There are other conferences that cover Agile software development, but the Agile 20xx show reigns supreme. At nearly 2000 attendees from around the world, this year’s show is happening at Walt Disney World in Orlando. (It was moved there after the flood in Nashville.) For the first time, three of the major analyst firms (and as a result 5 of the key analysts who cover Agile and ALM) are attending the conference – Forrester, Gartner and IDC.
Rally coaches, sales and marketing folk at booth setup
As a result of the show’s success, it has become the most significant market rhythm in our industry. So this week, we announced a few things:
I am speaking tomorrow on PDCA: Moving Beyond Simple Inspect and Adapt. (Thurs 9:00 a.m. in A-1). Other Rally speakers remaining this week are:
Get your Rally cap
Former Rally developer turned Rally technical account manager turned Rally coach Chris Browne speaks Wednesday on The Art of the Hackathon (Weds 15:30 – 17:00 in Asia 3).
Rally coaches Alan Atlas and John Martin speak Thursday on “Your Team, Your Freedom, Your Responsibility” (Thurs 15:30-17:00 in Asia 3).
Follow the news from the show on Twitter at #Agile2010. Come see us at the booth and get a Rally and Deliver ballcap. Or let us know if you’re not at the show and want us to send you one (send name and address to kcaraway@rallydev.com).
On the road to Agile adoption, I often get asked, “how do you get teams spun up on Agile fast?” The short answer is to just do it. The long answer is that I believe there are 3 options. 1) Rally and other Agile coaching organizations offer programs that place a coach in your team to help with preparation, planning, estimating, setting norms, committing, tracking, daily stand-up, demonstrations and retrospectives. 2) You can take the DIY approach, but watch out for the unintended consequences. 3) Finally, I think there is the intensive practice approach. Let me give you some examples:
A Sprint Per Day for the First Week
While speaking and attending Agile Vancouver in 2008, Linda Rising facilitated a fishbowl exercise with a custom development firm in Vancouver. Given they were starting and stopping projects and reforming teams all the time, they had developed an approach to speed the team through the formation process and inculcate new team members (employees and customers) to the process. The would run a scrum sprint every day for the first week. This intensive process would allow them to work through tons of issues in a very intensive week. I would call a form of this preparation over planning.
A Sprint Every 90 minutes for a Weekend
If that is not fast enough for you, how about a sprint every 90 minutes? That is what the folks at SnapImpact did last weekend in Boulder at their SnapCamp (based on the notion of Startup Weekend).
I heard about this from one of the organizers and fellow Sprint Triathlete Dave Angulo. Dave is co-founder of the non-profit SnapImpact, a guerrilla non-profit that has a mission to “Make Doing Good Easy.” They developed an iPhone application and Wordpress plugin to simplify how people learn about volunteer opportunities near them. It takes feeds from HandsOn Network and soon All for Good. It is cool, I’ve been playing with it for a year. Anyway, ran into Dave at a CTO lunch in the TechStar’s bunker today and he told me about the wild success they had with 90 minute sprint process through the last weekend.
To give some background, SnapCamp was the kickoff effort for developing v2.0 of All for Good, the platform which powers http://serve.gov and a number of other sites. It’s the largest single repository of volunteer opportunities in the world. Version 1.x was pushed into production quickly and, while it is up and running, there have been a number of technical limitations which have frustrated All for Good’s partners and limited the platform’s usefulness. SnapImpact offered to develop v2.0 of All for Good because of the close alignment of the two organizations’ missions and their desire to have a more comprehensive list of opportunities for their iPhone app.
Ryan – Tell me how the 90 minute sprint process worked at SnapCamp?
Dave - We started the weekend with dinner on Friday night to allow time for everyone to meet each other, learn about each other’s backgrounds, and have a shared group experience. We had people from all over the country as well as a great local contingent. Some were die-hard SnapImpact volunteers, others had only heard about us recently. The dinner allowed for folks to get to know one another in a casual setting without having to do it in between trying to get work done.
Saturday morning, we laid out the business problem, context, and goals for the weekend, then I announced we would do 90 minute sprints. The business teams (we had marketing, UI, and product teams as well), would adhere to the same schedule. The beginning of the first sprint for dev was spent laying out four areas of technical problems and having the team self select into what tickled their fancy. Everyone then got to work. I moved between the teams to discuss possible technologies for them to consider and dive deeper on the problems they needed to solve. The volunteers then took over and by the end of the first sprint everyone had a handle on their problem areas. Most even had a initial plan of attack.
Everyone has heard of Forming, Storming, Norming, and Performing. With 2 days to get work done, we had to get them to performing as quickly as possible. The dev teams were all about 3 people in size with differing skill levels and familiarity with the technology stack we were using. The 90 minute sprints forced a tempo which required the teams to get to performing quickly – no one wants to report out nothing was accomplished. Yes, some of the progress initially was small, but these were hard problems to tackle in a weekend. I had one team who’s requirements were being developed by the business team through the weekend, some sprints the deliverable was “received requirements from business and developed a response.”
By the end of Saturday, all of the development teams had produced something which was merged into mainline for the other teams to pick up. That was huge and everyone could see the bar moving.
Sunday started with a review and then everyone picked up where they had left off. The development teams reformed and started working before we even had the morning review. The pace on Sunday kept accelerating, merges occurring after every sprint, until late afternoon, when we started winding down.
I have run many volunteer projects. The SnapImpact team had actually completed one earlier in the week involving several hundred people with BDNT, and it’s absolutely critical volunteers feel like they are moving the bar. Given the scope of this project, it was going to be very easy to have volunteers lose sight of the progress they are making and give up. The 90 minute chunks with progress review and planning helped ensure the volunteers didn’t lose sight of the progress we were making that weekend. As project owners, we had goals of our own on what was going to be delivered at the end of the project. The sprints allowed us to keep moving in the direction we needed to go as well as identify trouble areas.
Ryan – What did not work so well or would do different next time?
Dave – Training – One decision I made was to use a relatively new technology stack, Scala/Lift, for the framework. Instead of holding a formal training session for those unfamiliar with it, I made sure there were experienced people in each group and let training happen “on the job.” I think next time it would be better to do a short training session, as given the pace, sometimes that training disrupted forward progress. Just the basics, so when a concept was discussed it wouldn’t be completely foreign.
Deliverables – We got sloppy during the reviews and didn’t nail down specific deliverables for teams. At times, it caused teams to lose focus during the sprint. The reviews were every 90 minutes, so the lack of focus was caught sooner rather than later.
Insert more fun – Because the tempo was so high, I’m not sure folks had as much fun as they could have during the event. I’m a big believer in fun being central to any successful project and I think teams could have bonded a little more and we may not have been as exhausted by Sunday afternoon. There was some fun, we just needed more.
Ryan – Tell me about the emergent end deliverable? Can people see it on the web?
Dave – Our goal was a beta of existing functionality by the end of the weekend. We’re very close to that now, but some decisions made during the weekend prevented accomplishing that goal. The SnapImpact team is continuing development and once the existing functionality is in place we’ll start working on a host of new feature requests from the business team. We’re entering all of that information into Rally now and beginning the planning process. Folks will see v2.0 at http://allforgood.org in June.
Ryan – What did you do to prepare or plan for this process?
Dave - Preparation started weeks in advance. My role in this project is CTO and VP of Engineering. So, the 3 critical things I needed to accomplish before the weekend started was making sure I stacked the deck in my favor with some talented people, had a toolbox ready with possible solutions to the technical challenges we would face, and had stakeholders present to make decisions.
Given the new technology stack, I needed to recruit folks with some very specific skills. To enable that effort we recruited the leader and founder of the Lift project, David Pollak. He helped us motivate a few people with experience using the technology. We also had the SnapImpact team actively recruit their friends. The result was a very high quality team capable of getting the job done.
When the teams started work, they would spend too much time investigating everything unless I gave them a starting point. By bringing some ideas (not solutions) to the table to solve their problems, it helped define their playing field and allow them to make a decision quickly. Implicit in this was understanding the known business problems that needed to be solved.
We knew we would hit roadblocks during development waiting for business input on implementation details. So, we made sure to have some present the entire weekend. One of the stakeholders even brought a developer who was using the existing system. We embedded the dev in one of our teams working on implementing some external interfaces. Yes, that really accelerated the implementation decisions. Also, the stakeholders were really disappointed with certain aspects of the existing system. We had ideas to resolve those issues, but needed to ensure they met the stakeholders needs.
Thanks Dave for the great details on this event and example of agility at work!
Last summer, Rally started a video series called “Chalk Talks“.
I was fortunate enough to have filmed several“Chalk Talk” videos about some of the basics of Agile software development (The Agile Manifesto, Scrum Basics, Iteration Demo and Review Meeting, and other topics).
We also tapped into the wisdom of some of our other Agile Coaches: Julie Chickering, Mark Kilby, and Ken Clyne.
Our Rally Chalk Talks are informal videos, typically 3 – 5 minutes long, intended to provide quick, easy introductions to Agile topics.
Filmed in a short, tutorial format, these videos are great to share with your team as they are getting up to speed on Agile.
To get a feel for our latest work, here’s Rally Agile Coach Ronica Roth in her great Chalk Talk on User Stories. ( during which you can find out why a dog would want his own laptop :D)
Be sure to check out our entire catalog of Chalk Talks and subscribe to our YouTube channel if you’d like to be notified when we publish new videos. We already have two more Chalk Talks queued up: “Kanban and Scrum” and “Agile and Lean”.
As you look through our current catalog of talks, be sure to let us know what other topics you’d like us to cover in future talks.
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’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.
Clippy - the ultimate bearer of redundant information
Remember this guy? He used to pop-up when you least expected him and offered up information about something you already knew.
I’m sometimes reminded of Clippy when I hear the rhetoric from some in our Agile community.
We’re at an inflection point right now. The pragmatists and the conservatives are realizing the fallacy of large upfront planning.
As teams from these later adopters are striving to become leaner and more Agile, they struggle with the inertia that is inherent in large organizations.
They know that co-located teams are more successful but they prefer an environment that extends the benefits of working from home.
They know that it is much more efficient to work on one task at a time but someone way above their pay grade won’t let them have such a single minded focus. This is not a battle they can win right now.
They know that value can be delivered faster if testing can be pulled forward yet they don’t have budget to buy the tools they need.
For such decisions Clippy always knows the right answers for everybody. But Clippy doesn’t have to walk in their shoes and it won’t be Clippy who gets fired for taking a risk.
“Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.”
“I think we need to acknowledge that there are parts of organizations that will be less agile than others while moving from traditional to agile projects. That the big ole ship can’t turn on a dime. To me this is part of being a trusted partner.”
As you strive to become leaner and more agile, you don’t need Paper Clip Consulting, you need a trusted partner. You need someone that will begin with the end in mind yet not seek to get there immediately. A trusted partner will take the time to understand your environment, accept that there are always constraints and help you establish a cadence of continuous improvement.
About the Author: Ken Clyneis a kayaker, Certified ScrumMaster and Agile Coach at Rally Software Development. Subscribe today to get free updates by emailor RSS.
Remember this guy. He used to pop-up when you least expected him and offered up information about something you already knew.
I’m sometimes reminded of Clippy when I hear the rhetoric from some in our agile community.
We’re at an inflection point right now. The pragmatists and the conservatives are realizing the fallacy of large upfront planning.
As teams from these later adopters are striving to become leaner and more agile they struggle with the inertia that is inherent in large organizations.
They know that co-located teams are more successful but they prefer an environment that extends the benefits of working from home.
They know that it is much more efficient to work on one task at a time but someone way above their pay grade won’t let them have such a single minded focus. This is not a battle they can win right now.
They know that value can be delivered faster if testing can be pulled forward yet they don’t have budget to buy the tools they need. They understand very well the return on investment and to Clippy it’s a no-brainer but Clippy doesn’t have to walk in their shoes. Maybe Clippy needs to talk to the CFO.
Maybe Clippy needs to listen to Norm Kerth (from his book Project Retrospectives)
“Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.”
or as my colleague Julie Chickering says:
“I think we need to acknowledge that there are parts of organizations that will be less agile than others while moving from traditional to agile projects. That the big ole ship cant turn on a dime. To me this is part of being the trusted partner.”
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 Atlasis a Soul Musician, Certified Scrum Trainer, and Agile Coach 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’sDance of Change and Michael Hammer’sReengineering 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.
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 Atlasis a Musician, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.
RallyDev.com
I’m offering this follow-up post as a means to provide an overall response to all these great comments. I want to add some further background on the “escalation” topic and some more of my personal conviction around it. Specifically, I’d like to provide some insights into delayed feedback, the need for conflict, and how to “show up”, all without escalation.
Your company is insane and you might be insane, too.
