Show them the numbers – it’s results that matter

NOTE: I originally posted this at my old company's website in 2011,
but as that blog has been taken down, I thought I'd resurrect this
post here.

On a recent project one of our customers had some questions about the project’s progress. The project was a mid-size systems integration between Oracle Financials and Onyx CRM for a Fortune 500 company.

As with many large companies, there were several business units and people with interest in the project, and also as with many large companies, people had several other projects to deal with and were not attending the daily standups or weekly progress meetings.

I began to hear that there were some concerns about the project progress from some of the management team and a concern that we were spending too much time writing tests instead of code.

This came as a big surprise to me: from the perspective of the team working on the project on a daily basis (both customer and ext.IT), we were sailing along with no problems. We were providing the usual artifacts such as status reports which showed how we were tracking against estimated hours and when our code complete date would be, and all of this was tracking well against our original estimates, so to hear that people were unhappy was a big shock.

I called a meeting with all of the stakeholders and as soon as I invited all of the stakeholders I realized two things:

  1. This meeting would be the first time in the whole project that all of the stakeholders had been in a room together.
  2. While we had discussed our approach during the initial engagement, we hadn’t held a project kickoff with all of the stakeholders to discuss our approach to building software.

Both of these items were my fault, but here I was, several months into the project with an unhappy customer, so I thought I would address it in this meeting.

I put together a short presentation which discussed our approach to building software, including brief descriptions of how we perform iterations, test driven development, automated acceptance testing, retrospectives and other benefits to the way we build software, and why we considered our approach to be best practice.

Almost as an afterthought, I ended the presentation with a couple of slides showing our project status. This was an afterthought because everyone at the meeting was a recipient of the weekly status report containing the same information. I created one slide comparing our original project estimates (before we had detailed requirements) to our detailed estimates (once requirements were fleshed out) and to our actual hours so far on the completed features, and another slide showing our defect count and comparing it to another of the customer’s internal projects that they had build without the benefit of automated tests.

Once the meeting started, it was clear that I didn’t need any of the slides about our approach. We spent a few minutes discussing the original estimates against the actual time taken for completed features: everyone was happy with the job we had done in estimating against the original high-level requirements. We also discussed how we were tracking on the hours left: again, everyone was satisfied with the results. Finally, we spent five minutes comparing the low defect count on our project (with a high level of test automation), compared to some of the customer’s other projects (without unit tests), and everyone was satisfied with this too.

There wasn’t a single question about our approach, and ultimately no-one in the higher echelons of the customer’s business cared about the minutiae of our approach, nor were they interested in why we thought our approach was best practice.

They simply wanted to see the results of our approach.

In retrospect, this might seem obvious, but the best way to convince anyone that your approach to doing something is practical and pragmatic, is to do it and measure it against other approaches. People don’t care about dogma, or why you think something should be the best way. Only by showing people the numbers and measuring the effectiveness of your approach can you truly show that your practices are effective.

To conclude: After this meeting, the project was delivered successfully without any more concerns from the customer. We were one of several projects integrating with Oracle and we were the only project to deliver on time and under budget, with a very happy customer!

The Waterfall approach to reading

NOTE: I originally posted this at my old company's website in 2010,
but as that blog has been taken down, I thought I'd resurrect
this post here.

I was chatting to my wife the other evening and started to discuss reading lists. I wondered aloud how many years I had to live (30? 40? 50?), and was thinking about how many more books I would be able to read in that time.  A book a week for 40 years would mean I could read about 2,000 more books in my lifetime.

A quick search netted this wonderful article from the Guardian Online: 1000 novels everyone must read, so that was a great starting point.

I thought about how the task of building a reading list would look like if I approached the task like a software project.

The Waterfall Approach

  1. Use the Guardian article, Amazon reviews and recommendations to create the complete list of 2,000 books I am going to read.
  2. Prioritize the list.
  3. Buy all of the books in the list.
  4. Work through the list, reading the books in order.

Now deciding ahead of time what you are going to read for the next forty years is clearly ludicrous, as so much will change in that time.  My interests and priorities will change. The world will change. The available books will change. Even the cost and technologies for delivering books will change. All of this means that making decisions now about events far in the future is a pointless and expensive exercise, as most of the books in the list would go unread.

The Agile Approach

  1. Decide how far ahead you want to plan – far enough to avoid running out of books to read, but not so far as to make change costly.
  2. Make a much shorter list of books to read.
  3. Prioritize the list.
  4. Buy the first few books in the list.
  5. Keep updating this shortlist as your interests change and new books are published.

This approach has the advantage of having less overhead to maintain (a few books instead of 2,000), cheaper (less cost and inventory up front) and more flexibility (the list can change more easily over time).

Don’t plan in detail too far ahead, but be prepared for change

On many software projects, we are asked to plan iterations and projects months and even years into the future. This is as foolish as planning your reading list far in advance.

