In the last couple of months, IBM (via Scott Ambler) has blogged, hosted webinars and talked to the media about an Agile process maturity model (APMM). I am sure this will hit a new height today with the start of the Rational Users Conference and the release of the e-book. I have been asked to comment on this work by a number of press and analysts. Since my perspective will be published shortly, I thought I would go on record.
IBM splashes its way into Agile development
As the Agile market grows and takes hold in truly mainstream audiences, everyone is looking for easy, step-by-step guides to smooth Agile adoption. IBM is proposing one option under the name “Agile Process Maturity Model.” I think it is a nice marketing strategy for selling IBM’s Rational Team Concert products to companies that want to adopt the Jazz platform, copying their 90’s success with RUP. But I don’t believe it is actually an Agile process maturity model, and further, Agile doesn’t need one.
IBM’s proposal for an Agile Process Maturity Model
Scott says, “The goal of the APMM is to help categorize and understand agile processes, not to rate your adoption level (the CMMI Defined approach can address that need).”
He continues, “Unfortunately, the term ‘maturity’ is a loaded one within the software process realm, not the least because of the Software Engineering Institute (SEI)’s Capability Maturity Model Integration (CMMI). A lot of good work has been done to show that agile and CMMI can be applied together, and I look forward to seeing that strategy come to fruition. However, where the goal of the CMMI is to provide a framework for software process improvement the goal of the APMM is much more modest – it merely strives to define a framework which can be used to put the myriad agile processes into context. In short, the APMM and CMMI are orthogonal to one another…”
I am confused by the title and the orthogonality, so let’s peel the onion on this one.
What is a process maturity model?
The origins of process maturity models come from the manufacturing industry, but the software version was created in the 1990’s by Carnegie Mellon’s Software Engineering Institute (SEI). It is well known as three Capability Maturity Models – CMM for software, CMM for people and CMMI.
If you read Watts Humphrey’s work, you will see this is a management framework that measures the level of discipline of your organization. In essence, organizations that are certified Level 5 have implemented continuous improvement and have the disciplines and practices in place to effectively manage large complex projects with effective controls. The framework does not say anything about how the software should be developed. I make no claims to being a CMMI expert, but you can read a few of the “CMMI agile” search results to see how they work together.
Though not the stated intent of the framework, it has been closely associated with waterfall development and used to defend heavy process approaches. I disagree with that belief and prescribe to Jim Collin’s model of blending discipline and agility together to move from good to great. I think the CMM framework is a great checklist for organizations measuring their level of discipline… and we don’t need another one.
The 3 levels of IBM’s APMM
Scott’s APMM post describes three levels:
Core Agile Development
Disciplined Agile Delivery
Agility at Scale
I struggle to see how these three labels or the supporting details provide a framework that helps categorize and understand Agile processes. These titles grow in scope and scale, but do not speak to increasing agility. (Faster cycles, less waste, less work-in-progress, more value.) When you look deeper, it smells of a cookbook of when to apply processes and tools from IBM. That is fine, and I agree customers need this. However, I would argue this should not be used to guide companies in their Agile adoption.
By mashing size, scope, increased agility and disciplines on one scale, the APMM does none well. In addition, it will lead to amateur implementations where continuous improvement mentality never sets in. Where adopting scaling software agility is thought to be just a transition from A to B. To me that thinking is very limiting and will lead to gains followed by declines.
IBM in the Agile space – all good
I am thrilled with IBM’s entrance into the Agile space with their Jazz platform and related products – really. When I was at BEA/Weblogic, I can tell you that we did not have a market for Java Application servers until the industry’s gorillas, IBM and Oracle, entered for real.
During this year, Jazz and its supporting products will actually manage the workflow of projects in a way that works with Agile development instead of against it. This is huge change from the ALM 1.0 point products that actually reinforced the silos and phased approaches that created queues, caused hand-off delays and kept quality as an after-thought.
The IBM gorilla in the software development space will make the Agile sea rise and help break down major organizational barriers to bringing the benefits of Agile practices and tools to the mainstream development community.
There is no cookbook for adopting Agile
I believe that enterprises need an adoption model that helps them balance discipline and agility in an incremental fashion that creates incremental success and fuels continued investment and improvement. The enterprise Agile adoption model Jean Tabaka and I have synthesized is based on Lean concepts and is rooted in Deming’s work, just like Watts Humphrey and CMM. What Jean and I present in our whitepaper titled “Leaning IT: Moving to Program Pull” is how to move up the adoption curve of Agile by learning quickly, maturing before scaling and working incrementally.
This transition planning framework focuses on attaining benefits of agility by moving to lean states of flow, pull and ultimately the perfection of continuous innovation before adding the disciplines necessary to scale. It discusses the general steps, but does not prescribe a change approach to organizational, technological, process or strategy transitions. Your approach is dependent upon your corporate and technological situation. We recommend an iterative approach, facilitated by experienced coaches and peer support.
What does the Agile community need from IBM?
Mary and Tom Poppendieck’s new book called “Leading Lean Software Development” (out soon) has tremendously strong stories, models and insights from bringing lean concepts to software. In chapter six, they highlight a success story from working on lean with Sue McKinney at IBM. This success story, along with the Eclipse success stories, are critical for IBM to be telling the market regarding the impact of Agile and Lean in the large inside IBM.
In 2008 and four years after IBM started developing Jazz, we talked to IBM about integrating Rally’s award winning Agile Lifecycle Management solution onto IBM’s collaborative development platform, called Jazz Foundation. They said no, you have to wait until the GA release of Jazz. This would be a similar integration that we provide to Microsoft Team Foundation Server for managing code check-in’s and automated builds with a slick interface into the IDE. I am hopeful that IBM will GA the 1.0 version of the Jazz Foundation for partners to actually integrate with. They are saying all the right things on the Jazz.net site, here is hoping for some positive news at this week’s Rational User’s Conference. Finally, I am very excited about IBM’s global dialogue on Building a Smarter Planet. IBM needs to do a better job telling the story about how software agility is a critical component to building that sustainable planet. (It was nice to see the smarter planet splash at the front of the ebook, but it still represents a huge missed opportunity.)
What do you think? Does Agile need its own process maturity model?
Again, I was surprised by the title of IBM’s Agile Process Maturity Model and hope they will consider changing it before more marketing dollars are spent. It does not improve on the CMM, nor in my opinion does it help CMM certified companies adopt Agile. I assume IBM has a huge role to play in helping those CMM certified companies add agility and innovation to their highly disciplined organizations. If they don’t, we are glad to help today.
Jean and I made a commitment this quarter to go deep on Lean software development. We have been working with Lean and Agile for years, and really want to engage you in a dialogue to help explore the topic of how they relate.
Jared from Subway on his exploration of a different type of "lean"
To help focus our research, tell us, what are your favorite resources for Lean and Agile?
I don’t want to bias your feedback too much, so here are a few of our current favorite resources as a jumping off point:
Lean.org – Jim Womack’s site about Lean across industries
I’ve been thinking about leaning a lot lately, and not of the pressed-wood bookshelf nuisance variety. I talk about Lean with my colleague and President of Rally, Ryan Martens. So when I talk about a leaning bookshelf, I’m referring to my interest in Lean in all its forms. I am talking about the books I’ve been reading that pertain to Lean. And, more specifically, how can I turn my “Leaning bookshelf” into a continuous “learning bookshelf”? How can I think about my evolution of thought and practice with regard to Agile as influenced by Lean? What could be a good, rewarding goal?
And so, through discussions with Ryan and some of my own quiet thought, I came up with a goal of improving my notion of learning. Yes, for me, that seems to be what I am discovering more and more about Lean:
How to learn
How to teach others to learn
How to encourage organizational learning
How to avoid/eliminate re-learning
And so in this post, I thought I would share what I am reading, have read, or am about to read, and ask you for your comments and recommendations with regard to my leaning—>learning path. Some of the books may not look directly associated with Lean. I just know that they have been part of my lean learning journey.
Looking at my leaning bookshelf and thinking of my focus on learning, I realize I haven’t included any Senge books or others about organizational learning. That will have to wait for another post.
What books are important to you on your leaning/learning path?
If you have ever wondered what to do with the growing number of features in your software applications, you are not the only one. There is some useful guidance from The Standish Group survey quantifing that only 20% of all delivered software features are “often or always used.” For a team under the pressure of today’s economy to do more with less, here is a way to conceptually cut 80% of your effort and still deliver the high-value essentials. But wait it gets better. If you do not completely elaborate, build, test or document these features, you save once. But you also save again: with the future maintenance costs, the training users, the bug fixing and the regressing these features would have required. This is clearly the biggest lever for cutting software development costs using Agile. And yet it seems to be the hardest to attain.
Features used in Commercial Software - Reported by Jim Johnson of the Standish Group at XP2002
This pairing back to the simple, important few takes tons of discipline and that level of discipline is only be made easier as your agility maturity increases. Most agile books and coaches will call this the discipline of “Brutal Prioritization.” The folks from 37Signals call it: “Getting Real.” In either case, brutal prioritization means two things:
Not letting the fat slip into the backlog
Keeping the backlog prioritized by value and risk
First, lets talk about fat or wasteful features. Please note, fat or wasteful features come from all directions from the business and customers, but also from developers, support, and product owners. Your features may be fat or wasteful if they:
Do not help the most important user persona in your domain achieve breakthrough results or competitive advantage
Have not be proven to work and are based on a hopes and prayers
Look like pets that someone is protecting
Are weak features that degrade the product because they are not complete enough to meet minimum expectations
So if you are in the customer role or customer proxy role such as the Scrum product owner role, the technical product management or a business analyst role, it is your job to control yourself and help the team to keep the fat off the backlog. If you are on the agile team, it is your job to keep these roles honest about WHY these features are so valuable. This leads right to ranking the items into a prioritized backlog. (A few comments in this area would be really helpful – let’s hear what you use to spot fat features?)
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)
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.
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?
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.
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:
Lean flow provides more productive development organizations.
Better prioritization delivers the most valuable software first.
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:
Work incrementally, in an agile fashion, through the steps and gain proficiency before widespread scaling.
Develop a vision/roadmap and change backlog with key executives before you attempt to move up to step 3 and beyond.
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:
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.
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.
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.
RallyDev.com
and CMM. What Jean and I present in our whitepaper titled “Leaning IT: Moving to Program Pull” is how to move up the adoption curve of Agile by learning quickly, maturing before scaling and working incrementally. 
And so, through discussions with Ryan and some of my own quiet thought, I came up with a goal of improving my notion of learning. Yes, for me, that seems to be what I am discovering more and more about Lean:
