Category Archives: Extreme Programming

The Architecture Spike Kata

Do you know how to apply coding practices the technology stack that you use on a daily basis? Do you know how the technology stack works? For many programmers, it’s easy enough to use test-driven development with a trivial example, but it can be very hard to know how to apply it to the problems you face every day in your job.

Java web+database applications are usually filled to the brim with technologies. Many of these are hard to test and many of these may not add value. In order to explore TDD and Java applications, I practiced the Java EE Spike Kata in 2010. Here’s a video of me and Anders Karlsen doing this kata at JavaZone 2010.

A similar approach is likely useful for programmers using any technology. Therefore, I give you: The rules of the Architecture Spike Kata.

The problem

Create a web application that lets users register a Person with names and search for people. The Person objects should be saved in a data store that is similar to the technology you use daily (probably a relational database). The goal is to get a spike working as quickly as possible, so in the first iteration, the Person entity should probably only contain one field. You can add more fields and refactor the application later.

The rules

The most important rules are Robert Martin‘s three rules of Test-driven development:

  • No code without test (that is, the code should never do something that isn’t required in order to get a test to pass)
  • Only enough test to get to red (that is, the tests should run, give an error message and that error message should correct)
  • Only enough code to get to green (that is, the tests should run and not give an error)
  • (My addition: Refactor on green without adding functionality)

Secondly, application should be driven from the outside in. That is, your first test should be a top-level acceptance test that tests through http and html. It’s okay to comment out or @Ignore this test after it has run red for the first time.

Lastly, you should not introduce any technology before the pain of not doing so is blinding. The first time you do the kata in a language, don’t use a web framework beyond the language minimum (in Java, this means Servlets, in node.js it’s require('http'), in Ruby it means Rack). Don’t use a Object-Relational Mapping framework. Don’t use a dependency injection framework. Most definitely don’t use an application generator like Rails scaffold, Spring Roo or Lift. These frameworks can be real time savers, but this kata is about understanding how the underlying technology works.

As a second iteration, use the technologies you use on a daily basis, but this time set up from scratch. For example, if your project uses Hibernate, try configuring the session factory by hand. By using frameworks in simplest way possible, you’ll both learn more about what they bring to the table and how to use them properly. For complex technology like Hibernate, there’s no substitute for deeper understanding.

What to expect

So far, I’ve only done the Architecture Spike Kata in Java. But on the other hand, I’ve done it around 50 times together with more than ten other developers. I’ve written about how to get started with the Java EE Spike Kata (in Norwegian) on my blog before.

This is what I’ve learned about working with web applications in Java:

  • Most Java web frameworks seem to harm more than they help
  • Hibernate is a bitch to set up, but once it’s working, it saves a lot of hassle
  • Using TDD with Hibernate helped me understand how to use Hibernate more effectively
  • I’ve stopped using dependency injection frameworks (but kept on using dependency injection as a pattern)
  • I have learned several ways to test web applications and database access independently and integrated
  • I no longer have to expend mental energy to write tests for full stack application

The first time I write this kata with another developer, it takes around 3 to 5 hours, depending on the experience level of my pair. After running through it a few times, most developers can complete the task in less than an hour.

We get better through practice, and the Architecture Spike Kata is a way to practice TDD with the technologies that you use daily and get a better understanding of what’s going on.

Posted in English, Extreme Programming, Java, Software Development | 1 Comment

How to start a Coding Dojo

I recently attended the XP Days Ukraine conference in a rainy, but beautiful and Christmas-decorated Kiev. I conducted a coding dojo and gave a talk where I demonstrated pair programming live together with Dima Mindra. After the talk, I got a few questions about how to run a Coding Dojo.

This article is meant as a guide to anyone wanting to start up a Coding Dojo, whether it’s in Kiev (Mikail/Aleksey), in Odessa (I’m looking at you, Dima!) or anywhere else in the world.

A Coding Dojo is a place to learn and have fun while programming

Quite simply, a Dojo is a gathering of programmers who come together to have fun and learn while programming. It’s always hands-on and it’s always social. In Oslo there are about 300 people who have signed up their interest. We meet on average once per month, usually in a bar. There is anywhere from 5 to 25 people who attend any given meeting.

