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.

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.

2008 was a very good year for Rally, the Agile development movement and me personally.

At Rally, we measured ourselves by winning the third consecutive Jolt Product Excellence Award and delivering 6 product releases to a fast-growing list of great software-driven companies.

We leveraged our Agile and customer community and new products to deliver feature priorities based on our customer’s feedback and votes.

With the help of QSMA, we benchmarked that Rally customers are 50% faster to market and 25% more productive than industry averages.

On the local front we were named one of the best companies to work for in Colorado as well as awarded the Affiliate of the Year by the Entrepreneur Foundation – these are awards we strive for and help us validate we are building the type of company that can endure.

You can see the customer and financial growth that resulted from these market achievements in an announcement we issued this morning, or you can go to the Rally by the Numbers page on our web site to see the transparency we use to communicate our progress.

On the Agile industry front, the Agile Alliance had a blow-out conference in Toronto in 2008.  It was the culmination of my two years on that board and a very fulfilling experience.

We also saw this market grow with new customers and a host of incumbent as well as new competitors.

The Agile tools and applications market became real and Gartner put out a market map as a prelude to a magic quadrant; good news Rally was ranked in the “Positive” category.

What key performance indicators (KPIs) do you use in your business, and how will you improve or adapt them in 2009?

At Rally, we’ll be busy doubling our efforts to make our customers successful with Agile and effective on both prongs of short-term efficiencies and long-term growth.

Right now, we are all working through our 2009 budget process with the unknowns of the economic recession staring us in the face. This budgeting cycle holds more unknowns than we’ve seen in awhile, so it’s making everyone cautious about finding the right moves that will cut costs in the short term without damaging our businesses.

Unfortunately, layoffs may be part of the solution to achieving short-term savings, especially for firms hit hard by the recession. In short, layoffs suck. These highly personal actions are sad, and I am sure you and your staff may need some time to grieve the losses. But prior to cuts, there is a bigger issue to consider while managing belt tightening -– your long-term vision and direction. Put simply, it is imperative to refresh your 2009 vision before the cutbacks, or you risk destroying the morale of the whole team, losing key personnel, and dropping market share.

As you look to make cost-saving cuts, the first question is, how are you going behave?

1. Take the easy way out and cut in a way that fixes the short-term at the risk of harming your long-term prospects. “Across the board” cuts fit this behavior.
2. Rise to the occasion and cut in ways that meet short-term needs and advance your long-term goals.

On Nov. 9, Rahm Emanuel, the new chief of staff for President-elect Barack Obama said, “Rule one: Never allow a crisis to go to waste… They are opportunities to do big things.” Clearly Mr. Emanuel is reacting by rising to the occasion – scenario number 2.

The trick to taking advantage of this crisis is to resist the pressure to simply cut without a long-term plan that everyone understands. When you do not have long-term goals, short-term fixes always lead to unintended consequences that are typically worse than the original problem. Said another way: While we sometimes get some of the intended consequences, we always get all of the unintended consequences.

A key goal of every IT department is to reduce the time and effort needed to deliver value to the business. To accomplish this, the best long-term trend we have in IT beyond Moore’s law and the power of the Internet is the improvement of IT agility. Increasing IT agility is important because it provides a value innovation and delivery method that harnesses these fundamental advances in infrastructure.

Tom Poppendieck, a leader in the Lean IT movement, recently said, “You can’t cut costs by focusing on cutting costs. You’ve got to focus on the changes that will lower your costs over the long run.”

If you are exploring the adoption of agile software development practices and you’re prepared to rise to the occasion, this recession and the resulting belt-tightening gives you an opportunity. You have the opportunity to rally your company around a vision that will not just cut costs, but improve morale and help you grow your business in the next economic spring.

IT agility

For the 70% of you who have not adopted enterprise agility, let’s do a quick overview. Agile practices enable teams to build less, but return the same value by focusing on early delivery of the features that have the highest business value and not wasting money on the features that don’t.

IT agility is driven by three major innovations: agile development, Software as a Service (SaaS), and Web 2.0 social networks. However, without agility in development and software releases, the innovations of service-oriented architecture (SOA) and Web 2.0 are elusive.

There are three costs savings for enterprise IT agility proven through benchmarking analysis:

