Agile Development Blog

Yesterday, the Agile Journal posted their May edition of the online publication with the above focus.  To support their release, they asked us to share our opinion on the topic.  Here is our response:

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.

Ryan Martens is an amateur triathlete,  founding board member of the Entrepreneurs Foundation of Colorado, and CTO at Rally Software Development.

Jean Tabaka: Let the System Talk

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 Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development.

Last week, 10 of us from Rally product development, sales and coaching attended the Lean Software and Systems Consortium’s 2010 conference in Atlanta.  For me, the learning highlights of the conference were in the Systems Engineering track  led by James Sutton. To kick-off his talk on Lean Systems Engineering, James used a number of compelling stories around different systems and what guide them.  As part of his introduction to systems, he played this hilarious Dave Snowden video about how you plan or act based on one of 3 systems in which you might find yourself -- Chaotic, Ordered and Complex.

David Snowden -- Cognitive-Edge -- Ways to Plan a Party

James, a Systems Engineer, Principal with Lockheed Martin, is an invested member of the Lean SSC board as well as a technical advisory member.  He is the deepest expert that I have ever met in the field of systems engineering. And he has a wonderful gift for bringing multiple resources to bear in helping people understand and care about systems. For a Civil Engineer and Computer Science major like myself his talk and track were the definition of a prop-spinning geek nirvana.

Systems are guided by the pressures that form them

The point of view that James imparted on us was to understand that there are fundamental systems in which we operate. They are not value-based; one is not better than the other. They just help us set context and inform us about the world around us. Why should we care about this? How you approach your product and project development depends on which system  you find yourself in. And, as it turns out, the system you find yourself in is largely guided by one of four compelling pressures. That is, you will recognize the system in which you operate based on what is driving you to act.

There are four fundamental pressures that guide us: abundance, scarcity, desperation, or conformity. And each leads to a different system context. To illustrate this, James led us through the story of four different nations following the second World War.  Each nation, responding to different drivers, led to advances in different types of systems management approaches in use today.

• United States -- Abundance -- Systems Engineering

• Japan -- Scarcity -- Lean

• England -- Desperation -- Chaos Theory

• USSR -- Creativity and Conformity -- Patterns of Inventiveness
  

The Four Systems

Given this sense of what guides particular systems, James explained that we live in a world of four fundamental systems: Simple, Complicated, Complex, Chaos.

Cynefin

Once you recognize what system you are in, you discover what principles and practices will best serve you in that system. But systems tend to not be static. So, James presented what agent or pressure might cause you to move to a different system and therefore what tools and practices would guide your thinking and actions for transition.

For instance,  if you are in a Simple system and are moving into a Complicated system, Lean Manufacturing and Analytical Systems Engineering are your best tools and guides. If, however, you are in a Complex system verging on Chaos, you’ll work best relying on the perspective originated by Dave Snowden: Cynefin, the Welsh word for “the place where you hold multiple things.” Cynefin serves Complex systems well as it emphasizes emergent behaviors and, what Snowden refers to as “sense-making.”

The history and vision from this talk became almost a grand unifying theory for me. It all made great sense. If you are a  systems engineering fan, do not miss the recorded version of this talk when it becomes available.

Thanks Lean SSC

While 6 speakers and several attendees from Europe were prevented from attending the conference due to the Icelandic volcanic ash cloud, the Lean SSC rolled with the punches and pulled off an excellent event. The folks able to attend and the over 40 sessions offered created an electric buzz both in the air and on Twitter. Given the caliber of sessions, hallway discussions, and Open Space,  I am sure there will be many posts that emanate from attendees. And no doubt new ideas will be growing that were nurtured by the conference. Kudo’s to the Lean SSC board for creating a space for this excitement and emergence.

About the Authors:

Today we announced Rally’s acquisition of AgileZen, a visual project collaboration tool that manages work using the Lean concept of Kanban. AgileZen is a simple, elegant project collaboration tool that supports software development by providing a Web-based Kanban board.

Our definition of Kanban

If you aren’t yet familiar with Kanban, there are lots of great resources out there. The simplest description we could come up with for Kanban and Scrum is in our press release, but we welcome your thoughts and additions:

Kanban literally means “sign board,” and in Lean it is the signaling tool for visualizing and tracking work as it flows through various stages of a process. A Kanban board does this by exposing bottlenecks, queues and waste in a process so that teams can deliver high quality, high value work. Both Scrum and Kanban methods focus on early value delivery, and both provide transparency into the work in progress.  But Kanban can operate with a different planning and delivery cadence than Scrum and emphasizes different metrics.

What does this mean for Rally and the industry?

We believe that Kanban is a simple but natural extension of Agile software development. It will invite more teams into Agile and provide more runway for mature teams. But most importantly, it will help us extend Agile beyond development teams to create an Agile business. The AgileZen team has been effective in all of these areas. We are in heavy learning mode and, at least in our view, the entire industry is still figuring out how Scrum and Kanban work together and which methodology is better fit for various projects.

Welcome Nate and Niki Kohari!

Nate and Niki Kohari, co-founders of AgileZen, have built the best Web-based Kanban board out there, and we have the utmost respect for their product, company and brand. We are incredibly excited for them to join our North Carolina office.

What does this mean for AgileZen?

First, you should read Niki’s blog post. Not much has changed for AgileZen users. Together, we’ll continue to support the AgileZen solution as a low-cost Kanban-focused project collaboration tool, and users can access support as they always have.  If you aren’t familiar with the AgileZen product yet,  check out their free product.

Join us at the Lean SSC Conference in Atlanta next week!

The Rally and AgileZen teams will present our products and coaching services at the Lean Software & Systems Conference 2010 in Atlanta April 21-23. Ryan is also speaking on Plan-Do-Check-Act. We look forward to seeing you there!

About the Authors: Ryan Martens is a goat cheese maker,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

On April 21 in Atlanta, the Lean Software and Systems Consortium will come together for its second US conference.  Last year’s event in Miami was “amazing” according to Jean.  So this year, Rally is exhibiting, I am speaking while Jean and Aaron are running the open space on Friday.  The price per attendee goes up by $250 on March 31st, so if you do intend to go, REGISTER now.

At our booth, Rally will be demonstrating its product support for highly-visible Kanban, WIP/Cumulative Flow reports, and cycle-time  metrics. Join Alan Atlas, Jean Tabaka, Aaron Sanders and Craig Langenfeld in our booth.

I will be presenting an experience report titled: PDCA: Beyond Simple Inspect and Adapt. On spring break this week, I’ve been thinking more about the details of my talk. Here is my abstract and outline for those of you who might consider attending:

Lean and Kanban focus on practices of continuous flow of product delivery. Plan-Do-Check-Act (PDCA) is a Lean discipline that moves beyond inspect and adapt of Agile team-level processes.  At a corporate level, PDCA provides guidance for strategy as well as problem-solving work. In 2009, I led Rally’s move to PDCA for the company’s strategy process at both the annual and quarterly levels.  My primary guide was Pascal Dennis’ “Getting the Right Things Done”. In this experience report, I share Rally’s PDCA first year of adoption: where we started, how this impacted our corporate behaviors, and where we are now. I want to share Rally’s story to compel participants to embrace PDCA and get good at it. I ask each participant to come with its organization’s #1 goal and success criteria. I will close with a planning A3 exercise from Pascal’s book .

Outline

1. What brought me here—background on why I am passionate about sharing my organization’s overall Lean story including the addition of PDCA, A3’s and concurrent set-based development.  This talk focuses on PDCA as the critical step in increasing structure and discipline in strategy execution.
2. Point of View – Use PDCA to move your planning horizon out and as the principle governing mechanism for organizations in continuous flow.
3. Benefits — Mature your strategic planning and execution environment to handle the complexity of increasing speed, agility and scale and to gain alignment, pull and innovation.
4. Where we were and what was not working
   1. The context at Rally was based on a couple of key concepts:
      1. Core Values, Core Purpose, Sandbox and BHAG from Jim Collins
      2. 3 to 5 Quarterly Rocks, success criteria and Scoreboards from Gazelles
      3. Rock team structures  – cross departmental and story based
      4. Facilitated, highly collaborative cross-departmental meeting of 30+ managers and above
   2. What we noticed
      1. Rock work as a second or third job
      2. Wisdom of the Crowds to help fix over-reaction and group think
      3. Too much on the fly, not enough backlog grooming
      4. Highly critical, non-cross departmental initiatives were de-prioritized
      5. ORID process added to keep from jumping too solutions, but the data was not visible enough