Alternatively, a Coding Dojo can be used to describe a single event for a company or team that wants to train their developers in a hands-on and engaging way.

Coding Dojo Style #1: Many programmers, one problem

In the martial art Aikido, “Randori” means that multiple people are attacking the same person. In the Coding Dojo, “Randori” means that multiple programmers are attacking the same problem.

In order to organize a randori-style dojo, you need a computer with a development environment, a projector, a place to meet, a facilitator and 4-10 programmers who attend. Here is one way to carry out a Randori Style Coding Dojo:

  • If the group is new to test-driven development, the facilitator demonstrates the red-green-refactor cycle with a simple example (no more than 10 minutes)
  • The facilitator introduces the programming problem (kata) to solve. The Prime Factors kata is a good first kata for a group
  • The faciliator invites a partner to join him at the keyboard. The facilitator writes a first test, makes sure it runs red and invites someone else from the group to take his place.
  • Each pair works on the problem for 5-10 minutes, the facilitator then makes sure that one person in the pair is switched out with someone in the audience.
  • After about 45-60 minutes of working on the problem, call a break and review what’s happened. Personally, I’ve had success with asking everyone to name one thing that they learned, one thing that surprised them, and one thing they want to change about the way they work.
  • After the review, the group can work on another kata (problem), try the same problem again or use another exercise form

The biggest barrier for most people to participate in a Coding Dojo is that most programmers have never programmed live in front of anyone else. This feels extremely awkward and vulnerable at first. As a facilitator, your most important job is to help everyone feel at ease at whatever level they are.

Coding Dojo Style #2: Pairs working in parallel

Some people report that a Randori-style dojo can feel slow and constrained. As an alternative, I sometimes use the CyberDojo software, created by Jon Jagger. For a CyberDojo style dojo, you need a place to meet, a computer with a projector and internet access, a facilitator and 6-30 programmers with their own laptops with a web-browser and internet access. Here is how I usually carry out a CyberDojo style Coding Dojo:

  • The group forms pairs of programmers
  • The facilitator sets up a CyberDojo on (It may be smart to send a quick tweet to Jon to make sure he’s not planning to restart the server at this time)
  • All the pairs work in the fashion the group has agreed to work for 30-60 minutes
  • After the coding session, the facilitator uses the CyberDojo dashboard as a focus for discussions of programming habits

If you’re thinking about facilitating a Cyber Dojo, just go to, try creating a dojo and solve a kata. You can do this on your own now!

Coding Dojo Style #3: Working under stress

Extreme startup is a workshop based around a server that will ask questions of the software running on the computer of each participating pair. As the pairs answer questions correctly, they are awarded points. I usually run an Extreme Startup session after having run a strict TDD Coding Dojo. In the Extreme Startup, teams can work any way they want.

The Extreme Startup software is developed by Matt Wynne and Richard Chatley. There are several forks, including mine, which tries to maximize the stress.

In order to run an Extreme Startup workshop, you need a place to meet, a computer with a projector and the Extreme Startup software, a facilitator and 6-30 programmers with their own laptops with a development environment of their choice. All the computers need to be on a shared network so they can communicate using TCP/IP.

  • The group form pairs. If someone wants to work solo, or in bigger groups, that is okay, too
  • The facilitator starts the Extreme Startup software in warmup mode
  • The facilitator demonstrates how to get started (I use this collection of starting points in a number of languages)
  • The teams work for around 30 minutes until (almost) everybody have been able to get a web server running and registered on their computer
  • The facilitator starts the Extreme Startup software in real mode
  • All the teams reregister their servers. All hell breaks lose as they try to implement the questions as fast as they can
  • After the teams have worked for another 60 minutes, the facilitator breaks off the competition. Ask the teams on the top to describe how they worked

If you’re thinking about facilitating an Extreme startup, download my or Richard Chatley’s version of the software to your computer. The README file explains how to get it running. Then download Steria’s collection of starting point to your computer. Use the ruby/sinatra_for_dummies starting point to create a solution. Let me know of your experiences when trying out the software, so I can improve the README.

You can do this by yourself now!

Start a coding dojo

A coding dojo is a great way to build your professional network, become a better programmer, and to have fun! I hope this article can help you get started.

