I just wanted to take this opportunity to thank each and every one of you who follow the Agile Blog.
Jean and I have had a great time writing these posts over the last year, and we are humbled by the way you’ve responded. After a few years of casual, intermittent posting in our Agile Commons community, we jumped off the deep end into blogging this year by hatching out this site and our Engineering Blog.
We are truly grateful for how you have helped us learn and grow: for every comment, every tweet, everything that you have shared with us.
And we are hopeful that the learning has been a two way street. That is, whatever topics or ideas we posted in the blog that particularly resonated with you, we are honored that you invited us into your 2009 professional journey. In fact, we’d like to see your comments on what you found particularly useful or engaging in this past year. And we welcome your suggestions for topics in 2010.
We look forward to continuing this great conversation in 2010.
For 2010, lets find ways to focus on teaching our craft and growing the world of skilled software development professionals instead of trying to figure out who is “right.”
I believe much of the “Escalation” that Jean is seeing was correctly titled by Regina Mullen as a battle to be “right.” (see and read Escalation is Killing Agile – Can We Please Stop It? and Escalation is Killing our Healthy Conflict in Agile). That behavior focuses on carving up the pie instead of growing the pie. There has been so much added to the field of software development methods, tools and techniques from the guiding ideas of Agile. Now is not the time to stop and eat.
For me, 2010 is about continuing to grow the Agile software development pie’s reach and innovations.
I believe one of the key fixes to the problem of escalation can be found through increased professionalism and certification in Agile. By raising the bar through “difficult and skills-based certification,” as Brian Marick and the board at the Agile Alliance described, we can advance the Agile discourse through :
a defined a bar that is deep in skill, knowledge and practice
a significant enough bar to engage College and University study and examination
research and curriculum that explore the tough questions in a scientific method
development of more flexible or “T” shaped individuals that can see and work beyond silo roles.
I am a member of a community of thinkers and I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.
A Community of Thinkers creates more leadership in our profession. I see the expanding certification efforts in 2010 as great steps in these directions:
I encourage everyone in our community to figure out how to put energy toward one or more of these efforts. The benefit of actively learning, teaching and reflecting on our work should lead us all to expanding civil dialogue that works to understand all points of view and keep expanding our thinking. Thus broader education and difficult certification helps create a “Community of Thinkers.” And, a Community of Thinkers will create a virtuous cycle of win/win and thus a larger pie for all.
As a Scotsman living in the US I take more than my fair share of trips through Heathrow airport.
There are many things I enjoy about being back in the UK but Heathrow airport is certainly not one of them. For a while HSBC bank tried valiantly to cheer us up, and as we trudged wearily from terminal to terminal, our journey was made more colorful by the many posters from their What’s Your Point of View campaign.
Here is an example of one of their posters:
Looking at these posters made me reflect on my own work as an Agile Coach and how I am often confronted by different points of view.
If I am speaking to a group and criticize waterfall development there is a chance someone will feel I am disparaging their team or their efforts. Sometimes use of the word agile does not serve a good purpose. Many have negative perceptions of Agile and believe it to be chaotic, undisciplined and unpredictable.
As a coach, I don’t like to spend time fixing negative perceptions of Agile. My passion is making teams and organizations successful. I like to steer away from the waterfall vs. agile discussion.
Instead, I focus on sharing what I see happening in high performance teams and organizations:
Without knowing what value really is we can’t reduce waste. Afocus on customer value answerstwo key questions: (1) Who am I building this for? and (2) Why am I building this?Once we have a keen sense of what value is we can then prioritize our work to deliver the highest value first.
By delivering early and often we give ourselves the best opportunity to beat the competition to market, realize revenue and discover insights that we can help us improve.
One of the biggest impediments to delivering early and often is the inability to reduce batch size and many teams struggle with this. This is a battle worth fighting.
Another impediment to delivering value is not pull testing forward. If we don’t complete our work as we iterate then we are creating technical debt that will affect our ability to release.
Successful teams know it is best to take small incremental steps towards improvement and to establish a rhythm of continuous improvement. We don’t try to define the perfect process, we don’t set the bar too high and we continuously inspect and adapt.
As Émile Chartrier once said “nothing is more dangerous than an idea when you only have one”. Successful teams and organizations know that to survive long-term they need to create a collaborative culture that fosters innovation and shared commitment.
Are these are agile principles or lean principles? Some like to draw an ideological line between the two but like Wille Faler I don’t believe that’s a bottom-line discussion. Call them waterfall if you like, so long as you’re successful.
You might not like my list and that’s fine too. Make your own list but don’t just pull it out of a book. Visit the gemba and come up with something visceral that your team can identify with.
I had the fine fortune of spending a day with Liz Keogh and Eric Willeke in Boulder last week.
What a wonderful experience! The three of us gathered with the goal of producing something for the Lean and Kanban software community. We didn’t know what that would be. We just knew we felt strongly that we should give something to the community.
We were heavily influenced by past conversations with Chris Matts, his call for “fewer leaders, more leadership”, and a desire to see the Lean Software and Systems Consortium (LSSC) learn from some of the trials that other communities and community-leading organizations have undergone. Ryan Martens, the CTO and a founder of Rally, also provided thoughtful input to our discussions during the day.
As we talked, we discovered something. We were all keenly interested in the general notion of “community”. We became less convinced that the LSSC needed a challenge from us, and more convinced that it was applicable to software communities generally. For me, this was a deeply personal statement and commitment. It played heavily into my recent blog posts on “Escalation”. And yet, together, Liz and Eric and I found the same deep conviction. So as you look at the statement I provide below, if it’s exactly the same as the copies on Liz or Eric’s sites, it’s only because their arguments were equally sound and convincing.
Because of that personal nature, we wanted to avoid putting our statement up as some kind of manifesto that people can sign. If you feel strongly enough about this statement that you would want to sign up, copy it. Post it on your own site. Attribute it to wherever you got your copy from – the act of sharing is more important to us than the act of creation – and feel free to change it so that it reflects your own values. I don’t think that any statement like this can ever be perfect, nor will we perfectly live up to it.
I am a member of a community of thinkers. So are you.
“A Community of Thinkers”
I am a member of a community of thinkers.
I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.
I challenge each community in the software industry to:
reflect and honor the practitioners who make its existence possible;
provide an excellent experience for its members;
support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
exemplify, as a body, the professional and humane behavior of its members;
engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
embrace newcomers to the community openly and to celebrate ongoing journeys; and,
thrive on the sustained health of the community and its members through continual reflection and improvement.
I believe that leaders in each community have a responsibility to exhibit these behaviors, and that people who exhibit these behaviors will become leaders.
I am a member of a community of thinkers. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.
In my last post I discussed the awesome workshop I attended called Leading and Learning for Sustainability and why I think it was so beneficial. It changed me. This post is about how it changed me.
While at the workshop, I learned from deep reflection that I get things done by example. I also learned that I like to work with my team and my customers. In other words, my strategy for leadership is “walking the talk” and sharing it. (It only took me a year of blogging to figure out why I blog and to whom I am writing. I feel my best posts are the ones written to my team and customers that are based on my own personal experiences.)
As a result, I have learned to articulate my strategic roadmap toward sustainability and restorative economies in these steps:
Get Rally and our customers effective at Flow, Service and Lean in software and product development
Get myself and my family to a zero carbon footprint lifestyle
Mature the software & hardware development practices as a highly valuable, joyful, respectful and humane profession
Get Rally to a zero carbon footprint
Get our High Technology industry to a 80% carbon reduction in total footprint
Grow High Technology as a leading sustainable industry and critical enabler of green technologies and as an 80% carbon reduction in other industries
Step 1. Back in 2002 when I was working on the initial concepts for Rally, it was Paul Hawkin’s Natural Capitalism book that really shaped my long-term vision for Rally. We basically committed to to bring service and flow, and lean to the high technology industry. I would declare our first 6 years as a success. We have succeeded at introducing the concepts of Flow, Lean and Service into the software and hardware development industries. In addition, we have made many of the worldwide leaders in this space very successful by realizing the benefits of enterprise agile software development.
New Baby Goats this Spring
Framed Greenhouse on Barn
Step 2. We have been incrementally investing in solar-based solutions to make our personal life more sustainable. It was PV’s, hybrids, chickens, goats, an e-bike and now this year a new in-ground greenhouse. A solar hot-water and pre-heater is up next in 2010. (Hopefully, I will even get a cool Tendril home monitor from one of our customers for Chirstmas!.) I think our home life will be over 80% of the way to zero carbon footprint by 2011 with the final addition of electric vehicles.
As a well paid worker in the executive in the High Technology field, I figure it is my role to help these new green technologies move down the marginal cost curves. In addition to actually doing something about this problem, I am learning about living in close-loop, sustainable value chains. (I will tell you there is something very grounding and joyful about starting the day by feeding animals who provide for you. Even on a day like today that was -1 F outside.)
Step 5- 6. These steps will come as we share our experiences based on our own relentless pursuits of steps 1-4. Right now I learn a bunch from work shared by Interface carpet’s mission zero, Google.org’s RE<C and as a member of NRDC’s E2 program.
It was as a direct result of this workshop that I learned enough to articulate my choices, what to conserve, what to let go of, my leadership approach, who I need to do this with and ways to bridge the creative tension between my personal vision and reality. It was a very powerful workshop.
In closing, I would like to share two of my favorite quotes:
Edward Deming: “The prime requirement for achievement of any aim including quality is joy in work.”
Humberto Maturana: “Emotion is the bedrock of all that we do and love is the only emotion that expands intelligence.”
Thank you again Peter Senge, Sherry Immediato, Darcy Winslow and all the other great folks who attended the SOL workshop on Leading and Learning for Sustainability in DC.
Climate Change due to the increase of carbon from human activity is a “Global problem,” thus it has a couple of unique attributes compared with other world problems:
This three-day workshop leveraged long-time SoL content on leadership and mastery into the context of the global climate change. It was a fantastic workshop that I highly recommend – as it has changed me and my mental models.
Tim, our CEO, Peter and myself at the end of day three
Living in Boulder Colorado with tons of the worlds best climate scientist and a University that helps you Lean More About Climate, I am familiar with much of the science behind climate change. But, in this workshop we got to take our understanding up to the larger system level through system archetypes, multi-player games and simulations.
On the third day, we played with and did mock negotiations using the climate change system simulators that were built for negotiating teams going to Copenhagen in the next two weeks. The systems dynamics models baked into the C-Lean simulator are made more apparent in the Seed Simulator on Carbon flows. (It is a simple bath tub model of how carbon flows through the natural system.)
For your information, the answer to the simulation puzzle of putting climate change in check and keeping average global temperature from rising more that 2 degrees involves three things:
have all countries in the world (un-developed, developing and developed) reduce there carbon output by 80% from 2005 levels by 2030
stop deforestation efforts
maximize reforestation efforts
To do this, the world will have to cross the threshold to a new game; an infinite game of win/win behaviors that measures success based on ecological restoration and social well-being. Finite game behaviors coming from zero-sum game thinking and patterns of shifting the burden and escalation will have to stop. I like to think of this an maturation of our species from wildly growing adolescents to young adults.
Peter’s 5th Discipline Fieldbook and The Dance with Change, come with tons of exercises, tools and guest lectures that are all helpful at understanding organizational learning and systems thinking. However, as Peter said in the workshop, understanding the concepts are easy, but practicing them can be much harder.
Part of the success of this public workshop was working with these concepts in a context of a global problem that we all share. We got to work on ourselves and a shared global issue. And as a result, we seemed to all have limitless energy and worked from 8:30 AM to 7 PM each day.
I encourage you to visit these sites, they give climate change a face and a shorter feedback loop. Both of these benefits can lead you and your teams to better understand and more easily act on this Global issue.
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.
Sarah: “Whoa, whoa, whoa, Walter. Where are you going in such a hurry with that look on your face? You look like you’re chasing that guy who stole Christmas.” Walter: “Grinch.”
Sarah: “What?” Walter: “It was the Grinch that stole Christmas.”
Sarah: “Stop changing the subject, Walter! Where are you going?” Walter: “I’m going to the Frboz 2.0 Project Post Mortem, and it’s gonna be pure hell. It was over 100% late, bad quality, angry customer. It’s a classic. And I wasn’t even on it. I’m supposed to be there to criticize the project leader.”
Sarah: “How did that happen? I thought they went through all of that on 1.0, didn’t they?
Walter: “Yes they did, and they had a post mortem and they made changes and it seems to have made things worse. They blamed a few people and then left them to work on the 2.0 project because they learned something by being blamed, so they were pretty demoralized to start with. The post mortem decided to be more rigorous on signatures, so the Requirements phase took twice as long as planned. Every time they tried to get all 12 people to sign, one of them had a change to make. Same thing happened during System Test. They were supposed to get CTO approval for every push to pre-production, but the CTO was never around and she had to be completely briefed on everything that had happened in that build when they finally found her before she would sign. Everything took ages! In the end, everything they did made things worse. I don’t know what to do. This meeting is going to rip some people up, and for no reason that I can see.”
Sarah: “Hey Walter, I have an idea! What if you tried to get them to look at root causes instead of concentrating on blame for surface symptoms? Maybe they would discover some useful ways to actually improve things. What do you think?”
Walter: “You know, Sarah, it’s crazy enough that it just might work. Remind me of some easy ways to do root cause analysis. I’ll only get maybe one or two chances to make my point.”
Sarah: “Try the 5 Whys. It’s a technique from Lean Manufacturing, but it works really well. Start with a symptom and ask ‘Why is that?’ Then when you get an answer, ask ‘Well, why is that?’ When you get that answer, ask it again. Do it a bunch of times and you’ll eventually drill down to a root cause. Ask ‘Why?’ five times. Get it?
Walter: “OK, let me see if I got it right. I pick a symptom, like ‘requirements not agreed on time’ and ask “Why?”. Then they say ‘…because it was too hard to get all 12 signatures.’ So then I say ‘Why was that?’ And they say ‘…because every time we made a change and went to get the signatures, one of the people would have another change to make.’ So then I ask ‘Well, why did that happen?’ And they say ‘Because everybody kept learning more about what the product should be.’ And on and on until eventually we find out something like ‘Oh. It’s impossible to get all the requirements right up front.’ Or whatever. Then we can figure out how to address that root cause. Is that it?
Sarah: That’s it, you’ve got it.
Walter: Gimme five, Sarah! Thanks for the help!
About the Author: Alan Atlasis a poker player, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.
RallyDev.com
I just wanted to take this opportunity to thank each and every one of you who follow the Agile Blog.
I had the fine fortune of spending a day with 
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.