5. What we decided to do about this:
   1. Explanation of PDCA — A brief overview of PDCA in general and then specifically what I used as guidance from the Pascal Dennis book, “Getting the Right Things Done: A Leader’s Guide to Planning and Execution”.
   2. Our initial experiments with A3 process the year prior — Working with our Ops team and product marketing teams on problem solving using real data
   3. First quarter — How we kick-started Rally’s company-wide adoption of PDCA . I describe our “Mountain Team” and their transitional role.
      1. Defining Rally’s True North
      2. Creating our second level tree with current and needed metrics
      3. Socializing these throughout the company seeking feedback in anticipation of our annual and quarterly planning
      4. Started new experiments based on quarterly planning decisions
   4. Next Quarter – Review new experiments, discussed learning and drive A3’s into the planning process
   5. Mid-course adjustment by Mountain team, in middle of the quarter – What we discovered working and not working
      1. The rocks were all dependent on each other.
      2. Had to run Rock of Rock team meetings to steer to a final solution
      3. Coordinated release planning would have
   6. Final quarter – We worked to expand the plan. We took the Mountain team’s True North and feedback to drive our PDCA for Rally’s Annual Corporate planning by:
      1. 1. Taking company-wide feedback into our Annual planning to collaboratively drive cross-department A3 creation around each branch of the tree
         2. Mountain Team retrospective over the course of year 1 that helped create a planning rock team.  The Mountain team’s role as a transition team ended.
   7. Year 2 – Doubling down our efforts to go from amateurs to intermediates —Changing our process to institutionalize A3’s and PDCA as our strategy execution approach:
      1. Quarterly rocks moved to a world of pre-defined from developed on the fly
      2. Quarterly planning moved from ad-hoc based on yesterday’s weather to more programmed based on True North and meeting the target metrics
      3. Strategic planning worked to validate annual True North in the context of long-term planning, shared vision development, cross-boundary collaboration and larger systems
6. What we learned and what you should do about it
   1. The cycle of adoption is a year, quarterly cycles work to improve the process, but it is hard to make leaps on a quarterly basis.
      1. Year 0 – Introduce Lean thinking (A3 in our case)
         
      2. Year 1 – Introduce PDCA (Novice)
      3. Year 2 – Invest or abandon (Your choice)
         1. A3 is now the language for problem solving
         2. Making sure we are solving the right problem (aka slowing down to speed up)
   2. Do not have a overall guidance team steering the continued PDCA process – it is owned by the “team”
   3. Putting pressure on the organization to get more clear about our economic models to mature from “Theory-based decision making toward the right solution,” Now “Data-driven decision making toward the right problem”
   4. Where to start – The Strategy A3 an exercise
   5. What is next? – We call it the Innovative or Lean Organization. Seeing large systems, collaborating across boundaries and creating your reality.
      
7. Point of View – Use PDCA to move your planning horizon out and as the principle governing mechanism for organizations in continuous flow.
8. Call to Action – Introduce the language of A3’s through problem solving or Strategy A3’s
9. Benefits — Help build a company of problem solvers to focus your efforts on the critical few things.
10. Where I hope you go with this: Great companies build great software, great experiences and work on creating win/win scenarios.
    

I’ve noticed a piece of advice repeated in many Agile blogs, articles, and books.

Seeing it makes me roll my eyes until it hurts. (Why I would hurt myself on purpose will be the subject of another post, on a blog reserved for psychotherapists.)

Even my very most favorite Agile book, “Scaling Lean & Agile Development” by Craig Larman and Bas Vodde, has a section in there with this advice.

I saw it in Jim Highsmith’s new book, too, although by the time he’s done discussing it he does make a couple of good points. It’s an old piece of advice that pre-dates Agile.