Posted in Communities, English, Extreme Programming, Pair programming | 7 Comments

Experience Agile Programming

The next half year, I’m scheduled to give the talk “Experience Agile Programming” in Kiev, Gothenburg and Riga. In the presentation, I pair with a local developer and show a coding kata in Java, Ruby or CoffeeScript. After the presentation, I engage the audience in a discussion of what they saw, when they would use it, etc. I might also show a few more programming tricks if time permits and the audience requests it.

If you are a local developer in Kiev, Gothenburg or Riga this could be a chance for you to improve yourself. I’ve got more than ten years of experience with extreme programming practices and chances are you will learn a few tricks that will put a smile on your face. I will practice with you before the conference, and my goal is to make you shine during the presentation. Chances are that your peers will recognize your skills after the conference, so this may help you get some local fame and build your personal brand. Finally, programming as an exercise is great fun and the experience is likely to leave you with a smile on your face.

Here’s what Jussi, who I paired with for #TampereGoesAgile has to say about the experience:

If you’re a programmer who’s willing to take a risk, learn a lot and get some attention from your peers, please get in touch via @jhannes, or comment on this blog post.

Posted in English, Extreme Programming, Pair programming | Leave a comment

What’s your MyScrum?

Instead of using Scrum, maybe we should use MyScrum. It’s like Scrum, with the stuff added that you think will super charge your MyScrum.

This is my MyScrum:

  • I want to measure velocity every week
  • I want to demostrate the product with a cadence that makes sure users show up to the demo
  • I don’t want to have story point estimates, I want to have story point budgets
  • I want the product owner, not the team, to own the budget/estimate (but they team may veto)
  • I don’t want commitments or forecasts from the team, I want measured historical progress
  • I want to plan per story, not per sprint
  • I want the developers who will develop a story to follow it (or pass the baton to other developers) from detailing to deployment.

What does your MyScrum look like?

Posted in English, Extreme Programming, Software Development | 3 Comments

How extreme is extreme programming?

The term Extreme Programming (XP) was coined in the nineties. Originally, it described a set of practices that have mostly been widely adopted today. Among these practices were continuous integration, test-driven development, user stories and frequent releases. These practices are hardly radical or extreme today. So what does “extreme programming” mean now?

To me, the idea behind Extreme Programming can be summed up as follows: What would happen if we take what we know works, and do it to degree that seems at first unreasonable?

You will quickly notice that testing will be more effective if you test earlier. What is unreasonably early: Testing before we have something to test. Thus the idea of test-driven development is born.

You will quickly notice that code review is an effective form of improving quality and spreading knowledge in the team. What is an unreasonable amount of code review: All code should be written by two people. That is, pair programming.

Similarly, the idea of user stories comes from the observation that communication between users and developers is key to effective development of a user friendly system.

Some of the ideas of extreme programming don’t feel so extreme anymore. But the spirit should live on. What would it mean to do what we know works today to an unreasonable degree?

Take continuous integration for example. Most teams use continuous integration to run tests when they check in the code. What would happen if we ran the tests whenever something changes? Most languages support continuous testing or autotesting today and teams are starting to adopt this now.

Frequent releases may mean once every 1-3 months for many organizations today. What would happen if you increased the frequency from months to weeks, or from weeks to days. Or from days to hours? Some extreme organizations actually push changes into production automatically when their batteries of automated tests succeed.

Short iterations work and reducing parallel work helps many organizations today. What if we got away from the iteration altogether, and a developers pick the next story when ready. What if we delayed all discussions about the user story until a developer was ready to start programming it? Many organizations are working with variations of kanban to increased flow and reduce waste.

Extreme Programming means pushing the things that work further than we’ve done before. What good ideas would you like to do to an unreasonable amount?

Posted in English, Extreme Programming, Pair programming | 5 Comments

Can we replace requirement specification with better understanding?

On larger projects, I’ve always ended up resorting to writing down a lot of detailed specifications, many of which are wrong, irrelevant or we might not be ready to answer them yet. On small projects, the dialogue between the customer and the developers can flow easy, and good things happen.

The quick analysis

Developer: … so we’re going to complete the current task tomorrow or the day after. Could we discuss what to do next before you’re off to your next meeting?

