NASCAR. Adjustability gets you the winners flag every time

Always on the lookout for good analogies to help get my point across, I happened to tune into the Nascar roundup on Friday night. Jimmie Johnson was being interviewed about the upcoming event.

As I am sure you can now guess I am a Nascar fan. Most of my friends and colleagues can’t understand this because from the outside looking in, it’s just a bunch of cars going round and round on the same track – what could be more boring than that. Quite the contrary however, Nascar racing is anything but ordinary. It’s a sport that requires incredible concentration, teamwork and most of all careful strategy and agility to outsmart the competition.

In particular, this Friday night’s interview struck a cord for me. The upcoming race was the 600 miler, a grueling race requiring mental fitness of the highest degree. Asked what he and the team were focused, on, Jimmie promptly answered “We’re working on making the car infinitely adjustable.”

I thought about this for more than a moment.

In Nascar, minor adjustments to the car’s setup can make the world of difference and in fact, the entire race is all about tuning the car for the current conditions. Race conditions change from moment to moment. Even the track temperature can make the difference of an additional couple miles/hour.

Assess the environment
So the manager’s job is to assess the car’s setup for the track conditions, how the competition is doing etc. I personally can’t think of anything more Agile than this. 40 plus cars flying around the track at close to 200 miles/hour all trying to assess the environment and make adjustments to the cars in order to squeeze out that little bit extra which can mean the difference between winning and losing. This all happens under enormous pressure and in an incredible short space of time.

Build the safety net for change
But it’s not the speed that is the deciding factor; it’s the adjustments that are made during the race to deal with the race conditions at that moment that ultimately lead to the fastest times.
I think the same is true for Software Development. Teams need to ensure that the codebase is “infinitely adjustable”, i.e. changes can be made quickly and without fear that something is going to break, based on customers changing requirements, the market conditions, the competition etc.

I know of only one way that teams can achieve code agility and that is through extensive unit tests, Test (TDD) and Behavior Driven Development (BDD). Writing tests gives developers comfort in knowing that changes to the code aren’t going to break the code. Developers that have this safety net are better positioned to put their company in a winning position. Companies never know where the next competitor is going to come from and what their strategy is going to be. The only certainty in life is that nothing stays the same. As a result you need to position yourself to be able to deal with change. The teams that manage this best are inevitably most likely to success.

I hope you find this analogy useful. I know it helped put things in perspective for me.


I tend to go to one big agile conference a year (doing a PhD helps to add motivation). This year it is XP2009 – the premier European conference on all things agile. Usually I publish some reports either after or even before the conference. This year I got lazy extremely busy having a PhD symposium, a paper and a workshop to run and instead of a creative reporting I just let you see the photos to get a feeling of what the conference atmosphere was like.

If you wonder about the place, everything happens on a very lovely place on the Italian island Sardinia.

Unfortunately I am still bad with remembering people I don’t know very well, so if you recognize an unnamed person, tell his name in the comment and I’ll update the post. This post will be updated if I add more photos later.

First several random pictures of the people talking.



Evening singer in the restaurant


You have to pass this area on the way to the restaurant

Thinking about a common problem I guess

Coffee break queue

Helen who was a co-runner of the PhD symposium and the students

The guy on the right is Hubert, one of two official photographers on the conference. Ask him for the better photos. The other official photographer is Tom Poppendieck, but somehow I didn’t take a photo of him yet.

Mary Poppendieck sharing her wizdom and humor – as usual

That’s what the hotel territory looks like

About 50 meters from the hotel

You can see the hotel on the background

I think white is one of the two the favorite colors of Joshua Kerievsky. At least he always wears either white or black, when I meet him.IMG_0020[1]

The guy in the middle is Patrick Kua who writes a very useful blog on agile coaching

Couple of finns (Kati and Mikko) and, well, couple of non-finns. The amount of of conversations in Finnish on this conference skyrocketed comparing to, say, XP2007. I wonder whether it’s a sign that Finland wasn’t hit by the recession as much as the other countries.

There are quite many “just tourists” in the hotel.

Unregistered participant

PhD symposium dinner. It was the first time I ever tried a dinner with seven or maybe even eight meals. Too bad they were also very tasty – will definitely have to spend some quality time in the gym.

Workshop on Agile Software Production Line Engineering. A manager from F-Secure, Pekka Abrahamsson and Frank Maurer

Lasse Koskela and Dave Nicolette demonstrate the art of test-driven development on legacy code.

Yours truly

Are you efficient or effective?

