Don't let this be your user!

Recently, my Rally colleagues Ben Carey and Ryan Martens delivered a great webinar about testing and quality.  What particularly struck me about the session was how Ben set up why we should, at a very personal level, care about testing and quality.

Enter Amy and her daughter Morgan.

As Ben told the story, Amy was a back office admin in a physician’s office. It was her responsibility to get billing out to insurance companies for the practice, and on one particular day, things were not going well.

She kept getting cryptic error messages. The batch just wouldn’t go through. Stress mounted. To add to Amy’s distress, it was nearing time for her to pick up her daughter Morgan at school. Morgan had just started school. Only 4 weeks in, Morgan was suffering some separation anxiety. Amy felt the urgency to be there for Morgan as soon as school let out. And yet, she was stuck at her desk dealing with these insurance issues.

Why should Ben be talking about Amy and Morgan in a webinar about testing and quality? Because Amy was Ben’s customer. Ben was on-site to see how his software was supporting the practice. And so, he personally felt Amy’s mounting stress in using the software HIS team had delivered and HER doctor’s office had paid for. When Amy started to cry, it was all over for Ben. He had to do something.

What does Amy and Morgan’s story tell all of us?

1. Users deserve better than this.

2. On an Agile team, quality is everyone’s job!

We often think of testing as an issue for the tester role alone.  But this stance sets a number of bad dynamics in motion:

• When we don’t fix defects, we declare doneness by “hiding” defects in a defect backlog
• Hidden defects accumulate into hidden technical debt
• Technical debt slows down our ability to deliver subsequent releases
• An ever-increasing defect backlog can be demoralizing for the entire team
• Engineering resents the business when being forced to deliver features when the engineers know defects exist
• Business resents engineering for not being better and faster at building features
• Testers resent testing left until the end because it puts business, engineering, and testing in a tight spot

So here is a thought: quality is not just an engineering issue; it is a systemic issue. That is, it is driven from the top down in a business not from within one part of the organization. A business policy about quality impacts our users by directly impacting their quality of life. Amy’s stress about picking up Morgan from school could be traced back to a testing and quality policy in engineering that was driven by a policy in the business: get features out.

As you adopt Agile, work vigorously to create rigor in your testing and quality goals. Why? Because your policy can hit hard in ways you don’t currently track. Pay attention to more than just the internal cost of technical debt. Let’s pay attention to the quality of life of our users.

The next time you are logging a defect versus fixing it, don’t forget about your Amy and Morgan.

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 was raised in the land of big software releases.

I spent over a decade celebrating the release of software to gold master at five different companies.  These events included plaques and various levels of behavior based on the amount of flesh that was lost in the release.  A few of them were great, but many of them left a bad taste in your mouth based on what was shipped or not shipped.

Early on at Rally, it was the same way.  We celebrated releases.  In our case, the numbered releases come about every 6 to 8 weeks.  I can recount having some over-the-top release parties, but mostly they seemed empty.  Now, we have moved to a world of release lunches.  These lunches now come after our retrospectives allow us to close the cycle well.  I do not consider them celebrations as much as a way to close.

Now we do something quite different, we make fun and celebration part of the agenda for every release planning.  As a result, we have events spread throughout the release and in many cases tied to holidays.

For example, here are three of the “scrumkins” entered in the Halloween contest.

In another example, last week we had Formal Friday.  Formal Friday involved everyone wearing some type of formal wear to work.   In a software company with T-shirts and shorts the typical attire, it was quite a shock to see many of our team members wearing a tie.  I honestly thought there was a funeral.  See for yourself.

Jeff's Pink Suite was the unanimous favorite

These examples of celebration build teams, trust and relationship much more that the big bang events of the past.

The source for this change started back in 2005 when we had a great Technical Advisory Board.  At one of the meetings Luke Hohmann game me a copy of Managing to Have Fun by Matt Weinstein.  It is a great book with some great ideas.

At this same time we also hired Melissa Gallegos onto our team.  Melissa moved from a role in QA to become our ScrumMaster.  She runs release planning and scrum of scrum meetings.  I shared Weinstein’s book and some ideas with Melissa as she started to move into the role.  In 2007, as Melissa began to get her stride, she became the official Master of Fun at Rally.  Melissa is a natural; as demonstrated by the blow-up palm tree and tons of toys on her desk.