Customer: Sure. The next task on the backlog is to send the payment request to the accounting system

Developer: Yeah. Um… well, we’re not really ready for the integration tasks yet. I was thinking that we might perhaps pick another user interface task. Would that be okay?

Customer: No problem. Let’s see…. how about “road project submits funding request”?

Developer: Great. What’s that?

Customer: Well, today, the owner of the road project sends in a paper form. Let’s see, the form is available as a PDF on our web site. Let’s take a look.

Developer: Let’s see…. We know how to deal with social security number, names, addresses. This field “municipality,” that’s the usual stuff, right? (customer nods) What about “request id”? What’s that?

Customer: It’s just a sequence number per municipality. It would be really nice if you could suggest a request number and then let the user override.

Developer: That should be doable.

They work out a few more details and get on their way. Total time, 30 minutes

The low ambition implementation

Developer: So, we worked on the funding request UI for the last two days. I think we’ve got something that looks pretty good.

Customer: Great, let’s see it! Let’s see… There’s a new “apply for funding request” menu item. Nice. But it should be “Fund road project” (developer notes feedback). Let me try and press it… Hmm… “select municipality”? Why do I get that?

Developer: Well, we’re still a bit shaky on AJAX. So in order to find the next sequence number, we would like to have the user select municipality first.

Customer: Oh, AJAX. That’s interactive web pages, right? Yeah, I guess that’s fine, but we need to fix up the text a little. So, what happens when I select one…? Nice, it sort of looks like the paper form. That will help us get learn it. But let’s move the fields around a little (he sketches a few change on a piece of paper).

Developer: We were a bit uncertain about this “sum” field. Does the user have to fill in the sum himself? He’s already filled in all the numbers.

Customer: That doesn’t make too much sense. How about if the web pages updates the sum field dynamically? Oh, you’ve got that ‘don’t make me do dynamic webpages’ face again.

Developer: Yeah, sorry. The last time it was a big mess. Can we hold off on that for now? Do you really need it?

Customer: (laughs) No, that’s okay. I guess we can just remove the field. That should be fine.

Developer: Yay! What about validating the bank account number? We left that out, because the documentation is…. well, insane. That alone will take at least another day.

Customer: No, we really need that. People often type it wrong, and then it’s a nightmare to fix all the errors that follow. You just have to fight though it.

Developer: (sigh) I guess it can’t be helped. We’re on it.

Customer: All in all, it looks pretty good. I’ll go over it by myself after lunch and bring you back some issues tomorrow.

The quick completion

Customer: Here’s a list of corrections. Nothing major, just a few misplaced fields and a few extra validation rules.

Developer: Great. We spent all of yesterday doing the bank account number validation. Man, that’s some bad doc! But we should be done before lunch.

Customer: I have an opening in my calendar at the end of the day, let’s take a look then and call it done. Great work, guys!

The contrast

Have you ever been on a small project where everyone has a pretty good understand of what’s going on and the communication works well? Developers can make a pretty good guess at the details and develop a pretty good first version. There may be some more work that’s needed, but these can be negotiated when the developers have a better idea of what’s going to be easy and what’s going to be hard.

When I’ve been on larger projects, this communication seems to break down. Instead the developers require a detailed specification in writing. And if something is missing from the specification, they reject it and ask for further details. And they won’t show the product to the customer before all the kinks are worked out.

When we do it well it’s not so bad, getting a detailed specification and finishing the task before we get real feedback. But it requires the customer to decide on things that may not be important, but that may impact cost substantially. It requires back and forth to get the specification written, reviewed, amended etc.

On a small project, a developer can understand the purpose, build something quickly and adjust it based on feedback. Is the reality of larger projects that this will just remain a pipe dream? If so, why? If not, how do you get the quick and informal feedback?

Posted in English, Extreme Programming, Java, Software Development | 4 Comments

Real time coding competition with Extreme Startup

Last week, I was invited to do a coding dojo for the Java user group in Bergen. I have written a few words about the dojo part of the exercise in a previous blogpost. After “classical” TDD-training, I decided to try something different and gave the group a competition to play with: Extreme startup, a workshop with software created by @rchatley and @mattwynne. The workshop was a huge success and I’m hoping to repeat it soon.