What is this old chestnut? Here it is:

Hire the best.

I mean, come on. Is this supposed to be a big lightbulb moment? Where do they find stuff like this, in the “Journal of the Totally Obvious?” Am I supposed to leap out of my chair, smack my forehead and exclaim “Eureka! All I have to do is hire the best! Why didn’t I think of that?”

Is this really good advice? Is it actually possible, or necessary in an Agile world? Is this sensible, if trite, piece of advice useful at all? Talk amongst yourselves while I blather on for a bit.

The problem with “Hire the Best” as an operational principle is that:

a) it immediately excludes most of us, and
b) it’s extremely difficult to do.

What’s the best? The top 5%? 10%? Certainly no more than 20%.

So what about the rest of us? What are we supposed to do? Are things hopeless for us? Should 80% of companies worldwide just give up and shut down because the top 20% of people are taken? What about big companies and the Law of Large Numbers? Can you really hire only the best when you’re hiring 10,000 or 20,000 people?

Something that makes much more sense to me, and which has much more power, is this idea:

Hire well, and develop people.

Check it out! Everybody can do this. “Develop People” is one of the two pillars of Lean, while “Hire the Best” is not. So far, those Lean folks have been right about pretty much everything, so why not this, too? Why would I need to develop people if I only hired the best? Why not save the money so I can pour it into my “Hire the Best” employment initiative?

The Agile Principles say something like […find motivated people and trust them…], and I believe in Agile. So I cannot find in the bedrock of either of my professional beacons, Lean and Agile, any indication that I should “Hire the Best”.

My common sense and experience tell me that it is incredibly hard to actually hire the best, and I like that it might not be absolutely necessary for success. How cool would it be to hire the ‘pretty good’ and then kick the butt of some company that thought it was hiring the best? Is that possible? Yes.

“Hire the Best” is really hard to do.

I’ve worked as a full time hiring manager at more than a dozen companies, all of which thought they hired the best and only one of which actually did. That company really worked hard at hiring the best. At that company, one rule of the hiring thumb was that you only hired people onto your team who would immediately place in the upper 50th percentile.

In other words, when you were on an interviewing team in that company, you were expected to vote to hire somebody who was better than half the people on your team. You think that’s easy? You think that isn’t scary? Try it sometime.

What I’m really really really interested in is something that can take my average team (and let’s face it, Ms. Wishful Hiring Manager, it is overwhelmingly likely that our team is average, for some value of average) and make it better or improve its ability to deliver value to my customers. That’s worth some effort to achieve because it is worth money to my business. If I believe in “The Art of the Possible” then I like this better, because it’s a lot more possible than simply hiring the best.

Anybody can embark on a long, expensive and likely unachievable quest to only hire the best, but if Agile were really valuable,  it would help me to take my team of competent professionals and make them significantly more effective than they were. It might even make them more effective than a gaggle of “the best” somewhere else.

The Agile Principles talk about motivated people, but they don’t actually mention “the best”.  I view this as a good thing because I strongly believe that the best teams are not built from a homogeneous mix of the smartest, fastest, bestest people.

Teams work best when they are diverse and when the power of the team can be unleashed by empowerment and self-organization. I also know from bitter experience how hard, and frankly scary, it can be to really hire the best. (Sorry if I harp on that, but I have scars…)

What I want is what I think both Lean and Agile offer to me as a businessperson. They offer me a way to take solid professionals and then ignite their passion and professionalism within a framework of continuous learning in a way that allows them each to contribute to the fullest extent possible.

That’s something that make Lean and Agile worthwhile to me, and not some lazy idea about hiring the very best (somehow) and then automatically winning.

About the Author: Alan Atlas is a Soul Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.

Looking for the perfect trend article to pass on to your executives about Agile development? Check out Dan Woods‘ well-researched, executive-level article “Why Lean and Agile Go Together” on Forbes.com Jargon Spy.

Dan describes how the Agile impact in software is similar to the Lean impact in manufacturing of the 90′s.  I initially struggled with the analogy until I realized he is not saying that software development is like manufacturing. He is saying that the concepts and techniques applied in Lean manufacturing are coming to large-scale software development.

