Agile Development Blog

Original F4 Technologies logo 2002-2004

I know what you are thinking with the title of this post – I am drinking the Kool-Aid. Just bear with me  for a minute. Back in 2002, when I started working on Rally, it was originally known as F4 Technologies. It was known as F4 because I did not want to work on anything that did not have the potential impact of a Factor of Four, for example a 4X increase in productivity or effectiveness.   There are two reasons for this:

1. Andrew MacAfee and John Gourville at HBS have shown that you need a 9X improvement with a new tool, technique or method to un-seed the incumbent.
2. According to Paul Hawken in Natural Capitalism, we need a 4X productivity increase in the use of natural resources to get to a sustainable place with the current population in the world.  Chapter 7 of that book helped form the core purpose and mantra of Rally – “Muda, Service and Flow.”

Now seven years into Rally, we have the proof that teams – including large and distributed teams – can be 4 to 10X more productive by following Lean principles and effectively implementing Agile development.  Like the story of “Good to Great”  from Jim Collins, you can’t leap here, but you can put yourself on that path by adopting a continuous improvement approach like Agile.  If you do that, you can be a “great” software development organization that dominates your market and is 10X better than the good ones.  Great organizations that dominate in their industry also have the knowledge and resources to change world, a la Google.org, the Salesforce.com Foundation and or through my favorite the Entrepreneur’s Foundation.

My summary take-away from Good to Great is:

“Right people building the right things right”

“Disciplined people, Disciplined thought, Disciplined culture “

If you are working toward this, I believe you increase your business value by 4 to 10 times.  I am going to make the case with the help of ROI models from David Anderson.  (BTW, I love his book – it does a great job explaining the simple physics of Agile.)

From Chapter 2 - David Anderson's "Agile Management for Software Engineering"

This is a very simple model of software process.  David shows more complex ones that model all the loop backs of large shipping software, but let’s work with this one.  So, the rough equations to calculate the business benefit of the process are the following:

Net Profit = Throughput – Operating Expense 
ROI = Net Profit / Investment

In the following four pages, I am going to look at how this equation plays out for four different scenarios:

1. Good waterfall team, on the mean line of the QSMA Agile Impact Report
2. Beginning Agile team in Flow benefiting from the 25% productivity savings of an Agile teams in the same study
3. Intermediate Agile team in Pull with incremental releases of value
4. Advanced team in Innovate that cuts time-to-market in 1/2 to end early after delivering 50% of the work but 80%the value

What you will see in this hypothetical modeling exercise is the true power of Agile to dramatically impact the software development teams in the organization. For a deeper understanding of what I mean by Flow, Pull and Innovate, please Jean and I’s white paper on moving to Program Pull.

Here is the summary:

1. Good waterfall team – ROI – 0.8
2. Beginning Agile team in Flow  – ROI – 1.4 (1.6 factor better than good waterfall team)
3. Intermediate Agile team in Pull  – ROI – 2.6 (3.2 factor better than good waterfall team)
4. Advanced Agile team in Innovate  – ROI – 6.3 (7.7 factor better than good waterfall team)

Factor or Four or better – that is why there is such a rush towards Agile development.  Of course, you can’t have your cake and  eat it too.  Moving up this maturity curve takes long-term dedication to increasing discipline and agility across the entire organization, but there are dramatic benefits if you can get on the continuous improvement path and stay there.

Jean in the mini-kitchen at Rally headquarters.

Jean has been doing a series of posts (What is with all the Agile process overhead? – part 1,  What is with all the Agile process overhead? – part 2, and How do you plan for unplanned work? – part 3.) on what goes in your backlog.  We have both noticed that it is really tempting to put the kitchen sink in your backlog.  At Rally, we only do progressive elaboration of stories based on subsequent levels of planning, which ends up looking a bit like this:

• Ideas and research topics managed by product line on the wall and adjusted across product lines every quarter
• Epics at the roadmap level (multiple release level) managed in a roll-up project in Rally’s Agile project management solution and estimated every eight weeks for release planning
• Stories at the release level managed in individual projects in Rally elaborated every eight weeks at release planning
• Tasks at iteration level managed by team member in Rally and elaborated every two weeks at iteration planning

As a result, we keep our backlog well groomed and do not waste time (muda) managing excess inventory or over-investing in stories that are not guaranteed to get built.  I have noticed it is really tempting to try and load all your ideas, suggestions and half-baked stories into a product like Rally.  We built Rally to make that uncomfortable – to try and discourage that.  Rally focuses you and the team on the iteration and not a big list of defects and bugs, while our coaches and technical account managers try to help folks move away from thinking of our system as an inventory manager.  We think of Rally and design it as a real-time decision support system.  (See my 2006 article in SD Times on “Kill your inventory manager” for more on this topic.)

As Jean and I were talking about this in our kitchen, I was noticing something  (see the picture). In this picture, there are no dirty dishes in the sink.  This is a relatively new occurrence here at Rally.  It happened when we moved from our old location, which had a huge kitchen and two dishwashers, to this new building. We doubled our square feet but shrunk our kitchen space in half with no dishwashers as a result of an in-house cafeteria that we share with Oracle and Quantum.

With almost no counter space and no dishwasher to batch up dirty dishes, you have to clean your dishes as you use them.  For the 150+ people who work at this office, that means a real just-in-time process of dirty it and then clean it.  As a result, we have less dishes, less wasted time and less wasted space due to managing the dirty dishes.  We also lost the typical sign that says, “Your mother does not work here! Please clean-up after yourself.”

Excess inventory leads to wasted time, wasted effort, and friction.  If you keep your backlog well groomed and focused on the valuable items, as Jean illustrates, you can keep from wasting valuable time.

This post is in honor of Greg Macaluso and Kevin Mindenhall, both manufacturing and distribution process consultants from Coopers & Lybrand.  In 1993, they taught me the way of JIT and Lean while working on an MRP project at Robinson Brick and a remittance processing project at U S WEST Communications.  In addition to tutalage, they had me read and flip the wonderful pictures of JIT, kanbans and manufacturing facilities with no horizontal space.  By removing the horizontal space to store stuff, the raw and work-in-process inventory went down and the throughput went up!