Extreme startup going strong after two hours

In the exercise, each group creates a bare-bones web server in a programming language of their choice and register its URL with the workshop server on my computer. The workshop server then starts asking each registered web server questions over http.

In the beginning of the competition, the workshop participants don’t know anything: They don’t know what sort of questions will be asked. They don’t know how the workshop server will encode the questions. They don’t know how answers will be scored. They only know that they will get http requests to the URL they registered and they have to work out the rest.

Similarly, I don’t put any requirements on how the participants work. They can decide to work solo, in pairs or in larger groups. They can decide to use TDD or not. They can decide to use any programming language they want. They can even sabotage or spy on each other.

I decided to officially end the coding dojo before the competitive exerice. This way, people could decide how long they wanted to stay and how involved they wanted to be.

As teams start answering questions, the scoreboard on the projector starts showing some teams doing better than others. After a pretty short time, @ovegram and @idarborlaug gained an advantage that they held throughout the night. Some people used tests and some did not. Some people quit early and some kept going. @StClairJohn and @karianneberg both showed remarkable stamina and kept working after everyone else had called it a night. Eventually they gaining the lead.

Take-aways: The competitive aspects and the open format made this into an extremely successful exercise. Many of the participants were not very familiar with the web-APIs of their platform, so having @bodiltv‘s collection of starting points helped people focus on the exercise, instead of the technical details. Having a real-time problem to work on forced people to balance quality and speed. Many teams considered using TDD and some did. Some benefited a lot from their tests, some might have been hurt by them. Some teams spotted problems using their tests, while one team forgot to run all their tests and ended up having a bug in production for a long time, while they had a test that could’ve saved them if they’d only run it.

One especially enjoyable aspect of the exercise was that the participants helped out other teams quite a bit. I waited with adding more questions until everyone was ready, so the leading players were interested in helping those lagging behind. I hope that in future iterations, there will be even more cooperation between teams.

@ovegram and @idarborlaug set up their working environment to ensure that they knew what happened “in production” all the time. As they were in the lead, I convinced one of the other players to sabotage them by stopping their server while I distracted them. They detected the sabotage within one minute, due to the way they set up their IDE.

There was one question where we believed for a long time that there was no correct answer. This was actually a good opportunity to discuss the problem of choosing your battles. Some customers will never be satisfied, so trying to please them is a waste of time. Recognizing impossible questions is a good lesson from the exercise. Even if it turned out in the end that the question did have an answer.

Extreme startup experiences (mostly for Robert and Matt): The extreme startup server is very cool. The questions are good, and I’m looking to add some of my own as well. Teams who had weak skills with regular expressions were often penalized, while no other skill were as essential. To add a different aspect to the game I would very much like to see (or add) some questions that require the servers to maintain state for client sessions.

Another weakness of the exercise is the fact it’s very hard for people to catch up when someone has a big lead. One possible modification would be to add situations where a single screw-up would cost someone a huge number of points, especially if they were already in the lead. Alternatively, if each round gives 10x the points of the last round, an early advantage will not carry for long.

It was a bit difficult to set up the workshop server on a Windows machine, mainly due to Ruby gems with native extensions. The server depends on a version of the library eventmachine that doesn’t compile on Windows, so I had to upgrade this. I updated the README and Gemfile in my fork for extreme_startup to describe how also get it to work on Windows.

Extreme startup is a very fun workshop and it is quite easy to run. I will definitively run it again at future workshops. The exercise lets you put your practices to the test. Your score will not depend on whether you did do things by the book or not. If you get a good score and didn’t use TDD, that’s fine. If you got a good score and did use TDD, that’s fine, too. If you wrote beautiful code, but failed to answer the questions, you still lose.

I hope that this blogpost inspires you to seek out or organize your own extreme startup workshop!

Posted in English, Extreme Programming | 11 Comments

Cyber Dojo and Extreme Startup

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 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.


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.

Posted in English, Extreme Programming, Pair programming | 2 Comments

Tell a story with your project plan

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.


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”.

Posted in English, Extreme Programming, Non-technical | Leave a comment

Visualize your work

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

Posted in English, Extreme Programming | 4 Comments