Just as most of the 2,000 books in our waterfall reading list would probably go unread, by the time we get to the end of a long software project, we know so much more about what we need to do and so much has changed that a lot of the later detailed planning has to be completely redone as it is worthless and out of date.

I’m not saying it’s worthless to have high level plans – in fact this is really important. We need to know if certain things have to be lined up ahead of time (for example communicating release plans and outages, getting users trained, making sure other teams are ready for the downstream affects of our changes) and we need to know when the last responsible moment to make those decisions will be.

We also often need to provide our customers with a ballpark idea of the costs and schedule of a project (is it a week? a month? a year?) before the project begins, but we shouldn’t treat this as being cast in stone. The plan has to be flexible enough to change with the landscape. The cost and schedule estimates need to be improved and updated as time goes on, as uncertainties about the project are reduced (I’ll write more about this in another blog post).

While a high level plan is a good thing, what is foolish is detailed design, task planning, assignment and estimating for items far in the future of a project. While this may give the illusion of control and predictability, it is just that: an illusion. In fact it’s harmful to have that level of detail because the more design artifacts and task details that need to change in a project, the higher the overhead of maintaining these details and the more rigid the project will become.

Just like keeping your reading list short and easy to change, you should keep your iterations and detailed project plan short. This will give you a flexible plan that can adapt as the project progresses.

For more ideas about shrinking your iterations, see my recent blog post on the topic.

The shortest amount of time that could possibly work – shrinking your iterations

NOTE: I originally posted this at my old company's website in 2010,
but as that blog has been taken down, I thought I'd resurrect this
post here.

It’ll never work

It’s hard to believe this with my looks, but back in Liverpool I sang and played guitar in a band. One day, in rehearsal we were working on a new song, and I asked the guitarist to play an unusual arrangement. (For the music geeks amongst you, one guitarist would play the three chord trick in the chorus, and the other guitarist would play the relative minor chords at the same time.) His response was, “it’ll never work – the chords are going to clash together.”

Now bear in mind, at this point we are in a rehearsal room, with guitars strapped around our necks and plugged into amplifiers. It would have taken thirty seconds to try this out and see (or in this case, hear) whether or not it worked, but instead a long argument about music theory ensued. Eventually we played it, and it worked. (We recorded the song some time later and I think that those chords played together still sound rather nice)

In retrospect, to get the guitarist to try out the idea, what I should have done (instead of arguing about music theory), was to say, “you know, you might be right, but let’s try it – if it doesn’t work, we’ll know pretty quickly and we’ll try something else.”

A resistance to short iterations

One of the things I almost always find when working with customers is a reluctance to shorten their development cycles. Although they begin to adopt a lot of good development practices and are enthusiastic about the benefits of an agile approach, they’ve been conditioned over the years to think that there’s nothing achievable in a week or less, and they want to start out with iterations a month long or more.

This resistance to change was recently summed up by Mike “GeePaw” Hill as a case of the “Yabbits.”

Yabbitting is when people go through a sequence of resistance statements, where each statement begins with the words, “Yeah, but…”.

While Yabbits can be annoying, Mike goes on to state their value:

Yabbits don’t always, or even usually, represent real resistance to change. On the contrary, they are probes, whose intent is to test an idea’s prima facie validity.

A person who offers you yabbits is typically more open to an idea than a person who says nothing at all.

So when faced with this resistance, remember that these objections are often coming because people care and because they have real concerns. I should have been happy that the guitarist cared enough about how the song would sound, rather than just going along with my idea.

Often it is easy to show someone who is resistant to change a way forward by asking them to try something for a little while and show them that there is little risk in trying it out. This approach avoids getting embroiled in an argument about about some esoteric theory of agile software development (or music theory!) For some practices, the change may be perceived as risky, but for others, like shortening an iteration, or playing a new arrangement of a song, the risk is minimal.

The shortest amount of time that could possibly work

The problem with having long cycles (particularly when transitioning from a traditional approach to an agile one) is that the cycles tend to behave like mini waterfalls: most of the work gets done at the end of the cycle, the testers have most of the features dropped into their laps in the last few days of the cycle, and a lot of the real tools and practices needed for a sustainable pace (for example continuous integration, build automation, automated regression test suites and improved communication) often don’t happen early enough in the project for the team to get real benefit from them and ease their transition.

Clock

The benefits of a short iteration far outweigh the risks. The only real risk is that you won’t get much done in the iteration, and the overhead of setting up the iteration will be high. However, shortening the cycle means that you will not waste time in high ceremony activities, and any pain points or roadblocks will become evident very quickly. In addition, the risk of not achieving much soon disappears as you become much better at slicing requirements down into small but valuable features. You will also improve several techniques that will help you work at a sustainable pace.

