Thinking Inside a Bigger Box

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!