So I ask, who is your master of fun at your company?

At Rally, we tend to celebrate as a company based on external validation.  External validation includes awards, product reviews, customer feedback or financial performance.  We do this because external wins are a whole company effort.  We focus on closure and managing to have fun in the teams because Chris Avery and others proved to us that the key to high performance teams is trust, relationship and shared purpose.

Happy Halloween! enjoy the Day of the Dead and your own celebration.

About the Author: Ryan Martens is a mountain biker, 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 was teaching a CSM course a few months back when a question came up, as one often does, that needed an answer built around the concept of swarming.

An extremely creative example of the swarming concept

Swarming is something that is strangely alien to many folks in software development, so I’ll explain it here. Also, if I don’t explain it here then I won’t have enough to make a good blog post, and we can’t have that, can we?

The idea of swarming is to get the whole scrum team, or as much of the team as possible, to all jump onto a Product Backlog item (PBI) together and get it done in one fell swoop, as quickly and decisively as possible, by working together.

This has the benefit of being fun while at the same time implementing the idea of value-based delivery on the micro level. If a team swarms, it will tend to complete PBIs one after another rather than starting on several PBIs at a time and not completing any of them. So swarming on PBIs in priority order tends to deliver them in priority order while at the same time reducing the number of partially done PBIs (often called Work in Progress and considered to be a Bad Thing) that are hanging around waiting to be finished.

Swarming is something that good scrum teams do.

Side note: Those of you who are constantly asking what to do about the problem of testers not having anything to do until the last two days of the sprint, you should read this post twice. Those of you who are constantly carrying over unfinished PBIs to the next sprint, read this three times.

So, in response to the question, I told the story of swarming to the CSM kids as we sat around the campfire in the training room, eating smores, and they were enraptured. Entranced, really. Lightbulbs were flashing above heads. For some reason, for this class, the idea of swarming really hit home.

We had already discussed the Tuckman model of team dynamics earlier in the course. The Tuckman model, based on observations of lots of teams, simply lays out a four-stage pattern that teams seem to go through as they evolve.

The four stages of the Tuckman model are Forming, Storming, Norming, and Performing.

• Forming is fun because everything is new and nothing bad has happened yet. Of course, not a lot gets done during this stage, comparatively speaking.
• Storming is what happens as the team begins to try to get work done and the inevitable power struggles and turf wars begin. It’s not a particularly fun time, but it seems to be something that just happens when people try to work together.
• Norming occurs as the team resolves its internal strife and figures out how to work together.
• Performing is where the team can go when they learn to improve from their Norming plateau into a highly productive, smoothly-operating group of peer professionals.

The phrase “Forming, Storming, Norming, and Performing” is familiar to people who have been exposed to the Tuckman model for as little as 2.5 minutes.

So, in a burst of enthusiasm, one of the students in my class (remember the class?) suddenly shouted (well, to be honest, he only said it in a loud voice) “Forming, Storming, Norming, and Swarming!”

Which was great because Swarming is kinda one quick way to describe a Scrum team that is in the Performing phase.

Everybody laughed happily, and I thought, that’s a blog post right there. And look! I was right.

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.

Just published in Dr. Dobb’s is my article on Agile Social Contracts;  It covers the process of Agile rollout planning and the burning need for a clear commitment to your teams and organization.  What is not as well covered are the other four components.

I make the argument in the article that Agile enterprise adoption is easy, if you are prepared and crisp with the right structure and discipline.

Here are the five items you need to be successful at Agile release planning or Agile Enterprise Rollout planning:

Release Planning Structure		Agile Enterprise Rollout Structure
Team – Cross-Functional Development Team	1	Team – Cross-Function Transition/Steering Team
Commitment -  To the Definition of Done	2	Commitment – To changes in external metrics
Contract – Team Norms	3	Contract – Social Contract with the Organization
Roadmap – Product Increments	4	Roadmap – Flow-Pull-Innovate transition steps
Vision – Product/Service	5	Vision – Organization, Process & Technology

