Agile Development Blog

I have been told repeatedly that my brain thinks in pictures, and as a result I have to work hard to communicate my logic effectively in words. Recently in my argument against an Agile Process Maturity Model, I made a comment that Agile is an instance of Lean.

One of the replies on the Agile Alliance Group of Linked-In countered that my statement isn’t accurate – and in fact a team being both “Agile and Lean” is an oxymoron. So, I looked in the mirror and said this must not be clear. I need to communicate better in both words and pictures.

“The term Oxymoron originates from the Greek oxy (“sharp” or “pointed”) and moros (“dull”). Thus the word oxymoron is itself an oxymoron.”  Wikipedia’s Etymology for Oxymoron

Instead of trying to figure out which is sharp and which is dull, I thought I would present my mental model on the evolving Agile software development ecosystem.

Agile as an umbrella term

First and foremost, Agile as an umbrella term was hatched in 2001 to represent a “way” of developing software that is focused on rapid value delivery, collaboration with a customer, face-to-face communication and measuring progress in working code.  It casts a wide net of iterative and incremental process frameworks including RAD, Spiral, Extreme Programming (XP), Scrum, DSDM, Feature-Driven Development (FDD), Lean Software Development, OpenUP and Kanban. These methods stand in contrast to highly structured methods that tend to measure success based on meeting plans and following the process.

My rendition of the geneology of Software Development Approaches

Agile has evolved both bottom-up and top-down based on the evolution in technology infrastructure, tools and guiding ideas of our industry. It is symbolized by increased productivity, speed to market, response to change and craftsmanship.

I believe it is not a fad, but a natural by-product of the increasing scientific as well as craftsmanship approach brought to this critical industry.

Lean merges with capital-A Agile

I see the pictured genealogy tree merging Lean software development methods together with capital-A Agile methods. This is because the physics behind Lean design and production are the same physics that make Agile deliver impacts like we see in the Agile Impact Report from QSMA – 50% faster time-to-market and 25% increased productivity.

Though the principles of the Agile Manifesto do not sound like the principles of Lean, the patterns are the same. (For a great overview of Lean software do not miss Corey Ladas’ guest post on Shaping Software.)

• Small batch sizes, short cycles that create rhythm
• Reduction in queues through pull
• Reduction in work in process inventory
• Design quality in
• Stop-the-line defect control
• Value streams the link to the customer
• Integrated learning through reflection
• Last responsible moment decision making

These patterns are the same for an effective Lean effort or an effective Agile effort. This thinking has me advocating that Agile is an instance of Lean, not just a ground-up new tree that was born solely from the roots of OO, Spiral and RAD.  I am having a hard time seeing the black and white separation between agile and lean. This is all grey, maybe I should say blue and red based on the diagram, to me. 

What do you believe – is Agile is an instance of Lean, or together are they are an oxymoron?

In the mid-1990′s, I worked on a great team (which included three members of Rally’s current technical team) as a consultant and eventually as a Director of IT at US WEST Communications in a part of the IT organization that became known at the Global Village Labs.

You can read about some of our early Intranet work in this 1995 Fortune Magazine article.  In addition to being filled with great people, we had a great leader by the name of Sherman Woo (great profile on ZoomInfo), who was a complete rebel.

Sherman, a 25-year veteran of the Bell system, was rebelling against slow IT services in the age of the 1996 Telecommunications deregulation act. To meet the rapidly changing needs of open network, he built this amazingly agile organization that leveraged Mosaic and then Netscape browsers to screen scrape mainframes using ORAPerl.

We used these agile teams of 5 to 10 people to build tools for customer service representatives and field technicians.  These were typically simple tools that bridged a couple of mainframes to build compound views that could answer really tough questions.

These questions were hard because each role was only trained in a limited scope in limited mainframes and that full training took 24 months.  So we used early Internet technology to open the access and bridge that gap with simple tools.

We made it into Fortune Magazine because our time to market was measured in months and our ROI was 1000%.  In our agile model, we delivered our first working increment to the business on test servers in a fixed time box of six weeks.  If these solutions showed value and promise for 5 users, we would run another 6-week time box and then roll the application to 50 users.  Successful projects then went on to 500, 5,000 and then up to 20,000+ users following this 6-week time box approach.  Marginally valuable applications got tabled at the end of the 5 or 50 user-demonstration time-box.

