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.
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-Incountered 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 Greekoxy (”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.
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?
Last year I entered the Marine Corps Marathon. I’d never run more than 10K in my whole life, but I felt the urge to do a marathon at least once. And of course I didn’t want to just finish. I had to get close to my friend Dave’s time who did 3:17 in the Loch Ness Marathon.
Runners in the Loch Ness Marathon pacing themselves
So I started an ambitious training program. As time progressed and I was not getting any faster, I started training harder. Four weeks before the race I had to pull out with a stress fracture and slightly torn Achilles tendon.
As an Agile coach, I had failed to heed my own counsel.
I tell my students that the number one cause for failure with Agile development is scaling too fast. Always start with baby steps.
Similarly with Agile teams, the optimal conditions and fundamentals of the method are:
Deliver highest value first
Release early and often
Shared vision
Empowered collaborative decision making
Engaged customer proxy
Sustainable pace
The benefits of Agile are:
Deliver highest value first
Release early and often
Shared vision
Empowered collaborative decision making
Engaged customer proxy
Sustainable pace
Plus more energy!
I realize now that if I’m headed the right direction with the fundamentals, I will reap the benefits without the burnout. This year I’m entered in the marathon again, but I’m going to take it easier with the training and not care where I finish in the race.
Same with Agile – get headed on the right path, pace yourself, look back often to check your process and you will achieve your goals.
I believe that Agile project management in small, co-located teams crossed into the mainstream back at the sold-out Agile 2007 conference, but Agile program management at scale is just now heating up. Last week’s article on eBay’s Agile adoption in Business Week (combined with other recent news) shows us that organizational agility is becoming a mainstream topic at the highest levels.
The market is no longer asking, “Can we scale Agile across the enterprise and large distributed teams?” and instead is asking, “How do I get there?” and “Who can help me?”
BusinessWeek asks, “Can eBay Get Its Tech Savvy Back?”
Watch the video of eBay's Mark Carges on BusinessWeek.com
Author Douglas MacMillan says: “Carges’ plan for eBay is to take the “agile” method of software development epitomized by the daily deal widget and expand it to other areas of the site. New product pages will be customized to better accommodate different categories, such as jewelry and clothing. And the company is helping third-party developers create applications for eBay’s site such as a UPS-branded terminal for monitoring shipments” Read the full article >>
Author Note: Mark Carges was my boss and mentor at BEA. I know a good bit about his current efforts and they are really going for it at eBay and PayPal. It is great that their enterprise agility efforts will unfold in public eyes.
In other mainstream signs of Agile…
I was excited to see a couple of other great articles on Agile this week, including:
Marketers often say you’ve reached the mainstream market when you notice your peers are doing it, and you feel behind enough to move. InfoWorld’s Paul Krill noted in his article Software Companies Jump on Agile Programming Bandwagon how many providers are “eager to hop on the agile development train.” (Clearly, we have an early mainstream market now.) See my post about traditional providers, including IBM, entering the space.
“If ever there were an ideal time to make the leap from a traditional to an agile project management approach, it’s now. In this tense, uncertain, cost-cutting environment where CIOs are watching their bottom lines like hawks, the concept unfailingly proves successful. It not only delivers consistent, excellent results on time, but often under budget.”
Finally, David Rubenstein from SD Times tackles the issue of Agile Development Built to Scale. I agree with Robert Holler that scaling anything across an entire organization is tough, and that sometimes Agile just gets a bad rap for something that is universally a challenge. It does take commitment from the team, a bit of training and a lot of inspecting and adapting to be the best Agile organization you can be.
The question these days is: how good do you want to be, by when, and who’s the best partner to get you there?
As part of our goal to have a zero carbon footprint by 2020, we calculate our total carbon footprint each year including building facilities, travel, commuting, IT and waste. As we get more accurate every year, we are adding in the impact of using Software-as-a-Service (SaaS) to that calculation. I have been unable to find a benchmark of other SaaS companies carbon footprints, so I am putting out a call for SaaS companies to share their footprint per user.
Rally’s benchmark – 8 tons of CO2 per year for every 100 users
At Rally, we have been growing steadily (227% in 2005-2007, 242% in 2007-2009) at the same time working hard to limit our carbon footprint. Unfortunately, as a company grows, its carbon footprint often grows with it.
We have been able to keep carbon per 100 users flat at 8 tons per year for the last two years – the same amount produced by a single person flying from New York to Deli, India round trip 4 times. In addition, we estimate that our SaaS customers are avoiding an additional 1 ton per year of CO2 as compared to running an application in a robust manner in their own data center.
What is your SaaS carbon footprint per 100 users?
Lacking any other information, I used our figure – 8 tons per 100 users per year – to calculate our carbon use per 100 SaaS seats for each of our SaaS suppliers including: Google Enterprise Apps, Salesforce Unlimited, NetSuite, Big Machines, Eloqua, Xactly, and Open Air. I assume our numbers are conservative because we are not the scale of the Google or Salesforce, and we count airline miles and employee commute in our footprint. Can any other SaaS providers tell me your carbon per 100 users to increase the accuracy of our calculations?
Like Salesforce, we buy renewable energy credits from NativeEnergy to offset the carbon of hosted operations. This is a very small portion of our overall carbon footprint - about 7 tons per quarter. However, it does a couple of things for us: 1) It supports our SaaS service being carbon neutral since 2008, 2) It keeps us learning about carbon credits at a national and local level, and 3) most importantly, it keeps us focused on our goal of zero carbon by 2020.
Do you want to partner?
In addition to our efforts to battle climate change in our industry, we are also working hard in social responsibility by following the 1% model started by Marc Benioff and Suzanne DiBianca at SalesforceFoundation.org. Last year, we hit our 1% target of volunteer time with over 2,500 hours helping 90 charities. This year, we are in search for a strategic non-profit partner to help us focus our corporate social responsibility efforts and volunteer time in one of three areas:
Reducing the environmental burden from the IT industry (carbon, e-waste, toxins, take-back efforts)
Decreasing the digital divide in society (universal access to the Internet)
Increasing the level and engagement in corporate social responsibility behaviors
If your non-profit believes it can leverage the 3000+ volunteer hours from a company in Colorado, North Carolina and the UK to help on one of these efforts, please contact us. We are looking for a true partner who wants to start developing a relationship in 2009.
The importance of sustainability at Rally
Our efforts are based on trying to stand on the shoulders of Ray Anderson from Interface. See Ray’s Fortune interview on pushing through on sustainability in light of the current economic crisis that is radically affecting his commercial carpet business. Since then, Google’s efforts and Salesforce’s efforts in the SaaS IT space have kept us moving forward.
We look forward to driving zero footprint data centers, increasing remote collaboration technology and having a zero footprint campus in the next decade. We are preparing a sustainability report for 2008, following the Global Reporting Initiative format. It is not a small project, but it was the clear next step for our sustainability efforts that started in earnest in 2007. Our goal is to release it by July 1st so stay tuned.
ADDED After Publishing and based on comments:
A better video of Ray Anderson is his speech at TED in 2009, it gives more background, and more data. – Thanks to David Koontz
Graphic below to provide clear breakdown on sources of Carbon in our business – 6/17/09
Last week I attended the Agile Success Tour in Santa Clara, CA. I noticed 5 themes to the discussions and breakout sessions with the nearly 200 software and IT leaders in attendance.
Catch the next event in Atlanta on June 25. The event is free, but registration is required.
1. Product Owners are very important
Waterfall product marketing will find it difficult to adapt to the new responsibilities of Agile teams, unless they learn what is expected of the Product Owner. An absent or uneducated Product Owner can handicap a project before it even gets started.
2. For Agile to be successful, you must gain consensus and commitment
When rolling out new Agile teams, you must get consensus both from the team members converting to Agile and your management. Everyone involved needs to understand that growing pains will occur, but ultimately lead to higher performance. In addition, you must dive in and get started with a “burn the boats” mentality that prevents anyone from considering turning back. See Jean’s post on 12 Agile Failure Modes for more on behaviors that can inhibit your success.
3. Distributed teams, though popular, are hard to make successful
With obstacles like quality of life, cultural and time zone differences, and the drag from waiting for decisions, distributed teams pose special challenges that require Agile teams to inspect and adapt with respect to all. Team building at each location, enhancing communication, mentors, travel, group pictures, and sharing the load all help break down barriers that can prevent distributed Agile teams from reaching their potential.
4. Successful Agile adoption can help companies realize quantifiable benefits
Jean Tabaka shared how companies who are adopting Agile development are seeing significant cost savings in their development organizations with faster ROI, improved time-to-market, and increased productivity. In tough economic times, speeding up Agile adoption to help companies realize cost-savings quickly is more critical than ever before.
5. An Agile community is a valuable tool
Agile development may have simple values, but it is not always easy to implement. Capitalizing on the “wisdom of crowds” and learning from each other’s experience are key to avoiding common pitfalls.
Last week my fellow blogger Jean Tabaka spoke at the Bay APLN about one of her more controversial topics – the 12 Agile Adoption Failure Modes. Check out this great post from Aaron Sanders that distills her presentation.
My personal favorite is #11 – Revert to Traditional
Aaron says about #11, “Change is hard. Hit the threshold where this sucks. Revert back to old ways of doing business.”
In this statement, Jean is referring to Kathy Sierra’s work on “How to be an Expert” and what Kathy calls the “Suck Threshold.” Jean has seen first-hand that many teams can slip into complacency and ultimately fall back below the “Suck Threshold.” At that point, they may give up and revert back to traditional process. Classically we see this happen right around 1 1/2 years because too many of the other adoption failure modes pulled the team or teams down.
But there is good news…
I highly recommend reading Aaron’s post to determine what failure mode might be working against you. Once you can name them, you can take the necessary steps to address them.
Special thanks goes to Aaron, who is joining Rally as a coach in July – we are all looking forward to seeing him at our quarterly coaches off-site. And also thanks to César Idrovo and David Chilcott from BayAPLN for their help with the talk and our visit to the Bay!
The MoSCoW technique for backlog prioritization has its flaws
It’s OK Sergey and Boris. I’m not referring to the capital city of your homeland with its rich history of classical music, literature and sporting heroes.
There are a couple of problems with this technique, and in my classes my students spot them right away.
The customer always thinks everything is important, and therefore the distribution of the backlog items is hopelessly skewed towards the Must Haves.
Let’s say we are planning an iteration. We have only room left to take on one more backlog item, but we have two Must Haves. Which one gets planned into the iteration? Of course we should ask the customer, but what if they aren’t there?
Many customers think that promoting backlog items to Must Haves is exercising better control over delivery, but in fact it is not. A customer who cannot differentiate between the importance of backlog items is ceding control to the delivery team. Work has to be sequenced, and if the customer will not choose then the team will.
A better technique is to rank backlog items such that no two items have the same priority. In this instance, it is very clear the preferred order of delivery.
On our recent webinar “Demystifying Cloud, The Next Generation Architecture” we had a number of thoughtful and tough questions related to security, intellectual property and risks. We provided answers to these questions in the recording, but I found the recent SD Times article “Cloud Providers Answer Tough Questions” an even better source. In this article, a number of experts on specific platforms from Microsoft, Google, Salesforce as well as Rally’s own Zach Nies answer questions about security, lock-in and IP.
Henry Ford didn't foresee the impact of the first car - do we foresee the true impact of the Cloud?
Daryl Plummer from Gartner also did a great job recently describing the real point of cloud computing as he reviews Russ Daniels recent Forbes article. Russ says:
“In my view, the ability to facilitate innovation and entrepreneurship in this new model is one of the most promising ways to ignite the next wave of economic growth. We can no more see the full impact of the cloud than Henry Ford foresaw the impact of his desire to produce more cars in less time.”
As a result of SD Times’ tough questions and our desire to “ignite the next wave of economic growth,” we decided to talk in our next webinar with Global Logic and IBM about how to go to the cloud and mitigate risk along the way. As with any pilot, the goal is to enter wisely, learn fast and then move forward. Given the iterative and incremental method of Agile is best suited for this fast-learning approach, we will title our next talk “Going to the Cloud – the Agile Way.”
We are structuring the content now, but I would love to hear your ideas, questions or feedback on this topic. I will also post a registration link for the webinar as soon as I have it.
Thesis: Taking a learning-first approach to your cloud efforts can help you avoid the risks of vendor lock-in, IP security and a spectacular failure
Proposed Agenda:
Review the innovation, benefits and risks
Typical approach – Choosing early, over selling, dramatic big bang
The Agile/Lean approach – Set-based, scientific and learning-based
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.
RallyDev.com
#4 in our list of the Top Characteristics of an Agile Organization is about the importance of Flexibility and Rhythm.
Agile Adoption Failure Modes. Check out this 
and CMM. What Jean and I present in our whitepaper titled “