Agile Rollout planning is best done like sprint or release planning. This is what I and others mean when we say “using Agile to rollout Agile.“  We use the same methods, structures, and process to rollout Agile as we do to manage our development.  This gets senior managers and executives talking and experiencing Agile along with all the practicing teams.  It leads the transition team to the benefits of visibility, alignment and frequent feedback cycles.  When this is done, it makes Agile Enterprise rollouts as easy as Agile software development.

For more details on our approach to enterprise Agile rollouts, please see the post An Alternative to Agile Adoption Cookbooks – Flow, Pull, Innovate.   This approached is based on a concept of  Shu-Ha-Ri (See Alan Atlas’ post on DIY vs. Shu-Ha-Ri).

For a detailed example on a rollout plan that uses the Flow-Pull-Innovate approach – see the post Agile Transition Plans – an example.

About the Author: Ryan Martens is a backyard chicken farmer, 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.

Sarah: “Walter, I just want to check in with you following the team demonstration and see how you are doing with the new Agile approach”

Walter: “Sarah the results were thrilling for the customer and the team.  Everyone seemed engaged and the dialogue was very healthy. I see it, but it does not make sense.  We are moving features through the team faster, but I had to do this with dedicated resources.  I am sure this is costing me more.”
Sarah: “Walter, this is totally normal.  You are seeing the difference between single tasking and multi-tasking as well as optimizing the whole versus a certain roles or steps.  We can do a little model to show you that this Agile approach is better, faster and cheaper.”

Walter: “Well that would be very good because it is very counter-intuitive to me and all my management tools and tricks seem to run at odds with this approach.”
Sarah: “Great observation, Walter!  As you told me earlier, you tend to focus on fully allocating engineers.  In Agile we focus on increasing the throughput of value by optimizing the whole flow through all roles.”

Walter: “Right now I just want to stay out of the way, because I do not know how to help.”
Sarah: “Walter, let’s spend some time to get you comfortable with the impacts of batching, queuing and task switching.  Once you see the math, we can talk about how to serve the team by proactively clearing impediments to smooth flow and taking some savings to invest more in them.  The team will love you for this commitment.”

What benefits will you see when teams are in Flow?

As we described in “What so Great about Flow?“, we think of attaining Flow as the first step in our recommended approach to enterprise Agile adoption.  For this step, we focus groups on adopting agile by the book by team; thus the impact from Flow is only incremental and isolated to the specific team.  However, this does not mean the results of this effort are not noticeable and infectious.

Foremost, groups that attain Flow make changes on the way to becoming a team.  When given space and dedicated members and short time box, new agile teams take three key steps:

1. First the collection of individual contributors comes together to plan a limited portion of their own work. 
   
2. Second they set norms and limits that lead to common commitment to deliver working, tested increment. 
   
3. Finally, they open their increment up to feedback and open themselves and their process up to feedback, introspection and adjustments for continuous improvement. 
   

The benefits seen from doing this are many:

• A team is forming and that makes work more fun and easier for them to manage
• Work-in-process is getting reduced by focusing the work on a small increment of functionality
• Testing is coming forward in the process and quality is beginning to become a team issue
• Hand-offs and delays are declining by dedicating a cross-functional team to working on one thing at a time
• Feedback loops are shortening in the demonstration and review process helping to prioritize the next step

Typically these benefits take one to three iterations to manifest themselves and translate into incremental productivity increases of 15%, 25% faster cycles and a reduction in downstream defects (See the Agile Impact report for more details of business improvements from Agile).  Most of these teams are reporting the benefits of flow.  Teams in Flow settle into a predicable pattern of delivery.  They are not perfect, but you can count on them and estimate based on their historical velocity. We look for these metrics to know if a team is in the state of Flow including:

• a rate of 90% or greater of Story Acceptance per Iteration on an iteration over iteration basis
• an average of zero net, new Defects added to Defect list across iterations
• A reduction in 1/2 of the amount of stories that are in-process across iterations
• A continuous build success rate of 90% or greater for the team’s isolated code base

In general, they are starting to do things in a more lean and less wasteful way.  By working together on a small batch of work with a clear definition of done, it allows the team to focus and reduce the task switching.  To understand why multi-tasking and task switching do not work, you should read this post from Mark McGuinness at Lateral Action or check out Tom Demarco’s book “Slack” and specifically pages 16-21.

