Thinking Inside a Bigger Box

Last week, I was invited to do a coding dojo for the Java user group in Bergen. I chose a format that let people work more independently rather than the classical style of “lots of people passing the keyboard around and looking on the code on a projector”. The result was an informal, competitive and engaged workshop where people continued playing with the exercise long after the official program was over. While drinking and socializing, of course.

I found the format useful, and perhaps this blogpost will useful to others who would like to organize a coding workshop.

Part I: A longer introduction

In order to get people to have a shared vision of the activities of the workshop, we started slower than I’ve sometimes seen in other workshops. First, everyone in the room said a few words about what they were hoping to get out of the evening. Then, I demonstrated a simple exercise together with @karianneberg. In the exercise, we demonstrate how to do pair programming and test-driven development. After the demo, we discussed what aspects of this way of working were surprising or different from what the audience was used to.

Take-aways: Coding dojos often throw the participants out on deep water right away. By instead showing an idealized pair-programming session, we provided a model for the participants to follow.

Part II: Exercise

We started out with the simplest programming exercise I’ve been able to come up with: Calculate whether a year is a leap year. I took the instructions for of the exercise from @jonjagger‘s Cyber Dojo tool. The participants worked in pairs on this exercise.

Cyber Dojo can be a frustrating tool, and I offered people the option to use it or not as they wanted. In the end, almost all the pairs chose to use it for the first exercise. And we could see how their work was progressing on the projector.

After everyone had completed the leap year exercise, we switched around the teams and worked on an exercise to translate Arabic numerals to Roman numerals. Here, too, I used the instructions from Cyber Dojo. However, due to various problems, we decided not to use Cyber Dojo as the programming environment for this exercise.

We did a brief retrospective after each exercise. I decided to mostly use this chance to ask “too much or too little questions”, like “do you feel it would’ve been faster if you’d taken larger or smaller steps?”, “do you think you refactored too early or too late”, “did you switch which person in the pair was using the keyboard too much or too little”, “did you spend too much or too little time thinking about how you would solve the problem”, etc.

Take-aways: Coding dojos usually practice a stylized form of programming with as small steps as possible. By reflecting on how it would be to work with the same problem in a less forced way, it’s easier for people to find out how they can apply what they learn to their day-to-day work. In particular, the discussion about how big the TDD-steps should be brought up a lot of interesting debate.

I usually try to have bigger exercises, like Yahtzee scoring or Poker hands. I found the smaller exercises to work very well for this workshop as this part ended up acting as a warm-up for the competition.

Cyber dojo experiences (mostly for Jon): I’ve used the Cyber Dojo a few times now. It’s an interesting tool, and I find Jon’s idea about taking away features to avoid distractions to be a good strategy in general. However, I usually find that to some level, the tool becomes a distraction because of its limitations. In particular, I think the groups would’ve wanted to continue using it if they didn’t have to work so with the build script and if they could’ve switched between files and run the tests using the keyboard. The groups miss code completion etc, but are willing to accept these shortcomings because of the community and competitive aspects of the tool.

The real killer, however, was the setup. Using a Windows box, I didn’t get the Cyber Dojo to run natively. I tried using a VirtualBox setup, but kept running into technical problems. In the end, I decided to risk using Jon’s hosted dojo at http://cyber-dojo.com. Sadly, it turned out that Jon was doing upgrades of that system halfway through our dojo. Too bad, but as he provides this service out of the goodness of his heart, I knew the risks.

Part III: Competition

After the exercises, we had a competition where people got to use or ignore what they’d learned as they saw fit. The competition used the Extreme Startup workshop. There’s a lot to be said about it, and I’ll write a future blogpost on Extreme Startup.

Conclusion

Cyber dojo and extreme startup both create a competitive and social environment for small groups to practice programming. This can create really fun workshops. The Bergen Java User Group kept playing with Extreme Startup until midnight.

I will use Extreme Startup as a workshop in the future. Hopefully I will add more questions, too. I may use Cyber Dojo again, but I’m hoping for some changes to the software before doing so. As it is, there are too many aspects that distract the users.

