I’m offering this follow-up post as a means to provide an overall response to all these great comments. I want to add some further background on the “escalation” topic and some more of my personal conviction around it. Specifically, I’d like to provide some insights into delayed feedback, the need for conflict, and how to “show up”, all without escalation.
In one part of the comment stream, I heard and felt the call for an effort to get to the root cause of such deep-rooted assumptions.
According to the Systems Thinking Toolbox from Pegasus Communications,to break an Escalation structure, ask the following questions:
What is the relative measure that pits one party against the other and can you change it?
What are the significant delays in the system that may distort the true nature of the threat?
What are the deep-rooted assumptions that lie beneath the actions taken in response to the threat?
So, in our system of sharing information in the Agile community, we have to ask, “Are we setting up a dynamic that pits us against one another?” If this is true, then we have to ask, “How can this be addressed and still ensure that we share insights?”
Guided by Systems Thinking, that means we need to check in with: what is distorting our communications and what might our deep-rooted assumptions be that would have us act as we do?
Here is an example:
I created a delay in feedback by my not responding to posted comments. I believe that created assumptions around what I may or may not have intended in the post. I think some individuals thought I had written the post pointed specifically at them. Faster feedback would have helped quell that assumption.
I was writing about, and continue to write about, the Systems Thinking Escalation archetype and how I see it in our community. I was and am looking at a dynamic not at an individual. Escalation is NEVER about an individual; it is about the system in which blame is occurring and allowed to continue. I am fearful that blame and the win/lose game are in our system and that is what I do not like and I want to address.
Some of the comments to my post seemed to indicate that I was anti-conflict. Far from it! In studying the inner workings of high-performing teams, I have often referred to Sam Kaner’s model for participatory decision-making. Conflict is a must.
In this model, Kaner insists that, to get to high performance we must bring forth conflict to discover the best informed decisions. Divergent ideas must be invited. Divergent voices must be heard. Divergence must be allowed to just be. That is, don’t just jump to conclusions. With enough time and patience around divergence, we can then move toward informed convergence.
Conflict in this context is dialogue. It seeks insights. It invites greater and greater participation. I also want to emphasize that in this context of dialogue and non-escalation, our purpose is to engage in forward thinking. We let go and we look forward. And as we look forward, we let go.
So, as a member of the Agile community, my interest in expending energy in discussions is to seek insights, encourage divergence, and discover convergence as it emerges. All of these practices help and encourage me to create more and more forward thinking. If this is not occurring in our community, then we are not getting enough for the energies we expend. If in our community we really “must win” in order to “be heard”, we are stuck in an “Escalation” archetype. And, that means we are all trapped on an up escalator to nowhere.
What could any individual do to break an escalation pattern in a system? Create energy around your insights and share them without a need to apply win/lose stakes. Stop expending energy to refute others.
Here is a simple formula for bringing your viewpoint to bear without escalation:
Show up. (Be willing to be engaged.)
Find out what has meaning to you. (Be willing to be honest about your perspective.)
Tell your truth. (Be articulate about your insight without attacking or assigning blame.)
Let go of what happens. (Be courageous enough to allow others to agree or disagree.)
I believe this formula provides guidance on how to remain forward thinking, remain open-minded, and remain engaged.
I have some more mental models I want to offer here. But they will wait for another post.
Thank you in advance for your considerations, insights, and comments.
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?
Now, in the upcoming Better Software Conference June 8 through 12, I will be presenting “Agile, Lean and the PMO”.
To summarize and entice, let me give you a quick preview.
PMOs usually think they are out of a job when Agile comes to town. But the truth is that a PMO can play a pivotal role in successful Agile adoption in large organizations. In this presentation, I bring my experiences guiding organizations in how to engage their PMOs for successful Agile Adoption.
Enter three primary Lean Principles:
Eliminate Waste
See the Whole
Amplify Learning
I intend to give examples of how PMO members act as the “systems thinkers” for their organizations, pulling Agile success outside of the engineering group alone and into the entire enterprise.
As I’ve stated before, there is a fundamental shift of the role of the PMO with Agile.
Simply stated, the PMOpulls standards versus pushing them; the PMO provides product backlog prioritization guidance with regard to architecture and governance; and the PMOserves its Agile community by facilitating release planning across teams and creating and maintaining product councils.
In short, I contend that a truly Agile PMO brings “shocking openness” to the organization. This ensures deep, wide Agile adoption.
Let’s get together in Vegas to talk about PMOs and Agile and how Lean can guide us to take “what happens in Vegas” back to our organizations!
I have always answered the question “Where does Agile not work?” with the answer: “We have customers in all forms, geographies, and technologies working in Agile. It works everywhere!“
Of course that is my Agile Convert persona coming screaming through…
In his article “Agile Processes Go Lean” on the Dr. Dobbs portal, Forrester analyst Dave West does a great job illustrating the true challenges and roadblocks in successful Agile adoption beyond the team. His research across numerous sources, collaboration with Tom Grant and ability to synthesize these concepts makes this article a must-read for executives in software development organizations.
Dave sums it up nicely:
“The problems, broadly, tend to be technical, cultural, or organizational. Technical problems relate to infrastructure, tools, and architecture, and are often the most visible of the changes involved. But many companies find the cultural and organizational issues are the hardest to resolve.”
“When a development organization uses the approach to transform itself, it often runs into problems with other parts of the company that haven’t undergone similar transformations. Clashes come with the business operations, governance, and organizational structures, among other areas. For example, hierarchical organizations may struggle with agile development’s quick, iterative review cycles and decision making.”
In the past few months, I’ve talked with Dave and Tom about the opportunities and success of large-scale and successful Agile adoptions (beyond single teams and beyond simple flow) using examples from our customers and even our own internal processes. I’m excited to see analysts tackle the meaty topic of scaling Agile and Lean with real data and customer stories.
I am ever seeking to expand my Lean learning. This week I am attending and speaking at the Lean Kanban Conference in Miami, FL. I’m excited about the opportunity to engage in more Lean learning with some great people. Real conversations with the folks behind the books and on the forefront.
In my post on my Leaning Bookshelf about my Lean learning, I included Craig Larman and Bas Vodde’s wonderful book : Scaling Lean and Agile Development, based on their collective experiences in very large (and distributed) Agile software development.
I love this book. Given my interest in the book, and knowing both Bas and Craig a little, I invited them to tell us a few things about themselves and the book.
Q. [JET] I’m very interested in Systems Thinking and yet don’t find too many people in our software development field talk about it. So it was a wonderful surprise to see it as the opening topic in your book.
Tell me, why do you feel it is so fundamental to the work of scaling lean and agile development?
[Bas] I do think systems thinking is discussed in the software development field. Gerald Weinberg, of “Psychology of Computer Programming” fame, has written three books on the topic. Of all the topics Jerry talks about, I think this is probably the one he has written the most about. Also, Mary and TomPoppendieck wrote about the topic in their lean software development books. But perhaps you are right, it is still not covered enough.
In large-scale development everything tends to have an effect on everything else. It is easy and common to quickly respond to events or draw conclusions. For example, if there are many bugs in your system, it is easy to relate that to something you did recently and act based on that. When, after acting, the bugs increase or decrease, it is too easy to conclude that these two relate.
These mistakes in cause-effect thinking are especially common in large-scale development and therefore it is important to try to think of the system as a whole. System thinking helps thinking about the whole system and especially doing that together so that perspectives become aligned and a common understanding is created.
[Craig] The large-scale immediately (and usually, painfully) bumps us into the organizational structures and policies, and their impact to support or inhibit the flow of value. And large-scale development organizations have more formal policies and structures compared to the small-scale. The organizational design reflects the psychological and systems insight — or lack thereof — of the people in management.
Most business (and broader) problems have their root cause in mental and emotional limitations or weaknesses: command-and-control management and “Theory X” managers, not seeing the true nature of causal relationships, not grasping non-linear effects and delays in the workplace, lack of kindness and transparency, and so forth. And it extends to deeper issues: awareness of and healthy suspicion of our own mental models, double-loop learning, skillful listening and conversation, emotional intelligence … Great organizational designs reflect people in leadership with great personal mastery — and part of that mastery is people who can do systems thinking.
Q. [JET] Craig is a great guy. I’ve enjoyed the few times I’ve had to talk with him. As you were writing the book together, what would you describe as something in particular you were grateful that you learned from him?
[Bas] The book is a result of years long co-operations and discussions. So to limit what I learned from him to writing the book wouldn’t be fair.
Over the years, I mostly appreciated the countless discussions we had on large-scale development. I’m not always good at expressing my thoughts and Craig is a patient listener who really tries to understand different perspectives. Then, he is not shy on giving very direct feedback. I think it’s these discussions (and the ones we will have in the future) that I’m most grateful for.
Then, specifically to writing the book. I’m not a native English speaker and not an very experienced author. I don’t think I could have learned more about English language and writing in a shorter period.
Q. [JET] I love the “Try-Avoid” model you use throughout the book as well as inside the covers. It seems to walk a nice tight rope between prescription/non-prescription. What inspired you to come up with this approach?
[Bas] That is interesting. I wish I could take any credit for this, but I’m afraid Craig actually made that decision. I even argued against it since I felt that it would hurt the readability of some parts. Not all parts are easily put into this “experiment-format.” After many discussion on the format, I agreed with going forward and over time started to appreciate it.
What inspired the approach? I’ll let Craig answer this more thoroughly, but the main thing was the illusion of knowing the answer. Every situation, product, culture and company is different. Every product we go, we learn new things and experiment with new ideas.
So instead of giving “the solutions” we’d like people to think about their context and about the different experiments they could do. Learn from these and find themselves the best solution in their context.
[Craig] First, to reiterate what Bas said, kaizen in Toyota, and empirical process control in Scrum, emphasize a culture of structured experiments, rather than defined process or a cookbook of process recipes to follow, and I hoped to emphasize that notion.
Second, I become frustrated when reading a book and I have to dig around in the text to find specific actionable advice the author is offering. I want to respect my reader’s precious time, and make it as easy and immediate as possible for them to find that.
Q. [JET] Several years ago Bas, you and I roamed through Powell’s bookstore’s used computer books in Portland, Oregon together. That gave me a glimpse into your love of books; your bibliography for “Scaling Lean and Agile Development” is yet another indicator!
So here is a tough question for you: what were the top 5 books that inspired you in writing this book?
[Bas] Yeah, the visit to the bookstore was nice. :) I’ll change the question a bit. I’ll answer it with the top 5 books that inspired the content of the book… but weren’t mentioned in the book. There was no appropriate place to recommend them.
- Debugging the Development Process – Steve Maguire. Steve wrote two classics in 1995. One related to writing code “Writing Solid Code” and one related to the processes for writing code called “Debugging the Development Process” which describes how he managed software development groups within Microsoft. The book is full of insightful advice about software development and it is a book I always get back to and re-read parts of. Still today, most of Steve his writing is exceptionally relevant.
- Secrets of Consulting – Weinberg. Gerald Weinberg has contributed so much to the knowledge of software development. Not just his 40 books, but he has a group (Weinbergians) who he trained and is still in contact with. I know some of them and Weinberg’s influence is visible. Of all the books he wrote, this one was perhaps one of the most insightful ones. It is, like all his books, full of stories and small insights on working together with people and companies.
- Juran on Quality by Design – Juran. It is quite amazing that we did not have any place where we could recommend the work of Joseph Juran. Juran, next to other “quality gurus” such as Deming, Crosby, has been a huge influence on my personal thinking about organizations and developing quality products. I especially enjoyed this book of Juran and his insights related to quality planning and product development.
- The Gold Mine - Balle and Balle. We recommended a lot of lean books, but not this one. This lean book is written as a novel, which makes it hard to find a good place to recommend it. It is quite much like “The Goal” which is the well known business novel introducing Theory of Constraints. The Gold Mine, however, didn’t introduced any new concept, but it does a great job of clarifying lean in a form that is easy and engaging to read.
- The Peter Principle – Lawrence Peter. Some organizational behavior is so taboo that you shouldn’t be talking about it. But, of course, you can ridicule it. Thats exactly what the Peter Principle does. It shows that human society is rising in the animal hierarchy and has reached its level of incompetence. Books like this one give a great perspective to behavior in organizations and are very funny to read. Painful, but true :P
[Craig] In the same spirit of Bas, on relevant works that weren’t really emphasized:
various books by Ralph Stacey on the illusion of the belief of how much we can influence or control our complex non-linear social work systems (Stacey’s work is touched on in Beedle and Schwaber’s first Scrum book). There is a deep assumption in most people at work: we can control complex things. Once a great doubt arises about this core assumption, it opens a major can of worms that pulls the rug out from underneath many organizational design ideas.
Q. [JET] You mentioned to me that you and Craig discovered that in the writing of your book, you were uncovering “an embarrassment of riches”. This led you to decide to divide your work into two books.
What sort of preview can you give us to the material coming in the second book?
[Bas] Oh yeah. We kept saying “Oh that must be there.” Then we kept removing things to only leave the essentials. But soon it became clear that all the things we wanted to say would not fit in one book. Influenced by Don Reinertsen’s “The Design Factory,” we wanted to split the book in thinking and action tools. However, we had a group of ideas which didn’t fit well in either, so we came up with the “organizational tools.” Suddenly we had two logically consistent books and decided to do that.
The second book will be the “action tools.” The goal is to give concrete advise on how to do particular practices. How to do planning? How to do design? What do with with multi-site development? What to do with legacy code? All of these chapters will use the action and organizational tools from the first book. When people read the book, they ought to have concrete experiments for their current situation.
In this post, I’d like to respond to some questions posed to Johnny and me during the webinar.
JET = Jean Tabaka
What is the measurement of productivity? Is it user stories per lines of code?
JET: We define productivity index with regard to the Michael Mah statistics collected over 7500 products. It is not about lines of code. Rather it is about delivered value. At a very high-level view then, a PI in an Agile team is about the amount of value delivered by a team based on value delivered over the total number of team members.
Michael Mah shows in his studies, which we referenced in our webinar, that Agile teams tend to have a higher ability to delivery value per team member than the norm across all projects he has surveyed. This supports our view that the way to project cut costs is to help team members increase their PI versus cutting team members or off-shoring work.
When you start on Step 1, one team in flow, do you start immediately with 2-week iterations, even if the teams are used to waterfall?
JET: For any team starting its transition to Agile, the important Flow guidance I give is: Choose a timebox, and stick to it. Religiously.
I give guidance that a shorter timebox is preferable to a longer one. This gives the team that moment of pause for inspection and adaption sooner rather than later.
A shorter timebox invites earlier improvements on process. It also affords the Product Owner or customer representative the opportunity to re-prioritize, add, or delete items in their backlog.
Given these parameters, the team commits to what the timebox length will be. So what do I advise? If asked, I tell teams that 2 weeks is a good starting point: shorter time to inspection versus longer wait for improvement opportunities.
How would you apply Agile, and particularly Scrum, to security related software where design and reviews typically take longer than one iteration?
JET: Agile asks us to evaluate how much design and review MUST occur before features can begin to be coded and tested. Your question is all the more important in your context.
Think of it this way: Imagine in a security software environment, you implemented something and then slammed all kinds of vulnerability tests against it to discover its actual vulnerability. Imagine that this could be in addition to, or even as a replacement to, extensive review up front.
I once worked in a security related software environment. We spent months and months reviewing documentation attempting to conduct independent validation and verification about vulnerabilities before any coding began. How I wish we could have just conducted detailed design, code, and test on our riskiest features and applied our hypotheses against these rather than being left to hope our analysis was adequate!
If we want to introduce Agile in a certain project team, what’s the perfect ratio of Agile consultants versus our own personnel?
JET: Perfection is in the eye of the beholder ;-)
I suggest one mentor per team initially. We have also used one mentor for a team of teams, a program. That creates stability and synergy across the teams and encourages all teams to form their own Agile team agreements while also learning from what has worked well with the other teams.
One more thing: Having a mentor at the management/executive-level is also critical. It may be this same person; it may be someone who has more of an executive stature. In the latter case, be sure the two mentors work tightly with one another.
Would you define ‘user stories’? Similar to Use Cases? Difference?
JET: User stories are an expression of a request from the customer or customer representative for a particular function. They are meant to be short, incomplete, and value-based.
They invite conversation and further clarification of completion: “As a < role >, I want to < action > so that I can < benefit >.”
“As a dog, I want access to ‘The Daily Woof” newspaper on my Kindle so that I can flip pages without opposable thumbs.”
This request for action and benefit is elaborated as it rises in rank among all functions requested. We elaborate these in several ways. One way is to start writing acceptance criteria.
Another way might be to elaborate it through a use case that details actor-system interactions, extensions, and so on. A team makes agreements about how function requests grow in clarity; that is, are use cases our best way to declare DONENESS for this request? Or, in our environment, is a simple description and test case sufficient?
How can we get better reporting metrics for roll-up to the executive level? Are there key mash-ups I should/could use?
JET: without digging into specifics with regard to mashups in our Rally tool, I highly recommend looking at a set of metrics we gathered in our whitepaper: “A CIO Playbook for Adopting for Adopting Scrum” co-authored with Ken Schwaber and Dean Leffingwell.
One appendix in the paper guides teams in a quick self-assessment of their Agile uptake. The second offers metrics both teams and executives can use as new measures of success.
Altering how we measure and guide success in Agile has a great impact on the “stickiness” and intended benefits of the Agile rollout. Rally tool mashups simply support real-time access to such measures. This “reporting” style deviates from the traditional “reporting up”. Rather, the metrics we recommend are meant to keep the entire organization informed about what is really happening. This creates organizational ownership of amplified learning and continuous improvement.
Have you integrated user centered design (usability practices) into the Agile development process? If yes, what was your approach? If no, why not?
JET: I believe user-centered design has a place in Agile development. Design emergence doesn’t mean it can only occur in the planning meeting for the next iteration, IMHO.
creates a high-level vision (informed by many sources);
collaborates with the product owners about how to incorporate this across a product roadmap;
provides more detailed guidance about backlog items specific to the user-centered design;
then engages actively within Scrum teams when product backlog items specifically impact user design changes (where she is tester or owner or delivery team depending on the item.)
Do Agile practices only apply to software delivery, or have you ever seen them applied to successful service delivery?
JET: Jeff Sutherland tells a great story about helping his wife apply Scrum in her life as a Unitarian minister. I also have a colleague who uses it in his volunteer organization. And there are people in my Certified ScrumMaster classes from non-software parts of software organizations eager to bring Agile in. Here at Rally, we use Scrum in EVERY department in the company, including at the executive level.
It is already challenging to obtain the time of critical resources (shared among various projects and sustaining). Are every day SCRUM meetings practically possible?
JET: Everyday meetings are faster than having to write them extensive documentation. And, they are less costly than not having them involved at all. Still, teams make agreements about how critical it is for “part-time” experts to be engaged in every meeting. They inspect and adapt.
Is Scrum mostly for R&D projects with more unknowns or is it equally effective on projects with extensive functional and technical knowledge and skills.
In other words, is Waterfall totally obsolete?
JET: Rigid methodologies don’t serve environments where any amount of change can occur. If you have projects that have no change in scope, no mis-interpretations of requirements, no defects in design, no defects found in code test or integration that would require re-work, I see no reason for you to change. I do not know of such projects.
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
At Rally, we often get questions about how Agile fits in with a variety of other practices and processes, so the below questions about Agile and CMMI, Agile and RUP, and Agile and Architecture come as no surprise. Stay tuned for the final Q&A on Agile champions.
DW – is Dave West from Forrester
RAM – is Ryan Martens from Rally
How can Agile be integrated in a CMMI certified application in regards to the tremendous amounts of required CMMI artifacts (documentation)?
DW – The flippant answer is it can’t. ☺ But actually I have seen some great systems integrators use CMMI to help check list their processes of which some of those processes are Agile. Agile development works really well at the team level, but it needs to be surrounded with other processes. CMMI makes sure you remember those processes, some of which are inside the Agile team, others are not. The PA’s always seem to imply lots of documentation, but they do not have. You can keep the documentation to a minimum, but still deliver them. Do not, however, burden the Agile team with proving their compliance – Use the checklist, build the software and get others to prove they did what they said they did.
RAM – I am not quite as negative as Dave on this topic. CMMI and Agile combine just fine. There are a number of proof points that are easily found from past Agile conferences and by searching “Agile and CMMI.” The problem is that many folk misinterpret CMMI and are convinced that it mandates waterfall, heavy process and heavy documentation. According to SEI, it does not. Most teams would not adopt CMMI without a specific business need.
We received lots of great questions and shared them with the webinar attendees, but thought they would also be valuable to other Agile practitioners. This first series of questions tackle the obstacles of adopting Agile. Stay tuned for the remaining questions in later posts.
What are the biggest blockers you see to good Agile?
DW – My pet peeves are people that resist change without really thinking about it. That treat software like car production and think that you can plan, deliver in that manner. These same people often lament the ability of the software teams to deliver good code at the right price. Software is a fundamental part of business change – If you need a new part to your business it will most likely require software, which may require development and integration. Connecting up their development with the people who have the problem is the first step to success, empowering teams to try new things and question the status quo in support of those business needs is key. Organizations that put artificial walls between the problem and the solution are the biggest blockers. These may come in the form of planning processes, business access, travel budgets, governance models, standards or culture.
RAM – Good Agile development is a mindset change like Dave is describing above. Overly aggressive or passive plans are the biggest blockers to “good Agile.” You need to think about this change as incremental and iterative with a strong focus on continuous improvement and learning through inspect and adapt feedback loops.
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.
RallyDev.com
I’m offering this follow-up post as a means to provide an overall response to all these great comments. I want to add some further background on the “escalation” topic and some more of my personal conviction around it. Specifically, I’d like to provide some insights into delayed feedback, the need for conflict, and how to “show up”, all without escalation.
Okay, I must be obsessed with Agile and PMOs lately. Well, Lean, too, as long as we are talking about obsessions.
In my post on my 
I give guidance that a shorter timebox is preferable to a longer one. This gives the team that moment of pause for inspection and adaption sooner rather than later.