Efficiency and effectiveness are two words that are often used interchangeably. Many methodologies promise ‘increased efficiency and effectiveness’. I find this strange because in a rapidly changing environment like software engineering these two are often mutually exclusive. I think in order to understand agility it’s important to understand the differences between these two and the tradeoffs you are making between them.

How to be efficient
Traditional production techniques based on Scientific Management developed by Frederick Winslow Taylor about 120 years ago focus almost exclusively on efficiency. They does this by standardizing methods for performing work so workers can be interchanged easily, simplifying tasks by splitting them up into many simple subtasks that can be assigned to specialized workers and by increasing batch-sizes so many of these tasks can be done in series.

These ideas have also been applied to software engineering. The process can be split into analysis, design, implementation and testing. Workers then specialize in one of these tasks. By making sure that the result of each of these phases are meticulously documented it also becomes possible to move people on and off projects to maximize the amount of work they do. By performing these tasks in big batches, first all analysis, then all design etc. efficiency can be increased even further.

This allows you to do the maximum amount of work in a minimal amount of time. Unfortunately there is no way to know if you are doing the right work and if you are delivering the right quality until the end of the project. And even then it’s hard to see where the real problems lie because the client did sign off on the documentation after every phase of the project. Efficiency is easy to measure and easy to manage. That’s why it gets a lot of attention but by focusing exclusively on efficiency effectiveness suffers.

Become more effective instead
If you want to do the right work instead of just doing a lot of work you need to address a couple of issues. Lets look at how agile addresses these

First of all we need to make effectiveness more visible. We need to get rapid feedback when about the effectiveness of the work we’re doing at any time. Is the feature we’re implementing solving the client’s problems? In order to do this agile methodologies have several feedback loops built in. TDD allows us to check the quality of our code continuously. Pair programming provides instant code-reviews but most importantly by delivering working code often we get feedback from our clients.

In order to be more effective we need to be flexible. When requirements change we need to be able to change direction too. This can be done by minimizing work in progress. By working in small increments and finishing all work after each increment we’re able to re-evaluate goals during the project.

Splitting up work and having different groups of people work on different phases of a project can also be ineffective. Information is lost between phases of the project. Even when an analyst has the right idea about what software needs to be built this information is worthless when not communicated to the rest of the team. Agile methodologies address this by collocating teams. Documentation should not be the only means of communication.

So what’s it going to be?
So you can’t have both. What should you choose? Effectiveness or efficiency? Like always it depends. But trading in some efficiency for effectiveness will often turn out to be the right choice. There’s no use in running very fast if you don’t know if you’re running in the right direction.

Our Story Board is Better Than Yours

I have decided to take a break from my usual bi-weekly musings about high-level, theoretical subjects and devote this post to something more concrete. I would like to show you how our story board that we use for sprints looks like. This may be of interest to both newbies and advanced users. The former will have a chance to see how this sort of a thing looks in practice, the latter will be able to compare with their own story boards and share their opinions, praise or criticize (in a constructive manner of course).

The subject is also interesting because it gives insight into the evolution of our team, its dynamics, its priorities – I think it is safe to say that our story board is a reflection of who we are and what sort of a project we are working on.

Let me start with a disclaimer: this story board is not “by the book” – it is not exactly the type of board that is described in Scrum handbooks. It started that way. But over time it has evolved, mutated, adjusted itself to fit our needs. “By the book” solutions are good in theory only, day-to-day reality requires you to be more inventive than what “the rules” require.

The photo above shows our board midway through the current sprint (which is going to end on May 26th – around the time this post will be published). You will notice some obvious differences from “the standard”

  • the board has four columns instead of the typical three
  • the two inner columns are quite narrow compared to outer ones
  • there is no sprint burndown chart in sight

All three items above are our conscious choice and are there for a reason.

If you look closer (maybe the photo’s resolution is not enough to notice that), you will also notice that there are no tasks on the board – just stories and bug reports. A big no-no according to “the rules” – yet, this is what works for us and I will explain later why.