For those of you who already use PuTTY: Here’s a little improvement that’s surprisingly little known. Probably because it is very hard to explain. But I’ll try.

Here is how you can avoid starting programs, entering login information or indeed typing passwords when you use PuTTY:

1. Download Putty installer from the PuTTY Download Page. Make sure to grab the “Installer”
2. Install Putty
3. Start PuttyGen from Start -> PuTTY-> PuttyGen
4. Generate a new key and save it as a .ppk file without a passphrase
5. Use Putty to login to the server you want to connect to
6. Append the Public Key text from PuttyGen to the text of ~/.ssh/authorized_keys
7. Create a shortcut to your .ppk file from Start -> Putty to Start -> Startup
8. Select the .ppk shortcut from the Startup menu (this will happen automatically at every startup)
9. See the Pageant icon in the system tray? Right-click it and select “New session”
10. Enter username@hostname in the “Host name” field
11. You will now log in automatically.

This process is a bit hard to explain, so I have made a short video that explains it:

In order to streamline things even more, notice how Saved sessions show up under the Pageant icon in your system tray.

This blog post is a summary of my lightning talk at XP2011

I needed to fail with modern methods for requirement gathering in order to understand old methods for requirements gathering. Many software projects write requirements in what is refered to as “user stories”. But a use story is not a story at all. There’s no drama, no action and no resolution. Instead, user stories are often just a bunch of interactions between the user and the system laying in a big heap in a shoe box. Or even worse: In an issue tracking system. Using the form of use cases, a requirement form that had failed me in the past, I have reinserted the drama into my projects.

Humans have used stories to communicate and to think about the world for as long as we’ve had language. Some elements are common to all stories: A conflict upsets the order of the world. A hero enters the scene. Through the actions of the hero, the world is set back into order and the all is well in the world.

Here is a for a project that makes a webshop, the story of desire:

1. Some person craves stuff (the conflict)
2. The webshop(the hero) welcomes the craving user to its front page
3. The webshop lets the user picks stuff
4. The webshop lets the user pay
5. Some more stuff happens through the webshop so that the stuff is delivered
6. Even more stuff happens
7. The craving person gets his desire fullfilled and the world is set back to the way it was supposed to be

Not the most exciting story, you say? Well, you asked for software system requirements, not for literary masterpieces! The use case illustrates my point: A narrative lets us understand the purpose of the system (the hero) in the world and the operations the system needs to perform in order to fulfill its purpose. The first and the last step of this narrative happen without reference to the hero, setting the stage and providing the coda (look it up!), respectively. Each of the action steps between clearly states what sort of capability needs to be built for the system.

The story of desire is a made-up story to illustrate the point. Here is a simplified version of a real story in my current project – the story of disturbance:

1. There is a disturbance in the balance of production and consumption of electricity (the conflict)
2. Already, the system (the hero) has received from power plants information about their reserve capacity (this is a story of its own, but for another day)
3. The system shows the Operator (the real hero!) power plants with reserve capacity
   • Variation: The operator filters the list of power plants using some criteria
4. The system lets the Operator activate the reserve capacity at a power plant
5. The system sends an activation request to the power plant in question so they can be activated
6. The system shows the operator what reserves are currently activated
7. The system lets the user deactivate reserves
8. The system sends all activation requests to the accounting system, so the power plant can get paid
9. The balance is restored

If you wonder why this disturbance in the force is a bad thing, take a look at my blog post about xxx. You’ll quickly see that the balance of electricity may impact whether or not my beer stays cool. Clearly an important concern.

This story is a bit messier, since it deals with more real-world problems. Together with all the details I let out, it also has the disadvantage that it will take one team about a year to develop. Our customer is a bit too eager to get some software out the door to wait for all that.

So, we present: The impatient story of disturbance

1. There is a disturbance in the balance of production and consumption of electricity
2. Already, the system has received from the old system we’re replacing information about power plant reserve capacities
3. The system shows the operator power plants with reserve capacity
   • Variation: The operator filters the list of power plants using some criteria
   • Variation: The system updates the view it receives new reserves
