I love games! Especially games that help teams grasp Agile principles and practices. There is nothing like a good game to help build some solid muscle memory around core aspects of how Agile impacts teams and organizations.
In the next couple of months, I have the very good fortune to be involved in several Agile game events. I’m lucky enough to try out new games, bring in some systems thinking and design thinking games, and help others apply games.
Ryan Martens: Age of Reconsideration, Reform and Regeneration
The last decade marshaled in a new empirical way of working with increasingly complex, interconnected and highly-critical software-based systems – Agile. We are entering a period of reconsideration, reform, and regeneration in software, systems engineering and project management. Agile is working, Lean Software and System is working, and the combination is starting to prove very powerful with regard to throughput and workers. The benefits of autonomous work, engagement and mastery are driving systemic improvements in our way of working and growing to meet complex challenges of our world.
These results illuminate a future vision that has the potential to expand our current notions of Lean and Agile from software teams and into real organizational agility. As a result, there is a chance to unite and unify many communities under the guiding ideas of flow, pull, and value. All of these communities are being drawn in and starting to play well. These are beautiful days with all the implications to CMM/SEI, Agile, Scrum, Lean/LEI, and PMI/PMBok communities yet to be determined.
In the first half of this decade, look for collaborating across boundaries, seeing larger systems and groups working hard to create their future realities. Following that period, look for messy consolidation as the winners of this new platform emerge for a new golden age of networked, software product and system development. Together we’ll be focused on the problem domain of global scale difficulties in governance, cyber-warfare, energy, water, communication, commerce, medicine, climate, transportation and nano-technology.
Thinking about our path with Lean, I’m compelled to draw upon research I’ve been doing in Systems Thinking and, more recently, what I’ve been learning in Systems Engineering.
In Systems Thinking, we recognize a world of system archetypes based on the dance of balancing loops, reinforcing loops and the outside agents that may cause them to transition. Lean, as a system of thinking, has certainly responded to systems that rely too much on take-make-waste. A set of negative reinforcing loops: the more you waste the less you have to take and make. Outside agents, the scarcity versus abundance of materials, has led us to Lean. Lean principles and practices create a positive system wherein the more we reduce waste the more value we get which in turn reinforces more waste reduction. It is a reinforcing loop propelled by continuous improvement.
Recently, I attended the Lean Software and Systems Consortium’s 2010 conference in Atlanta. What a revelation. From James Sutton’s talk on Lean Systems Engineering, I added new vocabulary that I think will become critical to Lean’s future.
Will Lean be our best source of practices and principles in the future? That depends on what will be guiding our systems:
Scarcity
Abundance
Desperation
Conformity
Once we have clarity about what guides our system, we can understand more about the system in which we are operating:
Simple
Complicated
Complex
Chaotic
Lean has steadfastly addressed pressures of scarcity and hence a system of complexity. That brings me to Dave Snowden’s work captured in Cynefin, a Welsh word he has used to describe a framework of problems, situations and behaviors in these four systems. For our world of complex systems, Lean provides the perfect high-level thinking for what we must embrace: emergent practices informed by, as Snowden puts it, “sense-making”
As we move into the next 10 years of Lean, I fervently believe that our sense-making must inform us about what supports emergence that responds to complexity. The practices will follow. For now, let us concentrate on the systems in which we operate, what outside agents or pressures are guiding our systems, and how we can best continue to formulate and hold dear the practices that will naturally emerge.
Jean Tabakais a wine enthusiast, author and Agile Fellow at Rally Software Development.
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 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.
The other day, I noticed that the water is draining rather slowly out of my bathtub at home. That is annoying…
It means that I haven’t really kept my drain as clean as I should. Or perhaps I should be “snaking” the pipes more regularly. One thing for sure, if I don’t get this fixed, eventually my tub will stop flowing entirely. If I try to add water, my bathtub will just overflow and I won’t be able to use it without a major plumbing expense. Ugh!
What does this have to do with my latest topic of cutting costs with Agile development? Well, I’ve been reading a great little book by Linda Booth Sweeney, When a Butterfly Sneezes. It’s a sweet, simple way to learn about systems thinking by using children’s stories for examples of various systems’ archetypes. To kick things off she uses a bathtub analogy to explain stocks and flows and how they impact one another.
Aha! That is what I care about when I am developing software!
Imagine that the faucet to my tub is all the features I am putting into my product. My bathtub is my product stock. As I add features, my bathwater level goes up. Now think of the drain as the “flow” by which I get the “stock” out to my customers.
If my drain is clogged up even a little, I can’t get the flow of features, my value, out to my customers as quickly as I’d like. And if I have a really bad situation, then I actually can’t keep adding features into my stock (my bathtub) because it will just overflow. Features (value) will never get to my customers. They’ll just end up as a major mop up for me, lots of work that doesn’t deliver anything but frustration.
So what are the clogs in my software bathtub? Defects.
A few defects unattended to will just slow down my value delivery. Not too bad. But if I allow defects to accumulate, that technical debt can bring my value delivery to a crawl. I’ve got lots of stock and yet my inattention to defects has cut off flow to my customers. Crumb.
Agile cuts costs because it requires us to keep our drain clean, not let defects accumulate. Agile guides us to not over-emphasize adding features to our tub while disregarding accumulating defect residue. Rather, we are guided to add high-quality features with a zero-defect mentality. Think of it this way -
Adding a little Scrum will help you eliminate the scum.
Now, whenever you are ready to open the drain for a release of software, there are no last minute plumbing repairs necessary to let the value flow. Keeping the drain defect-free means I can keep adding features into my stock and let them flow out anytime I want. I can even have sustainable, even continuous, inflows and outflows to and from my stock. The cost of delivery of value slowly goes down, I have sustainable and reliable flow, and all because I was willing to do a little continuous bathtub maintenance.
Don’t let defects clog your feature bathwater. Use Agile to stop the defect clogs and keep the value water flowing!
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.
This last week I was with a number of our extra-large customers and prospects. A common theme with these large and very successful high technology companies was the statement “growth hides all issues.”
When we are growing rapidly, we all tend to focus on investment and hiring just to keep up and not limit the growth.
I remember this same feeling at BEA Systems in 2001 as the tech bubble popped. In our Boulder office, we found ourselves staring at 10 times more people than we started with in 1999. Even though we took Extreme Programming (XP) teams into that growth, we ended up with a 100+ person and multi-location, waterfall process. Our team reacted by putting back in XP engineering practices and large-scale, nightly, integrated builds to increase visibility and feedback.
Picture from Pegasus Communication - Leaders in Organizational Learning and System Thinking
A Two-Pronged Approach to Agile Adoption in a Recession
I was thrilled to see this approach used in the President’s stimulus package – short-term tax cuts to stimulate and provide relief coupled with future-looking government investments in more sustainable and equitable infrastructure. Without this type of approach, myopic thinking tends to increase the chances of “Fixes that Fail.”
It was a really good week last week. As a result of this positive feedback, our team is going to devote a substantial amount of blog space during early 2009 to covering the strategy, approach, myths, and success stories around the use of Agile development to cut costs and simultaneously prepare for future growth.
Please stay tuned, link back your stories, comment, subscribe and consider your actions.
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
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 my post on my 