Let’s start from the first one – what is the fourth column? The additional, non-standard column is the third one from the left – it is called “Testing”. Stories go there after they get “finished” by whoever on the team happened to be working on them (it could be one person or a pair). This column reflects our “Definition Of Done” – our definition is “The Story Is Done When Somebody Other Than The Implementor Says It Is Done” (your “Definition of Done” is probably different, but this is what we use). The “Somebody” can be anybody on the team, but they must not be directly involved in the implementation of a given story. For bugs, ideally (but not necessarily) this should be the reporter of the bug. A word of warning – the existence of this column is a potential bottleneck – it used to happen that cards would sit in this column and nobody would bother to pick them up and test a story or a bug fix, moving it either right (“test passed”) or left (“test failed”). Therefore, during one retrospective, it was decided that after each daily standup, all cards in “testing” column must be dispositioned by noon of the same day, otherwise nobody is allowed to pick new tasks to work on. This sort of a setup gives us a quite tight first-line QA, that is fast enough to catch quite a few errors before they show up during the sprint demo, or “in the field”.

The second interesting fact – two inner columns (“In Progress” and “Testing”) are quite narrow. They are meant to fit just a few cards. This is by design. You are not supposed to start working on some story or a bug fix until you are done working on the previous one. So the inner columns are usually occupied by just a few cards – most of them should be either in the left-most (“Not started”) or right-most (“Done”) column.

Next fact – we have no burndown chart at all. Why? Well, there used to be one, but it turned out this chart was quite meaningless. See, sprint burndown chart requires having time-based estimation of tasks required for implementation of every story. We used to do this – we used to split stories into tasks and estimate effort for tasks. But, either due to the fact that the work on our project consists mostly of “fighting with nature” and “charting the unknown”, or maybe simply be cause we suck badly at time estimations and at splitting stories into tasks, invariably midway through the sprint our initial tasks (both the estimations and task definitions themselves) turned out to be completely out of sync with reality. So one day we decided to stop doing it. Instead, we are splitting our stories in sub stories, in such a way that typically a story we accept for implementation is just 0 to 3 point big. Which incidentally is an order of magnitude less than our typical sprint velocity (around 12-15 story points per two weeks). So these days, we are able to estimate where we are at in each sprint by just glancing at the distribution of cards on the board – they are mostly of the same size, co number of cards in each column gives us metrics that are sufficient for us.

Now about the cards themselves. We print them straight from JIRA, using a nifty plugin that we have created. Take a look at the card on the right – decently looking, isn’t it? Now, most of our cards that are the “original” ones (scheduled during the sprint planning) are printed. But, if we happen to find a bug in whatever we have done during the sprint, we pin a hand-written card to the board and treat it just like the rest of them (and of course file a bug report in JIRA, to be fixed during the current sprint). There are quite a few of these hand-written cards on the photo.

The last thing for today – big piece of paper in the lower-right corner. It contains “the rules of standup” – what question you should answer, what topics to cover and what not to talk about. In case somebody strays from the subject, it is very easy to discipline them by just pointing them to “the rules”.

So there it is, our story board. It is better then your story board obviously – for our team. Your story board, with its own quirks and specifics, will be better than ours for you.

It’s all about Value, or is it? And if it is all about Value, what is it?


In all the scrum literature, there is much rhetoric on focusing on delivering value but there is very little explanation on how you calculate it. Exactly how do you calculate it? I came across an interesting article by Ryan Shriver called “Measurable Value with Agile” where he talks about delivering the right things by choosing tasks based on a cost/benefit analysis, and then delivering those things right with the selected agile method of your choice. Value is then calculated by measuring it via a defined set of identified targets, constraints, and benchmarks. Although I do agree that measuring performance is important, there is still a major problem; if business value can only be measured once a product/feature is delivered, how do you know which user stories to work on first and which ones to avoid? Sure a cost/benefit analysis may be an easy way to determine which tasks to focus on, however, the value of that task is yet to be determined. You can do a cost/benefit analysis, choose the “best” user story based on that analysis, and still deliver a feature that has absolutely zero value. So how do we offset this?

Other methods

There are numerous other methods that have been applied to calculating business value to base decision-making on such as financial prioritization, calculating NPV, shareholder value, the list goes on. However, I find that these methods all suffer from the same problem as a doing a cost benefit analysis. I haven’t found a consensus as to exactly how to derive business value prior to implementation because of how subjective the perception of value is.

Kano Model

Value, from a stakeholders’ point of view, differs from individual to individual and from organization to organization depending on their goals. In my opinion, the method to derive a number that comes closest to actual value is done by assessing themes (i.e. features) based on the Kano Model of Customer Satisfaction. According to the model, separating product features into the following categories can provide valuable information on how to prioritize work: threshold (or must-have) features, linear/performance features, and exciters/delighters (Mike Cohn, Agile Estimating and Planning, 2006). The relationship between customer satisfaction and degree of feature implementation can be found on the Kano model graph.

Business value alone may not cut it