4. The system lets the operator activate the reserve capacity at a power plant
5. The system sends the information about the activation to the old system we’re replacing for further distribution
6. The system shows the operator what reserves are currently activated
• Variation: The system shows the operator what reserves have been activated at a given power plant
• Variation: The system displays a chart of what reserves have been activated at a given power plant
7. The balance is restored

During the start of our project we wrote about 10 stories like the original story of disturbance. The stories were written by small gangs each consisting of developers and users or other domain experts. The gangs would swap stories and improve each others work. Meanwhile, the product owner and the project architect would try and pry apart a story so it could be delivered by a single programming team in the order of about 4 months.

For a single delivery, we would write an impatient story. Each action step or variation of the “impatient story of disturbance” became an item on the backlog of the programming team. I’ve left out about a thirds of the stories to keep the text of the blog post down. In addition, the team had about 5 technical tasks, such as performance testing. Each week, the team would deliver on average two such items.

After a few months, we have delivered the first increment in a system that tells a new story to the users, but a story they recognize. We have taken the task that they use their existing system for the most and made it easier and faster to use. The result: Happy users. And cold beer. We hope.

Notes

This approach has very much the same vision as Jeff Patton’s user story mapping and Effect maps. The approach of linear textual stories is one that works well for me. I urge you to find an approach that works even better for you. My stories use Alistair Cockburn’s style of use cases from “Writing effective use cases”, but with one changes: I simplify the writing of variations to better support the linear flow and avoid detail. They are roughly at what Cockburn describes as “kite level”.

Can the various European Agile User Groups benefit from working together? I am cautiously optimistic.

At XP2011 this week, Jurgen Appelo has taken the initiative to launch the Agile Lean Europe network. This is an initiative to bring together representatives from 17 European countries. Sergey Dmitriev and I will be representing Norway. To what end? I’m still not sure.

There is no doubt that there is much Europeans can learn from each other. For example, Norway has long had several active user groups (Oslo XP meetup, Oslo Lean meetup, and Oslo Coding Dojo are my personal favorites). The biggest of these groups gather as many as 100 people on a monthly basis. We have also hosted a local, Norwegian language conference for four years. Last year, the conference had over 400 attendees.

Norway has also had several large public sector projects adopting Scrum, driving the commercial adoption of Agile.

Our “sweet brothers”, the Swedes, on the other hand, don’t seem to have any user groups on the same scale, but they have a local, somewhat smaller Swedish sister conference to Smidig 20xx.

However, the Swedes have several very high-profile speakers, like Marcus Ahnve, Thomas Nilsson, Staffan Nöteberg, Henrik Kniberg, and several others. In Norway, we practically only have local speakers.

Also, the Agile Sweden mailing list is very successful. We have made a few attempts in Norway of getting an online community going, but it has never taken off.

It seems clear to me that there is a lot we Agile Europeans can learn from each other. Exactly what remains to be seen.

What do you think is the future of the Agile community in Europe?

This blogpost is a summary of my ScanDev 2011 talk: “Fearless Improvement”

What is the goal of your current project? I currently work on a project for the transmission system operator for the Norwegian electrical grid. The value of the system we’re building is that my beer stays cool.

Skill

If you’re not skilled at what you’re doing, you may put in a lot of hours and end up having nothing to show for it. Maybe you ended up writing code that didn’t compile and you had to throw it away. Maybe you ended up staring at an empty screen for hours waiting for inspiration to strike. Maybe you ended up writing a long document, only to forget to save it and then your computer crashed.

The first trick to making sure that your work is worthwhile is to make sure that the effort you put in actually transforms to some effect. In order to achieve this, you need experience and practice with your craft.

Purpose

If you don’t know why you’re doing what you’re doing, you may produce a lot, but it ends up not being valuable to anyone. Maybe the code you write solved the wrong problem. Maybe your long document didn’t answer the questions of you readers.