I completely agree and believe the model of how we build software is changing just like Dan describes.  Using the model from the Fifth Discipline Fieldbook, the change looks like this:

Lean Software Concept

That was a great decade – I see much of the last decade of improvement coming from a real effort to take responsibility for how we perform our craft.  The ground up work in Agile, Scrum, XP and Lean has increased velocity, increased quality and increased the quality of life for many in our industry.  I am personally in a much better working environment; how about you?

So what’s ahead for 2010?- With Agile software development hitting the mainstream, the guiding ideas on how to design and deploy software is changing for most software driven organizations.  As more teams and organization make the transition to the Agile/Lean triangle, I see us increasing our investments in skills training, teaching, experimenting and innovating with an increasing number of new tools, techniques and methods.  As a result,  I see this decade moving us past the Lean models of Toyota to something uniquely our own.  I am really excited about the improvement this decade could bring to our industry and all the industries that we impact with our software.

About the Author: Ryan Martens is a goat cheese maker,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

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.

With this back-drop, I am motivated by the notion of creating a  A Community of Thinkers,:

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:

• Lean Software and System Professional – new certification emerging
• Agile Developer Certification – that is also emerging
• Certified Scrum Practitioner – especially as it intertwines with the PMI’s Agile Community of Practice

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.

That is my hope for 2010 in our profession.

About the Author: Ryan Martens is a happy father,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

Recently, I wrote the post “Escalation is Killing Agile – Can We Please Stop It?”  My passion around escalation brought 40+ in-depth comments.  With my travels and lack of internet access, I had been unable to sit down, sift through, and absorb all the various perspectives.  Until now.

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:

1. What is the relative measure that pits one party against the other and can you change it?
2. What are the significant delays in the system that may distort the true nature of the threat?
3. 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:

1. Show up. (Be willing to be engaged.)
2. Find out what has meaning to you. (Be willing to be honest about your perspective.)
3. Tell your truth. (Be articulate about your insight without attacking or assigning blame.)
4. 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.

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.

At Rally, we are always working on both maturing and growing our use of Agile. We started with a single development team and over the past 6 years have been through the process of splitting, growing, partnering, and acquiring.

We did this while continuing to inspect and adapt our development and our strategy execution processes.  We have teams in various stages of maturity using Scrum and Kanban to run all parts of our company.   As the CTO, I have my focus on our strategic planning and execution process.

In 2008, I started to focus on maturing our annual and quarterly planning.  To do that, I used Pascal Dennis’ book titled “Getting the Right Things Done” to structure those efforts.   (See related post about Learning from A3′s a story of 2009 Quarterly Planning at Rally.)

As part of that effort, we worked to change our quarterly and annual planning process to specifically follow a Plan-Do-Check-Adjust model. (Note that I like Pascal’s use of Adjust, not Act which is typically quoted in the Toyota models.)

Prior to 2009, we were simply using an inspect and adapt process to determine annual and quarterly priorities, aka quarterly rocks, based on feedback from last quarter’s results and the corporate roadmap.

This process worked well, but we had some issues including:

• A moving definition of done based on different standards of work (research, implementation, campaigns..)
• A delay in the feedback loop on strategic efforts made it hard to check and close well
• Too many efforts in a quarter lead to poor quality (We found 5 rocks to be too many for us during a quarter)

None of these are different than what most teams experience with going Agile.  So we (1) adjusted and moved to limit our WIP to three rocks, (2) focused on inspecting the definition of done in the meeting, (3) used company wide survey’s to keep from developing group think and (4) chose to do company celebration based on quarterly metrics and not the completion of quarterly rocks.

These all helped make the current process work, but the process was still frustratingly unpredictable, semi-random and always left something to be desired.  Many of the reasons for this are explained in Alan Shalloway’s and Don Reinertsen’s posts on PDCA and types of process The Difference Between “Inspect and Adapt” and Plan-Do-Check-Act (PDCA). Unlike Alan, I do not see or perceive a big issue with Scrum.  Based on my previous post around the roots of agile; Dean Leffingwell and I are in the same camp; Scrum is Lean.