So the more of these features that are implemented, the greater the customer satisfaction. And the way to assess the features based on the Kano Model is to survey users and customers directly and tallying up the results. Once customers or product owners tell you what they want and you develop the features based on those answers, there should be very little discrepancy between the estimated value and the actual value delivered. This is an overly simplified explanation of the theory so if you would like to read more about the Kano Model, I would suggest you read Agile Estimating and Planning by Mike Cohn. But I guess the main point that I’m trying to make here is that, although you can estimate business value, you can only truly derive business value once that feature/product has been delivered and feedback is provided (i.e. based on revenue, achievement of goals, etc). So trying to make an effective decision based on calculating business value alone, to me, is absolutely meaningless.

Half-dead project saved! Thank you – Direct Communication

Picture (c) Przemyslaw Bielicki

In my previous post I shortly described the half-dead project in an over-waterfall company me and my team had to save three months before production. In this part I will show you how direct (instead of discrete) communication with customer or good Product Owner in general can help saving almost dead projects.

As I described earlier me and my team had a lot of problems with the systems we had to integrate – technical issues were present but they were not dominant, even taking into account the fact that the team was not experienced in .NET and T-SQL stuff.

Customer saved our project

After some time struggling with technical issues we finally were contacted by the person who knew how the product should behave. This person (let me call her Product Owner – PO) had all acceptance tests in her mind and knew exactly how to help us understand the product. PO was in fact our client – to be completely clear, the product we were delivering was either win-win or lose-lose so we had to cooperate and the success was our mutual goal.

PO was remotely available (although in the same time zone) but that was not a problem for us at all – we exchanged tons of emails and some phone calls and that was perfectly sufficient.

We were working like this for over two months and we delivered every single customer’s request to the product. After the development phase our software had to pass the certification phase which, in fact, was couple-hour testing process in production. Our PO was present there and was helping other clients with testing (yes, there were other clients eventually using our product).

I could risk a claim that it was a huge success because we just found couple of minor issues that were not even concerning the software but insufficient or incomplete data in our production databases. Everybody is sure that what saved the project and what really caused it to be such success was direct contact and constant help from our PO. As I wrote in one of my previous posts, namely Customer Team Member – a way to winning together having customer as your team member is usually really good and efficient idea.

Fool’s gold?

There are also (of course) problems with such attitude – the most “popular” one is the problem with actually having a customer. But even if you have a customer, how would you encourage him/her to be involved in the project (they usually aren’t, especially at the beginning of the project)? It may depend on the actual contract i.e. how you define success or whether customer gain something by helping you – to know which contract best suits your current situation please refer to Peter Stevens’ article: 10 Contracts for your next Agile Software Project.

It saved us – it can save You

To summarize, from my experience every time I worked with customer that was involved in the project I produced software with the highest business value (at that time). Every time I worked directly with involved customer I delivered the product that everybody treated as theirs, everybody was the owner – that’s very cool feeling. This has also real business effect – satisfied customer is more likely to come back to your company. You gain credibility working together with your customers e.g. by showing them that you really work hard to meet their needs and to bring the best business value reducing costs. That usually pays off.

So, my final advice here for you would be to take some effort and time and look for a GOOD Product Owner. When you find her then start bombing her with emails, phone calls, whatever that can help your team deliver the product with highest possible business value.

What are your experiences with working directly with customers? Are they positive or negative? How would you improve thing in your project – could customer’s involvement help?

Read Agile Software Development blog on Kindle

Not that we would be expecting many of you to do this, but if you have an Amazon Kindle , you can subscribe ($$) and have new articles on Agile Software Development automatically downloaded.

Read on Kindle

I find Kindle a fantastic idea. Be it available in my country and cost less, I would probably read books on it. I am not sure whether I would pay for reading blogs that are anyway available online for free, but then maybe you find it comfortable enough for paying. Anyway now you have the option. If anyone tries it, let us know in comments to this blog.

Downfall of Agile Hitler

Several days ago during the over-the-beer-discussion after the latest Business Value Game workshop (it was a huge success and I am still looking for an assistant to help with it on XP2009) told me about this YouTube video (sorry, I don’t remember who exactly it was). It is humorously subtitled piece of movie about the last days of Hitler. With these subtitles Hitler seems to be extremely.. disappointed of how his team failed to follow the agile principles. As one of the commenters said “i can say this is so close to the truth it’s scary!”. Have a look

“Stop Starting and Start Finishing” – A successful Lean philosophy