However, the most important benefit is the positive feedback from the team members with regard to forming a team and working in this intuitive and social approach.   It is this positive feeling that propels teams to move past Flow and into Pull.  Congratulations if you have the continuous improvement snowball beginning to roll downhill at your organization.  Building the trust and capabilities of the team is the most effective path to more value delivery.  (See “The Scrum Picture is wrong” and the comment/link about the Lean Journey from Jason Yip.)

If your team does not find this benefit, it is clear that there is a fundamental issue that needs to be resolved.   This is a great time to bring in an outside coach to help the team retrospect and give them space to form.  In these situations, it is easy overlook the fact that teams need to go through the process of of forming, norming, storming as they reach toward performing.  Remember this is a journey and you can not go there without building the team.

About the Author: Ryan Martens is a fly-fisherman, 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 do not believe there is a recipe for Agile enterprise transition plans because good ones must take the context and setting of the organization into account.

I do believe that starting step-by-step is the only way to get the snow ball of incremental improvement rolling down hill.  Our model, Flow-Pull-Innovate, is based on a strategy of creating a self-funding sustainable approach to adopting Agile; where some of the savings/profits from each step are reinvested in the next improvement step. (See my post An Alternative to Agile Adoption Cookbooks – Flow, Pull, Innovate for details on this approach.)

In addition to a step-by-step transition plan, you need a vision, shared commitment and social contract to be successful. Although, The Flow-Pull-Innovate model does provide sign-posts for your roadmap, the actual stories necessary to transition vary.  When we work with groups or organizations to build a plan that will take them from one step to another, we use a transition planning model that I helped define in the mid-1990’s.  This planning model is based on organizational change work from Peter Senge’s Dance of Change and Michael Hammer’s Reengineering the Corporation.

In this step-by-step plan, we use these high-level variables for planning change; “Strategy, Process, Organization and Technology.” In these transition steps, a typical story starts with the implementation of new technical and organizational infrastructure to support new methods, tools and techniques that lead to new way of working.  Download An Example Transition Plan (PDF).

An Example Transition Plan based on the Flow-Pull-Innovate model for Enterprise Agile Adoption

Again, please note this plan is very high-level and a fairly generic application of the Flow-Pull-Innovate approach. (See Jean’s post on What’s So Great about Flow? for more details on the first step.)  I have seen many variations on these detailed plans over that last 6 years.  Use this as a simple starting point for you and your group to think about your own situation.  If you work with Rally coaches to help you plan your organization’s transition, you benefit from their years of experience and ability to start with a clean white version of this model.

Transitioning to Agile at the enterprise level can be a very simple step-by-step process as long as you and your group thinks about it in this way. If you do a good job of defining “Done” for your steps, you will then be able to inspect your progress and adjust your plans based on empirical feedback.  In this way your adoption approach is just like the Agile process your adopting for software development; an empirical process that you steer with regularly schedule inspection and adjustment.

If, on the other hand, you think about the adoption as a “Big-Bang” that will be done on a certain date, I believe your “plan-driven” thinking will cause you to miss the real opportunity.  You will typically end up with only incremental improvement and not have the momentum to enable your teams to keep up the good work.  And, you will fail to get on the continuous improvement curve that will lead towards Agile/Lean expertise.  Given that most organizations are operating in a “plan-driven” world, this is not a surprising reaction to Agile adoption.   Agile success comes as you gain success incrementally by taking one step after another, while keeping process, technology and organization change areas aligned.

In CMMI, Level 5 teams get to a place where they “become continuous improvement teams.“  In enterprise Agile adoptions, we start folks at continuous improvement and watch them benefit from creating employees and teams that both solve their own problems and continue to re-focus on value delivery through each step.

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

Introducing Rally's Engineering Blog

As some of you have already begun to notice, the Rally Engineering team is now in full effect with their very own Blog.

This blog provides a great opportunity to (1) gain further insight into Rally’s development environment, (2) ask questions and interact with a high performing Agile engineering team and (3) learn tip’s and tricks from the team’s experience working in a wide variety of technologies.