As a result of moving to PDCA approach, we created a single “True-North” goal for the year and drove our quarterly rocks  towards that goal.

Now in Q4 of the year, we had some new changes to our process. By following the PDCA cycle for the year, we put a fine point on CHECK in this final quarter; Subsequently, we have a  Q4 quarterly rock focused solely on checking our Q3 and annual work to fine tune it based on real output.  This is an example of where PDCA cycle is more intentional than basic inspect and adapt at forcing the discipline of checking.

We focused a quarterly rock on checking  to make sure that we are done-done-done with our True North goal for the year.  We also have another Q4, cross-functional rock team focused on preparing for Q1 and 2010 annual planning.  This PDCA-driven rock is a major milestone for me personally.  It moves annual planning solely from my shoulders to a team effort; this pushes ownership of strategy down to the extended management team.  As a result, I am very happy with the move to PDCA for our 2009 strategy execution process. In Don Rienertsen’s terms,  our PDCA-driven process is more defined, while still with un-predictable output and governed with lots of feedback.   This was simply an increase in process maturity that was mandated by our continuing growth.

To do this, we create a team, called the Mountain team, to help the company transition our strategy execution process.   This team steered the transition and proposed our quarterly rocks based on the PDCA process.  And thanks to the ego-less and steady hand of our CEO, we have a very collaborative culture that quickly converge on these changes and quickly put them into action.

I hope this was helpful for you to learn about our experiences with continuous process improvement and our step-function transition processes.  Please note that we are not a perfect comparison to larger organizations trying to transition to large scale agility.  In addition to doing lots of growing, we have another difference that started when we began back in 2003.  We built Agile and Lean principles into our core values.  You can see the difference this might make in my comments to Israel Gat’s post More on Agile Social Contracts.

Specifically our core values are:

• Create your own reality
• Make and meet commitments
• Theory-driven decision making
• Treat people with respect
• Support our community and give back
• Maintain a healthy work/life balance

This is the social contract that we keep with employees. During transitions like this you need culture or a social contract to reinforce your moves toward Agile and Lean behaviors.

About the Author: Ryan Martens is a telemark skier,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.

I’ve written previously about my allergic reaction to process maturity models for Agile development. Based on 5 years of empirical feedback being a part of or watching what  succeeds versus falls back, I do not believe there is a “cookbook” for Agile adoption. Of course, the question then becomes:

If there is no cookbook, then what is the best approach to succeed with my Agile adoption?

Enter the crib sheet for Flow-Pull-Innovate, which is a guidepost for the key transitions in Agile organizations based on proven bottom-up success. Because the hurdles and challenges are unique for each organization and code base, this is not a prescriptive approach. It’s a framework to thinking about how to approach Agile adoption incrementally and iteratively and is essential to establishing quick wins that create a virtuous cycle of success to keep the ball rolling.

The three phases of Agile maturity are based on work by Jim Womack in his book Lean Thinking.  However,  Jean and I thought it was appropriate to substitute “Innovate” for “Perfect” in Agile organizations.  In IT/high-tech, it seems more about continuous innovation than the ultimate pursuit to “resource” efficiency.

Getting Over the Hump - Critical Step #3

Over the past 5 years, our focus at Rally has been getting our customer’s successful at Step 3, which we call Multi-Team Program Pull. (See our whitepaper on Leaning IT and moving to Program Pull.)

We focused on this step because at Program Pull, whole software products or major IT systems come to market typically 50% faster, according to the QSMA studies included in the Agile Impact Report. However, in this tough market and with mainstream Agile adoption, more and more organizations are adopting Agile at scale, making it important to light the path beyond Program Pull and into Organizational Pull and Organizational Innovate.

What do you think of the crib sheet for Flow-Pull-Innovate? Do you agree with the key metrics? Are these failure signs you’ve experienced? Would your organization be willing to stand behind items in the commitment needed column?

About the Author: Ryan Martens is a trail runner,  founding board member of the Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development. Subscribe today to get free updates by email or RSS.