And the number #1 Characteristic of an Agile Organization is…
“The Commitment to be Great”
The ability to make the commitment to be more than just good comes from the ability to drive a culture of discipline that balances the metrics of profitability and reputation. Hopefully you have seen and heard that message come through in the other items in our top 10 list; I applied these concepts from Jim Collins’ in “Good to Great.”
“Greatness is not a function of circumstance. Greatness is largely a matter of conscious choice and discipline.”
In the world of software development, an agile organization does not settle for having agile stuck in ghettos. An agile organization makes the commitment to go up the learning curve and blow past amateurism. As Jim describes this takes an organization that can increase the discipline to support increasing levels and scale of agility. Discipline to:
Regularly plan at the five levels (daily, iteration, release, roadmap and long-term vision)
Regularly make and meet the commitments you make based on a sustainable pace
Regularly inspect the progress & metrics and adapt the plans at each level
Make decisions based on the data, culture, and purpose
As Alan talks about at Amazon, it was just the OK from management that was needed. As Israel talks about at BMC, it was a Social Contract. You know what kind of commitment you need at your organization to scale agile. You need to get it to really improve and make your transition happen. Please, don’t settle for a weak commitment. It leads to isolated adoption, ghettos, and a slow, muddling adoption process. Scaling agility beyond just the development teams can be simple and rewarding, as long as you start with the commitment.
Here is a quick refresher of the complete Top 10 list:
At Rally, one of our core values is “Create your own reality.” In this 3 minute video, I talk about how successful Agile organizations embrace a practice of holding a corporate vision and yet encouraging people to find where they can best bring their talents to bear. In a traditional organization, a corporate vision may be the source of very strict, very detailed role descriptions and role assignments. The corporate vision in an Agile organization acts as a guide for how to help people contribute their best work for the overall corporate goals.
Watch my video for more about why I truly believe in both “Create your own reality” and Corporate Vision as key success factors in Agile organizations.
With regard to the video reference to Jim Collins, you can read the interview about his new book and his personal rhythm on the NYTimes site. Verne Harnish’s Gazelles.com teaches the Rockefeller Habits on business rhythm.
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.
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:
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.
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:
Beginning Agile team in Flow benefiting from the 25% productivity savings of an Agile teams in the same study
Intermediate Agile team in Pull with incremental releases of value
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:
Good waterfall team – ROI – 0.8
Beginning Agile team in Flow – ROI – 1.4 (1.6 factor better than good waterfall team)
Intermediate Agile team in Pull – ROI – 2.6 (3.2 factor better than good waterfall team)
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.
There was much to celebrate as an American last Tuesday. The President’s speech took me back to core values and principles. This quote struck me hard as we work through this recession.
“Those ideals still light the world, and we will not give them up for expedience’s sake.”
In the flurry to find ways to take cost out of the business quickly, it is very easy to get carried away and have everyone run to the cost-cutting side of the boat. There are two things to watch out for as your company’s suggestion box fills-up:
Selecting quick fixes without an eye for the long-term implications or unintended consequences
Letting your goals or values drift in the short-term at the expense of true on-going success
Cover of HBR Article on Core Values
If you enjoy the writings of Jim Collins, like this Harvard Business Review classic , you believe that only with the guidance of core values and principles can you make the tough decisions needed to steer through this rough time.
Again, from the new President’s inauguration address:
“Our challenges may be new, the instruments with which we meet them may be new, but those values upon which our success depends, honesty and hard work, courage and fair play, tolerance and curiosity, loyalty and patriotism — these things are old.”
For many software-driven organizations, I believe Agile development is the “new instrument” to meet these new challenges. Now for the good news – since core values are “forever,” these certainly do not need to change with even the largest scale Agile adoption across the software development lifecycle.
The NPR (National Public Radio) inauguration coverage of President Obama got me thinking about patterns for 2009. First, I was enjoying the notion that Obama created today as a national day of service (see a new clearinghouse for local service opportunities at www.usaservice.org and www.mlkday.gov), but I was lamenting that I did not have enough time to drum up some organized effort at Rally or with EFCO.
Listing of Service Opportunities around Boulder, CO from USAservice.org
My Start, Stop and Keep Doing List
That got me thinking about my focus for 2009. Over our holiday week off at Rally, I took time to create a Stop, Start and Keep Doing list, which is a practice encouraged by Jim Collins, among others.
For example, one of the things on my Start Doing list is to be the Executive Director of EFCO, working on scaling my dream around socially responsible businesses. I’ll focus more on corporate social responsibility later, but for 2009I think folks who are employed should all be focused on their Stop Doing list.
RallyDev.com
And the number #1 Characteristic of an Agile Organization is…
#4 in our list of the 
and CMM. What Jean and I present in our whitepaper titled “