I have read all their posts and there is something in there for all the rolls and levels of experience on agile teams.  It is unique because of the open authoring model for all members of a fast growing set of agile teams.

With 15 posts published, and many more regular contributions on the way, I invite you to join me as a new subscriber to Rally’s Engineering Blog (click here to subscribe and here to visit the blog)

About the Author: Ryan Martens is a fly-fisherman, founding board member of Entrepreneurs Foundation of Colorado, and Founder and CTO at Rally Software Development.

Your company is insane and you might be insane, too.

I bet you’re suspicious right now, aren’t you? You think this sensational opener is there just to suck you in and get you to read something that’s totally unrelated. Well, I mean what I said. Let me explain.

There’s this old joke. I think it’s a joke. Maybe it’s a saying. Or it could be an adage. I’m pretty sure it’s not an axiom and I know it’s not a koan. Hmmm. Might be a riddle. Anyway, where was I?

Oh yeah. The joke. It goes like this:

Q. What’s the definition of insanity?
A. Doing the same thing over and over again and expecting different results.

OK, so maybe “joke” was stretching it a little, but it is kind of pithy, don’t you think?

Why do companies want to adopt Agile methods? After all, it’s expensive and painful what with all the training and change management and readjustments and FUD (Fear, Uncertainty, and Doubt) and so forth. And why do people come to CSM courses hoping to find new ways to build software? Because they’re bored and they want to get into arguments with their management? Probably not.

I think the reason is the same for both. It’s because pretty much everybody wants better (different) results from their software development efforts. Management wants more software to sell, and they want it to be higher quality, and to arrive faster, and to be more liked by their customers.

Employees would like at least an even chance of succeeding in what they do, and they’d like to feel like they are contributing the best that they have to offer as a valued part of their company. They want to feel like an accomplished, highly skilled professional and not some interchangeable cog in a soulless production machine.

OK, fine. So far so good. Everybody is aligned. It’s win-win all around. What could possibly go wrong? Well, here comes the funny part. Nearly all companies, nearly all management teams, and many employees don’t seem to understand that getting different results is going to require doing different things, or doing things differently (I’m not sure if those two are the same or not).

When I’m teaching the CSM course or introducing Agile at a company, the minute I bring something up that is actually, obviously different from what they are doing today, somebody gets upset.

When one of my students gets upset, they start raising objections such as:

“Oh, well, we can’t do it that way at our company.” (Betcha you can.)

“That’s not how it is at our company.” (Isn’t that what I’ve been trying to tell you?)

“But what about having the complete architecture before I start? I have to have that!” (Should I do this the nice way or the mean way?)

“We can’t do all of that testing. We don’t have testers.” (Gosh, I hadn’t thought of that. I guess you’re right. Just do the Agile without the testing and you’ll be fine. I’m sure no one will notice.)

“We don’t actually have anybody who could be the Product Owner.” (Do you hear what you’re saying?)

“We have a very mature phase-gate development process that we have to keep in place as we move to Agile.” (Say what????)

“I’m a manager and I’m paid to leverage my maturity and experience by telling people what to do so they don’t make mistakes. I’ll be doing that with the Agile teams, too.” (Don’t roll your eyes…don’t roll your eyes…)

“Our QA is in a separate group and they won’t talk to us until we have a complete set of specs to give them.” (And how’s that working for you, and them, and your company?)

And on and on and on. I talk about this when I teach Agile to new teams or new CSMs and CSPOs. Then later on during the class, when they start in with this stuff, I can get away with saying:

“Oh! So you mean your company is insane. They sent you here to learn a new way to build software, but they won’t let you build software in a new way!”

This is fun because I get to call companies and my students insane in a way that’s fun and also makes a point.

What to do about this is a serious question for those of us who coach, train, consult, or champion Agile within our organizations. Teams tend to get it, but I fear that companies of a certain size tend not to get it. And they keep not getting it while their Agile adoption loses steam, fails to deliver as well as it could, and finally fades away entirely. This is where many of those “scrum failed” stories come from. What happened was that in reality, they didn’t really try scrum because they were afraid to change anything.

