Agile Development Blog

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.

When we started with Scrum at Rally years ago, we used to just do a design meeting every few weeks with a couple of key stakeholders to talk about what was coming up and prepare the backlog.   This worked relatively well, but as we added more discipline to our release cycle, the ad-hoc backlog planning our Product Owners were used to started to break.

If you want your team to be able to make a commitment around 8 weeks of backlog, you need to do somewhat more prep than you would with vanilla Scrum.  And if you want your team to meet that commitment, you need a mechanism to manage your stakeholders to minimize backlog churn.

About a year ago, we chartered a Product Council to solve this problem.  The Product Council is led by the uber Product Owner for each product, and consists of stakeholder representatives from all interested departments.  This team operates as lightweight Scrum that grooms the backlog for the next release, working in 4 meetings that are 2 weeks apart.

Meeting 1: Retrospective on the last Release

The first meeting falls about a week after the engineering team does Release Planning.  The Product Owners review the plans for each Scrum, talking through the stories for the stakeholders.  We’ll also highlight the work that definitely does not fit into the release.   Usually we have commitments from the development team as to what will be delivered.

We then ask people to rate how they feel about the product (what we plan to deliver) and the process (how we decided).  We tabulate these numbers, and then move on to a regular retrospective on the process – what went well over the last 8-week cycle, what didn’t go well, and what should be changed going forward.

Meeting 2: Bring Your Ideas

In the second meeting, we hang the roadmap and various backlogs on the walls – usability, platform, deferred defects, technical debt, customer requests, etc.  The Council spends about 20 minutes “walking the walls” – reviewing the roadmap and various backlogs.   People add items they think are missing, shift items forward where necessary, and talk about issues and concerns.  The purpose of this meeting is to identify those items the Product Owners should research for the next release – we usually leave with about 10 epics that need investigation.

Meeting 3: Presenting the Design Continuums

The Product Owners spend about 2 weeks researching those key epics, and come back with rough design continuums (backlogs) for each one and high-level estimates.  In Meeting 3, they present these ideas.  Sometimes an epic is too complex or unknown to be considered for the next release, or perhaps it’s too expensive to build given it’s value.  The Product Council votes to rank the different epics.

Meeting 4: Presenting the Detailed Backlogs

Based on the voting from the last meeting, the Product Owners go off and begin blending the strategic epics from the Product Council with small customer requests, deferred defects, and other small items.  In Meeting 4, we present the detailed, forced-rank backlogs that we intend to present to the development teams in Release Planning.   We talk about what’s changed and see if there are any last-minute, “Stop the line” type shifts that have to happen.  We get a fist-of-five commitment from the Product Council to confirm their support for these backlogs.

Moving forward, I’ll post more details about how these specific meetings work.