The second trick to making sure that your work is worthwhile is to make sure that the effect you have actually produces value. In order to achieve this, you need to move in the right direction.

This is the model of all human industry, whether you’re making cars, books, food, presentations or software.

In software development, effort is the time you put in, skill is your skill as a developer, effect is the working software, purpose is the architecture and value is the business goal.

The fast track to success is to understand the last step: Value.

“The other me”

Here’s an example. Find the value:

My current project creates a system which presents in user interface electricity reserves and planned electricity production that it has received from a message gateway, as well as measurements that it has received from an electricity management system.

This is gobbledygook. If this is how I see the system, I will fail.

In order to see the value, we have to take a step back. The system receives planned production and available reserve capacity from power producers. It presents this, along with measurements of the current balance between consumption and production on the electricity grid to an operator. The operator uses the reserves to regulate production to match consumption.

Hopefully, this is much more understandable. You’re probably aware that there are companies that produce electrical power, and you probably understand that electricity consumption should match production.

But why?

The ultimate value of the system is to the consumer who want to plug his appliances into the grid and have them work. They should neither blow up (too much production) or lose power (too little production).

Who is this mysterious “consumer”, then. Why, it’s me! It’s not Johannes-the-software-developer, it’s the other me. The “me” who has his fridge connected to the power grid so I can keep my beer cool.

The purpose of my project is to keep my beer cool.

The other you

To understand the purpose of your system, you should try and see how it contributes to your own life. Not the life of the “you” who develops software, but the “you” who uses electricity, the “you” who drives a car, the “you” who breathes fresh air, the “you” who wants to retire at some point in the future.

If you can’t see “the other you” in your system – take a step back and look again. If you still can’t see “the other you”, maybe you should be working on a different project.

Teams gather around task boards to plan their day. If the conversation and the task board match, we stay on topic and we understand what the rest of the team talks about.

The last month, my project has redesigned the task board with this in mind. Here is a picture of our task board as it looked a few weeks ago:

Each column represents a day. The top swimline represents testing tasks, the second swim line represents development tasks, and the bottom represents outside influences. In general, each swim line represents a theme for the next few weeks. Each card represents a task.

Every morning, we review the board:

• The Scrum Master reads the title of every card from yesterday that has been marked with a green checkmark. These tasks are defined as done. The people who worked on the task may comment.
• For every task for yesterday that still has a magnet with a face on it, the person on the magnet declares the task as done or continuing. Done tasks get a green checkmark. Continuing tasks are moved to today.
• For every task planned today, someone puts their magnet on it and thus takes responsibility for the task. Preferably, tasks are claimed by two people who will pair program.
• The Scrum Master reads every task for today that hasn’t been claimed. The team decides whether they they can commit to it in addition to the rest of the task. If not, it’s moved to tomorrow.
• The team looks at the rest of the week to make sure that tasks are evenly distributed. They may have to decide to drop tasks in order to get done or to ask for another user story for the sprint in order to have enough to do.

We’ve also used marker pens to indicate tasks that take several days (one task on Tuesday and one task on Friday, in this case), and tasks that are dependent on other tasks. We only indicate this when we feel it’s important. With these modifications, the observant among you may have noticed that we have reinvented the Gantt diagram!

For the stand-up meeting to be meaningful and stay on-topic, you need to relate it to what you’re actually doing. Have your meeting by a task board that reflects the way you work.

Thank you to Ram Yoga for the brilliant pictures of our task board

One of best ways to get the full effect of pair programming is if everyone programs with everyone else. This maximizes learning in the team. Here are three simple tricks we’ve found useful to get the pair programming to flow better.