1. Lean flow provides more productive development organizations.
2. Better prioritization delivers the most valuable software first.
3. Faster time to market and incremental delivery returns income sooner.

To realize those benefits, you and your team must develop, communicate and implement an effective agile enterprise adoption driven by a highly visible roadmap. Since the late 90s, agile adoptions have followed a ground-up and incremental funding approach as early adopters proved the benefits and scalability of agile in the enterprise. Starting in 2005, leadership-led or top-down approaches have begun to dominate the scene. These larger and more systemic approaches are required for organizations that need to act fast to derive short-term gains.

For managers and directors doing their budget planning now, the next three sections outline the proof points for agile, a roadmap to enterprise agility, and the implications on this roadmap from having to make savings cuts ahead of investment.

Proven impact of enterprise IT agility

Many large and distributed development organizations have proven the positive financial impact of agile over the past five years. These findings were quantified in the Agile Impact Report. In that study, QSM Associates benchmarked Agile teams against a database of 7,500 projects and delivered the following results. On average agile teams working with Rally were 25% more productive, had 50% faster time to market, and delivered one-fourth the number of defects. (Those teams not working got 50% of those results.)

Given those improvements, it is becoming a business imperative to adopt agility, especially on your mission-critical applications. In the face of cuts and with a long-term outlook toward enterprise agility, you can now see your way to a 25% savings in 2009.

Enterprise agile adoption roadmap

Like any mission-critical systems or initiative, you need a vision and roadmap to steer your adoption and rally the troops. During the past four years, an approach fashioned from Lean manufacturing concepts and adopted in an incremental approach has proven very effective. The following illustration depicts that method.

There are three keys to effectively managing this process:

1. Work incrementally, in an agile fashion, through the steps and gain proficiency before widespread scaling.
2. Develop a vision/roadmap and change backlog with key executives before you attempt to move up to step 3 and beyond.
3. Share the vision and roadmap with the entire organization and manage the rollout in a collaborative fashion with complete transparency.

Many of these rollouts have started with a grassroots effort to get to Step 1 and Step 2. With the help of external coaching and parallel tool rollouts, many companies have taken more aggressive, “flash-cut” moves with top-down leadership and investment to jump to step 3 in the roadmap within months.

Flash-cut approaches

Given the pressure and opportunity of this crisis, as well as the increasing number of public proof points showing how large organizations can quickly transition to agile, you might be thinking about your ability to do accelerate your adoption and capture savings in 2009 from your efforts. From my experience, there are three things to heed while considering this:

1. Adopting agile needs complete management buy-in and a true sense of urgency. Many enterprises that have done this have used phrases like “burn the life rafts.” A recent Gartner report, “Case Study: Inovis Uses Agile Methods to Accelerate Product Development,” says, “The ‘big bang’ adoption approach is high risk, but it works in companies or business units with high levels of risk acceptance, and it can manage the ensuing organizational change.” What is it going to take for your management team to get buy-in to adopt Agile on a major portion of your organization? I assume the current recession will amplify any existing business needs.
2. You are going to need a strategic partner to help you manage this organization change effort. I do not know a company that followed the flash-cut approach without an outside coaching or consulting firm. As a result, you will have to budget for this investment and the time to choose and schedule them. These partners will help you build the organization capacity for agile while also supporting the professional development of your middle managers as the organization becomes flatter and leaner.
3. This is a whole system change from a world of plan-driven to value-driven ideas. As a result, you will see immediate changes in your process, organization, and technology. This transition will set up a culture of continuous improvement and even drive changes in your overall development and business strategies. To make this transition go well, you are going to need to implement a collaborative project management solution to provide visibility across your development teams. Enterprise IT agility does not scale or distribute around the world without it.

Don’t waste a crisis

We don’t know how long or how deep this recession will be. Belt-tightening and staffing cuts almost seem inevitable. You can either reduce costs by just cutting your budget, or you can use this opportunity to make systemic changes in your business. I strongly urge you to make your cuts in parallel with investment in the long-term to avoid fixes that fail.

Provided you have a longer-term vision of your organization around agile software development, some outside coaching to help accelerate your adoption and solution for distributed management, you can take advantage of this crisis to make big changes very quickly. Enterprise IT agility is proven to do that — more so than investments in technology point solutions that only have a point in time savings. Most important, this approach will help ensure the savings from today’s cuts do not create worse problems in the long run.