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?
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
Yesterday, I mentioned a Rally client team I visited that was concerned about the Rally tool’s inability to create individual team member burndown charts. We swam through that torrent of misperception only to enter a shark-infested tank around all of the overhead involved in adopting Scrum. Wait! Isn’t Agile supposed to cut costs, not add them? Big overhead sounds like cost and waste to me. Where is this overhead? We quickly zeroed in on their overhead: the Sprint Backlog. Specifically, what should be tracked in the Sprint Backlog?
To start the conversation, they told me that they are always 100% allocated. Huh? “What do you mean you assume 100% allocation?” They helped me understand that, in the Sprint Backlog, they assumed that they worked 8 dedicated hours everyday. For them, Sprint Backlog should reflect all of that time.
This was followed up with, “So how do we plan for work that we didn’t know would come up, like production issues?“ Clearly, they hadn’t read Slack by Tom DeMarco or heard of the Theory of Constraints and The Goal by Eliyahu Goldratt and the notion of buffer. So, we had a few things to clarify around this “process overhead”:
In this first post on the Sprint Backlog and using Agile to cut costs, I’ll concentrate on the first bullet:
What goes into the Sprint Backlog?
The Sprint Backlog emerges from the Sprint Planning meeting as the team:
Identifies the highest priority value items
Breaks them into tasks
Determines the effort necessary to complete the value items
Commits as a team
We cut costs by only committing to and tracking the highest priority items that deliver value in that timebox.
We cut overhead by not tracking items in the Backlog that do not contribute to the potentially shippable product increment.
So back to our overprocessed team. We opened up the Rally tool and moved to their Iteration Backlog view. I saw over 50 items, at least. And then, I understood.
The team was putting EVERY task they do throughout the timebox into the Sprint Backlog, whether it added value to the product increment or not.
Imagine having to track all of your day’s activities. Imagine having to, 2-4 weeks in advance, absolutely commit to these full days’ worth of activities. So, indeed, here was the overhead. Vacation days were in the Sprint Backlog: they had 8 hours of effort. Holidays were in the Sprint Backlog: again 8 hours of effort. The book club had to be tracked separately for each individual who attended it.
The result was that the overall team’s Sprint Backlog would show effort being completed, backlog items being marked “Completed”, the burndown chart burning down nicely, and yet no work of product value was started or in progress. This was not a tool issue; this was an Agile adoption issue.
What is the lesson in all of this?
Be careful about what you choose to track in your Sprint Backlog.
Ensure that what you commit to in that Backlog reflects the delivery of product value.
Abiding by this simple guideline will not only dramatically reduce process overhead, but it will also ensure that what we DO choose to track, whether through a taskboard or an automated tool, is work that is intended to produce product value by the end of the timebox.
Now about their allocation percentages and how it contributes to overhead. That is fodder for another post.
As you may know, I am very passionate about the concepts of sustainability. For my birthday this year, my thoughtful wife and son gave me a living example of sustainability that sits on my desk and reminds me to work on this topic everyday. It is called an EcoSphere and I got it from EcoProducts Home Store here in Boulder (they are folks who also provide all of our compostables that help us approach zero waste here at Rally – they are a great Boulder success story).
The Ecosphere is a completely closed world and is self-sustainable. It was developed by two NASA scientists (the late Dr. Joe Hanson and the late Dr. Clair Folsome) trying to create models for long-term space flight. In it you will find algae, shrimp and bacteria living in a closed cycle with sun light as energy. (Learn more about EcoSphere’s sustainable model on their site.)
At $125 for a small sphere they are a bit pricey, but they are fun to watch, people always notice the shrimp moving around on my desk. After attending Thomas Friedman’s talk on “Hot, Flat and Crowded,” I realize they are just another part of my “work in progress” to living sustainably in the U.S. These do not feed me like my chickens and goats, but they also do not eat like my dogs and cats.
Here is mine on my desk - cool eh?
Definitely the most common question is: “Are those sea monkeys?“ According to the web site, they live 2 to 7 years with really no maintenance and NO they are not sea monkey branded brine shrimp.
This EcoSphere keeps me focused on the long road of continuous improvement needed to make our industry a zero carbon footprint or sustainable industry. We are currently on the road to be a larger emitter of CO2 than the airline industry by 2020.
We have to find the innovations in infrastructure, the methods and tools to reverse this. My of view of how to reverse this behavior is through the emerging software value cycle that is made possible by SaaS/Clouds, Agile development and Web 2.0 customer communities. You can read my thoughts on these topics or hear a MassTech webinar.
I have about 15 of these guys in my Eco-sphere.
I believe that with the change to Lean thinking – from products to services and with virtual connections to customers – we can learn to quickly adapt and adopt to new sustainable products and behaviors.
We need a value chain in the IT industry that is closed loop and sustainable, not open loop like the Story of Stuff.
I encourage you to take a moment and consider getting one of these model worlds for yourself or your best friends. It will keep you on the road to smarter, leaner and greener.
About the Author: Ryan Martensis an avid outdoorsman, founding board member of the EFCO, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by emailor RSS.
Over the holiday break, I had the pleasure of spending an hour with Peter Senge from MIT and founder of the Society on Organizational Learning talking through some of the concepts and models in his new book, Necessary Revolution. In particular, he uses the Shareholder Value matrix from Hart and Milstein to help organizations build a comprehensive vision and strategy for sustainable value.
We decided to use that model for our 2-day annual planning session that was led by Jean Tully at Creating Clarity. The model worked very well and helped us manage four intertwined aspects of strategy, divided on the axes of today/tomorrow and internal/external.
While using the model in planning at Rally, we realized that working in two dimensions allowed us to see the whole, and bound the conversations in a way that made the meeting very productive. We are students of Verne Harnish and Gazelles.com; we have and continue to use his one-page strategic planning matrix. However, we have struggled in the past in only talking along the time dimension.
Proposed Framework for Agile Adoption
It was so successful that I built an example Agile adoption strategy model to help illustrated its use. I built this model of a fictitious software-driven organization to illustrate the result of completing only the “Today” part of the plan at the exclusion of “Tomorrow.” The trick of balancing short-term and long-term agility is completing both the top and the bottom to keep the business from myopically focusing on today.
This proposed framework can help you effectively communicate your Agile strategy in the context of the overall business.
Example use of the Agile adoption framework for a software-driven organization
In this model, I define Agile as a strategy and not a driver. I have yet to meet a company who has been successful at adopting Agile development that did not have a higher-level driver or business goal such as a massive increase in quality, cycle-time, customer satisfaction or market innovation. However, many people argue about what is Agile – a methodology, an approach, a process? To me it is all of those things, but its success and impact are starting to make it a strategy for many of our customers.
BTW, Peter Senge’s book is great for folks new to sustainability (balancing economic, social and environmental factors – see the SoL sustainability consortium) and deep learning strategies or for folks with a deep collection of both. And, if you are really interested consider attending their two-day training in Boston next week.
On Monday at SD West, Scott Ambler presented recently updated survey results from a 600 person survey on Agile Development.His results are just the latest in a series of surveys around the move toward Agile Development.Scott’s results came with an assertion that the Agile development trend has “Hit the Wall.”Though Scott could ask that question based on his results, I suggest that he stop and ask the question, Why does his survey show no additional adoption since 2005, but other surveys shows a completely different story? I can not answer that question, but it would be great for Scott to go to the next level.
As a result of Scott’s quote, I decided to dig into what we can learn about Agile adoption in the marketplace and what it means to a software development organization today.
First, I dug into other surveys’ that are represented well at Methods and Tools and the latest information from Forrester.Carey Schwaber has updated their survey of 1,017 North America and European enterprises.The survey was done in Q3 2007, reported in February at “Agile Enterprise Adoption in 2007“.
She found that:
26% are Already Using Agile and an additional 42% are aware
Adoption of Agile increased 56% from 17% in 2006, to 26% in 2007
Awareness increased 45% from 29% in 2006, to 42% in 2007
Her conclusions were as follows:
Agile adoption has accelerated
Large Enterprises are more likely to adopt Agile
Financial Service sector is the leading the pack to take Enterprise adoption
Agile adoption is correlated with adoption of open source, SOA, ALM and SaaS
The Methods and Tool survey found that from 512 respondents in February 2008 versus 232 in 2005 that:
Overall usage had increase by 77 % in adoption from 2005 to 2008
Between fully deployed, partially deployed and partially implement the 2008 versus 2005 results looked like this:(48% in 2008 compared to 37% in 2005)
Fully Deployed 2008 – 17% and in 2005 – 8%
Partially Deployed 2008 – 14% and in 2005 – 12%
Partial implementation 2008 – 17% and in 2005 – 17%
As an organization adopting or scaling agile, I know that I would like to know three things:
Is this a fad?
Am I behind the curve in adoption?
What real benefits are coming as a result of these efforts?
First, the accelerating year over year adoption and awareness rates point to the fact that is not a fad that it is not flaming out.
Second, if you were to plot this against a normal distribution curve that follows an empirical rule where 68% of the curve is one standard deviation from the norm, you would get a picture like this:
Where the area under the curve represents the entire population of adopters, you might come to the following conclusions:
Agile adoption is across the Chasm (into the early mainstream area) by everyone’s accounts with between 17% (Ambler), 26% (Forrester) and 31% (Methods and Tools) of the market using/having deployed Agile.
So are you behind the curve? That really depends on what market and technologies you are using:
Yes, if you are building web 2.0, SOA, SaaS or with Open Source tools
Yes, if you are in the Financial Services Industry
Yes, if you think of your development team in the early mainstream or pragmatic adopter.
No, if you are using mainframe, embedded or client server technologies
No, if you are in the retail and public sector industries
What is the ROI and benefits of Agile Adoption?
Studies like the QSM studies on BMC’s Agile Adoption are showing great results with 4X improvement is delivery speed, 11% lower defect counts for and 20 to 50% productivity improvements.
Though Scott’s survey showed flat growth in adoption, I believe he needs to look at his survey population to understand the discrepancies from the other surveys. All the other surveys point to periods of continued growth as Agile becomes more mainstream across many industries and technologies.
As I watched the Rockies sweep the NLCS I could not help but to think that the Rockies took advantage of Rally’s professional coaching services to help the team achieve success with their agile rollout. Let’s analyze baseball in regards to agile…
During the regular season baseball teams play in 3 or 4 game series, which can be thoughtof as an agile release. Each game in the series can be thought of an individual iteration with a timebox of 27 outs. The user stories don’t really change, a typical baseball iteration has 9 user stories (innings) with 3 story points each. The velocity of the team
really depends on the pitch count. If the pitch count is low we could consider the story to be completed faster than other stories in terms of relative sizing.
Similar to agile, the size of the team is nine players on defensive. These nine players work very closely together to complete each story and focus all of there energy on the current iteration (game). A team member grabs tasks (outs) when they feel they are able to take on more work. Team members regroup in between each inning for a quick stand-up meeting to discuss the next highest priority story (ok this is a long stretch but maybe they have a stand-up).
After the completion of the iteration there is always a retrospective (post game
conference). During the post game press conference (retrospective) the team manager acts as a scrummaster or coach and shields the team from media controversy. The manager is ultimately shielding his team from stakeholders (fans, media, owner) and focusing them on the current iteration (game).
At the end of a game (iteration) the team has completed 9 user stories and the team owner (product owner) either accepts the game or does not accept it (win/lose).
To end this fairly useless analogy we have to consider the post game celebration. Trust me the Rockies had one heck of a release party last night.
RallyDev.com