One of the killers on software development projects is Work-In-Progress. We have learned from the Lean experts and from the teachings on the Toyota Production System that too much work-in-progress is a liability. Just yesterday I was asked to spot the problem with a sister company’s task board. Sure enough one developer had 5 or 6 “in-progress” tasks on the task board. It took me a split second to notice.

The problem with this situation is that as a developer if you’re working on more than two tasks, simultaneously your productivity takes a dive. Additionally you’re going to end up with many unfinished tasks that never get completed. This is a classic problem in Waterfall where tasks have half-lives are in the order of man months. The more tasks in play at any given time, the more tasks that never get finished.

The most interesting quote from the Lean conference shared by Sterling Mortensen that really hit home for me:

“Stop Starting, Start Finishing” could not be more apt.

I believe this goes hand in hand with the definition of DONE that all the Agile thought leaders can’t seem to stress enough. There is no more important aspect of Agile in my opinion. The definition of DONE defines up-front exactly what is required to TOTALLY complete a task. If you’re minimizing work-in-progress and you complete this work in accordance with the popular definition of DONE, you’re going to drastically improve your overall cycle time. i.e. concept to cash. The reason is that unfinished tasks seem to linger on forever, never get finished and continue to drain the teams resources.

The other interesting quote which somewhat relates to the minimize work-in-progress theme:

“If you don’t know how to get the story out of the iteration – don’t let it in”

Living by this motto, ensures that you don’t have queues of unfinished work that have to roll over from sprint to sprint. Everything that goes in to the Sprint must get finished during that Sprint. This takes careful planning, so as not to over burden the team with work they know they can’t finish. It’s very similar to the JIT production systems that minimize inventory queues, and optimize throughput thereby ensuring optimum team efficiency and reduced cycle time.

So, plan to finish one story before starting another and always plan on finishing a story in the same Sprint that you start it in. What this means is your stories can’t be epics!

When is the story too big?

Nothing can ruin a Sprint Review meeting like having no stories to show the product owner when the sprint is finished. This week, I participated in two Sprint Reviews in two different companies. Both teams had the same problem. They took on stories which were so big that they had a queasy feeling committing to them. Of course, the stories grew during the sprint.

When should you advise your team not to accept a story because it is too big?

3 Warning Signs

Not accepting over sized stories is pretty standard advice. But how do you recognize when the story is too big? These are my warning signs:

  1. Past performance indicates you won’t get it done
  2. The story is large compared to the team capacity for the sprint
  3. The demo is complicated and / or demos many sub components.

Past Performance is a good guide to future performance

One basis is past performance (often called “yesterday’s weather”). If your velocity (capacity per sprint) is 25 Story Points and yet your team was unable to complete a 13 point story last sprint, then the team will probably have difficulties completing a 13 pointer in this sprint. (The same is true for total capacity: if your team completed 25 points last sprint, the 25 is a reasonable guess for the capacity in this sprint). Accept the inaccuracies in you estimates, and adjust your commitments accordingly.

Stories should be small compared to the size of the sprint

Another basis is comparing the size of a story to the total size of the sprint. My own rule of thumb is that no story should consume more than 40% of the teams estimated capacity. Why? An estimate is merely an estimate. If your team is knowledgeable in the technology and domain, each story has a nominal tolerance of +/- 50%. So 4 days could be 6 days, and you would still be in your tolerances. A six could be a nine. Assuming your capacity is 10, then committing to a 4 leaves a lot of room for error. Committing to a six exhausts your margin for error, especially if you commit to other stories. And anything bigger has a high risk of not getting completed, even if things go well.

‘How to demo’ makes the complexity clear

Finally, be sure to ask the product owner how to demo the story. This should be a simple, repeatable work flow which shows that the function does what it is supposed to do. If there are many work flows, then the story is probably complicated and getting all of the work flows to work may be a challenge. Furthermore, a story which defines a work flow or two and then says ‘and other flows like story XY’ or which contains the phrase ‘et cetera’ is suspect. I would insist on defining all the work flows needed for each for demoing each story.

And if the stories look too complicated, then splitting the story on the basis of the demo work flows might be a good place to start.

Splitting Stories which are too big

Personally, I find recognizing stories which are too big and splitting them in to right-sized stories to be one of the most challenging disciplines of Scrum. For the developers and Product Owner alike, it is a big change, since the splitting the story often does not produce a logically consistent feature set at the end of the sprint. It takes a sprint or two or three to get to a deliverable state.

So how do you deal with the challenge? How do you recognize when the story is too big? And how to you prevent stories from ballooning into huge, never ending monster stories?