As a result, we grew the group from the initial 10 folks to the 150 person organization in IT in just 18 months.  (See the internal brochure we used to drive business to our group – (BTW, this was really fun to research on the Internet – such good memories.)

QSMA Agile Impact Report showing Agile teams 25 to 50% faster versus 7,500 other projects

50% Faster Time to Market OR 50% Less Staff?

It was all about Time to Market (TTM) for GV Labs and for most folks adopting Agile in this decade.  However, now with the cost-cutting focus of these turbulent times, we see many organizations trading off some of the TTM for cost savings.  As a result, they will use fewer Agile teams on a project and deliver a lower throughput per agile, time-box cycle.  In many cases they are using fewer people, because they have fewer people due to staff cuts.  (If you have not taken staff cuts and are wondering how to do that and maximize your Agile success, read an earlier article of mine on TechTarget – Cutting Your Way to Increased Agility and my post on Israel Gat’s Social Contract for Agile Software Development)

Of course this is a continuum of speed and these savings exist in either getting done faster with more or getting done slower with less.  You and your organization should be careful to consider the total cost and benefit of the project when right-sizing the team size to completion date. There is an optimal range for most projects and with true agile project teams you get the benefit of adjusting this based on actual performance over short time-boxes.

To gain these benefits, you have to actually become Agile and not just adopt some of the practices. Agile means dedicating you and your team to learning and continuous improvement.  We did it at US WEST in the 90′s and QSMA shows how many of our customers are doing it today.

If you truely become agile in these times, you can accelerate out of this downtrun smarter, stronger and leaner.

Further Reading:

• Brutal Prioritization in Agile: cut costs by NOT building the fluff
• Agile Cuts Costs by a  Factor of Four – or More!
• How Does Agile Deliver Time to Market Improvements of 50%?

Back in 2007, Jean and I developed an evolutionary model of Agile adoption for teams and organizations seeking the benefits of “scaling software agility.”  We presented talks on this at the Agile 2007 and Agile 2008 conferences.  We call it Flow-Pull-Innovate based on the Toyota Lean principles of Flow-Pull-Perfect.

Productivity gains in Agile development teams come conceptually from eliminating waste.  Just getting to the first step of Agile maturity can lead to 10 to 20% productivity increases.  We want you to be successful taking the first step, and there is a ton of opportunity in most software development shops. According to Tom and Mary Poppendieck, most software development organizations are only spending 6% of their time doing value-added tasks.  The other time is wasted in these categories:

• Partially done work (coding features that get removed from release)
• Extra processes (elaborating requirements that do not get built)
• Extra features (features that are rarely used – more on this in another post)
• Task switching (across multiple projects – losing flow)
• Waiting (requirements, designs, feedback, builds, other teams, larger organization, customer)
• Motion (walking over to interrupt folks for a build or status)
• Defect (internal or external)

Agile works to systematically address these wastes as you mature.  In our white paper on moving to Program Pull, Jean and I characterize the steps, roadblocks and benefits found at each step in the Flow-Pull-Innovate maturation process.

On the move to Flow, we find that teams can increase their productivity working as a dedicated team on a single project for a two-week iteration cycle.  The reduction in waiting, motion, task switching and partially done work can be dramatic based on your level of multi-tasking.  We even find some teams in Flow reduce their extra features, partially done work and defects, but those productivity gains tend to be more associated with the move to Agile Pull.

According to the QSM Associates study of Agile development teams, you can expect to save 16% (the green dots on the graph). Of course the teams that worked with Rally’s products and services achieved on average 25% productivity gains (the red dots on the graph).

(The graph on the right from QSMA shows a white line of the average productivity of different sized projects in their 7,500+ project database. Between the blue dotted lines is the area 1 standard deviation from the norm.  You can see only one Agile project was less productive that the average and  7 Agile projects of the total 29 were outside 1 standard deviation. Thus 1/4 of these Agile projects were in the top 16% of all projects ever benchmarked by QSMA – see Michael Mah’s blog for more discussion – OptimalFriction)

Of course,  you cannot have your cake and eat it at the same time.  That is, you cannot just start running two-week iterations and become 20% more productive overnight, but with a combination of services and Agile project management solutions, you can attain these results in months. That is why we recommend a two-pronged approach to cutting costs with Agile and Rally offers a Guarenteed Succes program that combines our world class services and application in a discounted bundle for new and existing customers.  Get started by getting your teams to Flow and the savings can come fast.