To summarize, you will see the following benefits:

  • Risks and inefficiencies are exposed earlier.
  • High overhead activities like long meetings that don’t get you closer to your goal of releasing a valuable feature are removed or reduced.
  • The team will work together, swarming on a single feature until it is complete, rather than continuing to work across many features in the traditional manner.
  • Improved communication between the team and the business owners is necessary to keep the work flowing.
  • Automation becomes a necessity, rather than a nice to have.
  • Less temptation and opportunity to revert to old practices and do mini waterfall.

So given all of these benefits,  how short should an iteration be?

Ward Cunningham famously rephrased Occam’s razor when applied to software development as:

…ask yourself, “What’s the simplest thing that could possibly work?”

Let’s redefine an iteration in this way:

Ask yourself, “What’s the shortest amount of time that could possibly work?”

In other words, find the shortest time-frame in which you can get something of value to the business done.

How short is that? Almost certainly shorter than you think.

How do you get there? Luckily, several people smarter than me have some ideas.

The disappearing iteration meme

There has been a recent meme about shortening iterations, with several people blogging on the topic from different approaches.

Michael Feathers recently wrote about Zeno length iterations, where he proposes an experiment:

Suppose that you had an iteration of one week, followed by an iteration of 2 days, followed by an iteration of 1 day, followed by an iteration of one-half a day, and so on…

…you can deliver business value in shorter times than you can currently imagine.

From Michael’s perspective, one of the main benefits of short time boxes is that they force trade-offs and produce creative solutions. He concludes by saying:

Look at your product today.  If you only had one day to develop and deploy some feature, before putting the product on ice and letting it generate revenue as is forever, what would it be?

While I think Michael’s experiment is a little abstract, the point he is making is that you can deliver value with very small chunks of code – smaller than you think today.

Kent Beck recently proposed a different experiment in extremely short iterations, for a different reason, continuous deployment immersion:

Get the whole team in a conference room Monday morning. Choose a feature you are going to add. Have one person come up to the one machine in the room. Write one line of code. Deploy.

If you can’t deploy, erase that line of code and write a different line of code first. Deploy.

Once the deployment is done, write another line of code. Deploy.

About this time some of the rest of the team is going to be bored watching all the manual steps in the deployment. Have them go off and automate the most tedious, boring, or error-prone step. Bring the automation back to the conference room and start using it.

Kent suggests that by doing this, you will start to automate your deployment, automate your tests and understand a lot more about slicing up your features into smaller chunks.

By Friday afternoon you may not have made much progress on your feature (but you may be pleasantly surprised), but you will understand deployment much better than you do now. You will also understand how to slice development more finely and rearrange the pieces. You will also understand the value of automation.

He also (with tongue in cheek) concludes that it’s a crazy idea, but in reality, there is also a lot of value here. Forcing everyone to think about where their pain points are and making the pain points happen often (due to shortening the cycle) means that the team will be motivated to remove and automate those pain points and ultimately work more efficiently.

James Shore and Arlo Belshee also recently gave a very entertaining talk at the Lean Software and Systems 2010 conference, entitled “Single-Piece Flow in Kanban: A How-To.”

In it they propose stripping down a lot of the complexity of Lean and only having two queues, On Deck, and In Progress.

Ideally, only one item (Minimum Marketable Feature, or MMF to use Lean terminology) would be in progress at any time. Instead of moving the MMF through the traditional production line of Kanban (for example, through requirements definition, story queue, development, testing and deployment), you instead create a detective’s blackboard by putting all of the information about the MMF onto the board. The name comes from detective TV shows, where all of the information about a crime is displayed on a blackboard. This information might translate to tasks or information about the feature.

The whole team swarms on this single feature until it’s completed and then it is removed from the board and the next item added from the On Deck queue. What is fascinating about this talk is that while Jim and Arlo disagree about some details and definitions (including their definitions of an MMF), they both agree that this is a more efficient way to build software.

Try it!

While there are several approaches to shortening the iteration, or taking a Lean approach and not having iterations at all ((For more information on Lean and Kanban development, read Jeff Patton’s excellent post, Kanban development oversimplified)),  the best approach for you is the one that you try. Whether you take Michael Feathers’ approach of shortening the iteration length to find a workable minimum, Kent Beck’s approach of starting with a single line of code at a time, James Shore and Arlo Belshee’s Lean approach of swarming on a single feature, or some other means doesn’t really matter. What does matter is not being scared to shorten the cycle until things are a little uncomfortable and real work needs to be done to make efficiencies such as automation or continuous integration, or coming up with creative ways to solve problems and chunk up work.

Don’t get bogged down in figuring which way will be the best to shorten your iterations – that is like arguing about music theory when you have guitars in your hands. Instead, just pick an approach and try it.

You’ll soon arrive at the shortest iteration that works for your team, and it’s almost certainly shorter than you think.

And before you become a Yabbit and say “it’ll never work” ask yourself this: “what’s the risk?”