Your company is insane because what they wish is that you could somehow get all the benefits of Agile without making any difficult or scary changes. You might be insane because you think some things can’t be changed and we can still get the benefits of Agile without changing them. As long as either you or your company is insane, neither of you will get the benefits of Agile adoption.

I guess that’s all I wanted to say.

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

I have a systems archetype in mind that is troubling me. I am annoyed that some of the current (and past) one-ups-man-ship around Agile is distracting us from the useful constructive dialogue I crave.

The archetype I am thinking of “Escalation” is where “my fix is your nightmare and you have to lose in order for me to win“.

Situations can get sticky with too much escalation

Think of the American movie “A Christmas Story” about young Ralphie Parker and his own dilemma with “Escalation”.  In this classic scene, Ralphie’s friends Flick and Schwartz dispute over whether a person’s tongue will stick to a frozen flagpole. Schwartz ultimately issues Flick a “triple dog dare” (the most serious of childhood dares); bypassing “triple dare” and resulting in a serious breach of boyhood protocol.

Dares, blames, accusations and hard stances all contribute to the distraction and destruction that is associated with “Escalation”. When everyone is trying to win, the system suffers. Anyone’s “win” is nobody’s win; and anyone’s “loss” is everyone’s loss.

I see no place for this in Agile and yet the fight is on. Triple Dog Dares are becoming business as usual.

Escalation is Killing Agile.

So why the heck are we involved in so much escalation around things like “My Agile approach is better than your Agile approach” or, “Well, you’re only in it for the money” or, “I’m going to make fun of you until you stop what you are doing“?

How is ANY of this furthering my growth or our organizations’ growth in Agile?

In a systems view of the world, we can see patterns made up of balancing loops and reinforcing loops. In the case of “Escalation”,  we see factions sucked into a downward spiral reinforcing loop of fighting. The more someone fights, the more the fighting continues.

In our case, the fight may be about certification, or timeboxes, or engineering practices, or continuous improvement, or tools. Fights then lead to blaming and finger pointing. And in the systems view of things, once you get into blaming individuals or other parts of the system, your system is broken. Not the individuals, the system.

So in our Agile world, I ask, “How is this fighting useful? Could someone explain that to me? And how is it our system has metamorphosed into one that allows (encourages?) blame and mockery, one that remains so, or even worse, seeks to move further and further into this archetype?“

For me, a more useful approach is to find balancing loops. Here, we seek to create more knowledge in dialogue not blame. We seek insights with others interested in dialogue, not in escalating debates and accusatory blame. We look toward inquiry versus advocacy and so we seek people interested in this kind of work, not fighting.

One way I intend to take advantage of balancing loops is to seek people interested in Agile growth NOT in attacks on approaches or individuals. I’m thinking, for instance, of Linda Rising as a good example. Linda has been our steadfast beacon of reaching into kindness versus violence or fear or confrontation to use our personal perspectives usefully and creatively.

I’m done with all the distractions that don’t feed my growth. I’ve lost the ability to abide behaviors that don’t give evidence of what was written with conviction in the Agile Manifesto. The train has left the station on a number of initiatives within Agile, Let’s stop fighting them. More fighting isn’t going to make anything go away. Instead, we will just feed “Escalation”. Let us get on with where each of us can find and contribute to growth. Please.

Here is my personal commitment going forward:

My personal commitment is to seek those interested in creating more and more insights about how we can grow and learn. I will seek dialogue around various Agile approaches and what can contribute to the growth of Agile. I will not take delight in anyone’s cleverness or meanness toward an approach they don’t support. I will seek voices of engagement, deeper intention, non-blame, and creative inquiry. “Escalation”, to me, is like the old joke of trying to teach a pig to sing: it only annoys the pig and it frustrates you. I have no intention of spending time with such activity in Agile.  It distracts and annoys me. You’ll have to figure out for yourself how it serves you or hinders you.

So, moving forward, let us think about true dialogue. Let’s challenge ourselves if that is what we invite in each of our interactions. To add encouragement and inspiration, think about the etymology of the word – dialogue:

From the Greek “to gather reason through speech, usually between two people“. I invite each of us to reach for gathering not escalating.

Without this intention, we will all lose.

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.