• Magnets: Getting away from task ownership is essential to get pair programming to work. Instead of writing names on the cards that represents the tasks the team is working on, we place magnets with pictures of the team members on top of the tasks on our task board. This helps people remember that they don’t have to permanently commit to a task. Moving the magnets around during the stand up meeting is a good way to discuss how to organize the work today. We try to keep one person and exchange one person on every task every day.
• Pair programming star: Deliberate rotation fosters learning in the team. Write the names of all team members in a circle on a whiteboard in the team area. Every day two people pair program, draw a line from the name of one to the name of the other. This both becomes the team’s own indicator of success, and an “excuse” to ask someone you haven’t programmed with if you could pair up with them today.
• Don’t sweat it: When I started pair programming, I found it exhausting! It felt like I never had time that I needed to ruminate over the problems and that I never had chance to explore solutions on my own. During this period, it’s helpful to remember to give people the time they need to think through problems on their own. I do prefer that the code that’s actually checked in is pair programmed, though.

When I started pair programming, I found it to be an obstacle for getting into flow. After a few weeks, working solo has become an obstacle to getting into flow. You got to give it some time and take the breaks that you need along the way.

With pair programming, the teams share responsibility, pull together and have more fun!

I’m getting a little fed up with descriptions of project development lifecycles starting with waterfall, and then describing iterative and agile development in waterfall terms. What happens if we start on the other side?

Project development lifecycles

• Agile: The project creates a roadmap for a year or two, commits to the scope a delivery in a few weeks to a few months, adapts their commitment as they learn more and irons out the details of each task just prior to when it’s performed.
• Incremental: The project commits to the scope the whole roadmap at the beginning of the project and delivers bits every few months according to this plan. The details of a task are ironed a few months ahead of time. Changes to the full project scope are handled as exceptions.
• Waterfall: The project commits to the whole scope of the roadmap at the beginning of the project and postpones delivery of all functionality until the end of the project. The project avoids spending time to verify details after any implementation has started. Learning is handled as exceptions.

Agile described in terms of waterfall (“do a full project every few weeks”) sounds chaotic. Waterfall explained in terms of agile sounds insane.

What do you do if you want to have a reliable system? You make sure you have redundancy: More than one component can do a certain job. You back up you valuable data to a separate system. You have two servers to provide your critical service, in case on fails. Yet, many projects have no plan for the inevitable absence of people with critical knowledge.

We practice pair programming to get redundancy. This manifests itself in many ways:

• When someone is sick, on vacation or leaves the project (to become a doctor, say), the project doesn’t suffer. Or rather, it doesn’t suffer as much. We do get less work done if fewer people are present, of course. And many of our developers have areas where everyone loves to get their help.
• We can add new people to the team. Learning how the system works is just a matter of pair programming as part of the normal rotation.
• We are very adaptive to varying focus at different times in the project. If we had someone who could only work with, say, databases, he wouldn’t have much to do at some times, and too much to do at other times. With pair programming, we still have people who’re especially good in some areas, but everyone can help out with whatever needs doing.
• No parts of the code are off-limits. As every commit of the code is written by two people, no one person has the right to block changes to “his” code. Anyone can make the changes that they need to complete their current task as good as they can.
• The team is working with fewer tasks at a time. As teams grow in size, there can be a lot of different things happening at the same time. This both increases the chances that people will step on each other’s toes (that is, work on the same source code files) and increases the amount of “Work in progress” at any one time. Pair programming effectively halves the amount of work in progress.
• Everyone has a understanding of the whole system. During planning and design discussions, everyone can contribute. Instead of focusing on technical components and subsystems, the discussion is about how to solve the user story as a whole.

Some studies focuses on the impact of pair programming on efficiency, quality, progress, or even focus. I think it’s much more interesting to see how pair programming changes the dynamic of the team. From a group of individuals, we form teams where everyone is appreciated as a contributor. Everyone has their individual strengths, but more importantly, everyone has the same goal in mind: The success of the team.

When I started pair programming daily, it changed my life and my projects for the better. I often point to pair programming as one of the most influential possible interventions on any projects. Very often, an audience member with a healthy degree skepticism will inquire about the research into pair programming.

Sadly, the practice of software engineering research has not come very far in this area, so the questioner is left unsatisfied. In this blogpost, I will summarize the current state of research into pair programming, and describe my hopes for the future.

Read the rest of this entry »