Agile Development Blog

In the first part of this two-part series, I talked about deploying Scrum to parts of the larger organization without starting in development (“Can you deploy Scrum to a test team?”).  This article looks at another kind of “ScrumBut” – the most commonly meant kind:  deploying only parts of Scrum to an organization.

Is it half-assed to skip practices in adopting Scrum in your organization?

Lots of sources appear to say that it is.

Ken Schwaber gives a short presentation on ScrumBut in this video (you may have to click the “Download Optimized” button to play this).  I’d paraphrase his position as saying that the Scrum practices fit together to create more value than they do individually. So if we punt on one or more of them, he sees potential value being left on the table, and potential organizational weaknesses becoming more entrenched.  He sees Scrum as best adopted as a whole without deviation.  Consider this excerpt from his book “The Enterprise and Scrum,” about the medium-term issues in Scrum adoption:

“… many people in your enterprise are probably advising you to change Scrum because it needs some tweaking to be compatible with your enterprise.  My advice is this: Don’t Do It.”

Later in the same book, he suggests developing an organizational audit function to independently assess the degree of success in adopting Scrum:

“… the ScrumMaster and the team often get so embroiled in their work that they lose perspective on themselves.  For this purpose, having an audit capability is useful.  Someone who knows Scrum and is from outside the team needs to have a way to measure how well the team is using Scrum.”

That can be viewed as an organizational-wide commitment to avoiding ScrumBut.

This article from Mitch Lacey, “Practicing ScrumBut: Ensuring Project Failure,” captures a workshop delivered at SQE Agile Development Practices 2009.  I think the title here says it all in terms of the expected value of ScrumBut.

This article from Michele Sliger covers a particular pattern of ScrumBut that’s near and dear to my heart, failing to meet sprint commitments.   The thing I liked most in this article was the notion of “we suck less” Scrum adoptions.  Michele is encouraging us to strive for more than “we suck less” – in large measure, saying to at least aim to suck less.

Process change in large, traditionally structured organizations is hard

These authors are stressing the value of Scrum in its entirety, which is difficult to argue with.  The question for me is: “What if doing vanilla Scrum is too hard right now?”  As I noted in the first article, a big chunk of my career has been spent in larger organizations with very strong functional silos and long histories of plan-driven, waterfall lifecycles.  If you look at what you’re really asking an organization like that to do when you ask them to try Scrum, it’s clearly pretty easy for them to say “no.”

Even on pilot projects, this may be too much to ask for from them – especially so if they’re doing reasonably well with their current processes.

Certainly the value of the practices of Scrum together is greater than their sum individually but does that mean that the value of the practices goes to zero if we don’t deploy them all together?  Can the adoption of Scrum be something that is tackled incrementally with an eye towards creating value with each incremental change?  If that last question sounds a lot like how Scrum advises us to approach the creation of value on our projects, that’s no mistake.  Sometimes, and particularly so in the kinds of large, slow-to-change organizations I’m referring to above, I think it’s sensible to ask Scrum itself to deliver its value incrementally.  In scenarios like these, I think it’s important to keep in the forefront of our minds Mike Cohn’s advice in “Succeeding with Agile” about the difficulty associated with viewing Scrum adoption as a traditional change initiative:

“… unlike other change initiatives, with Scrum there is no end state.  There is no point when you’re done.  Instead, Scrum requires continuous improvement …”

The key thing here from the perspective of assessing the value of a ScrumBut adoption is that it should not at all be viewed as any kind of finish line, but rather a potentially useful step along the path of organizational improvement.  If we’re on a path of continuous improvement, do we have to start with a big bang introduction of all of the Scrum practices?

Schedule pressure, estimation and the “Release Train” – a real-life example

I once had a client whose group followed what they called “the Release Train.”  In it, they prioritized higher-level features and other work items in a big list and then worked on a few at a time in priority order.  They did not use fixed time boxes for this work but rather used a Definition of Done to help them decide when a given work item was complete and another could be started.  In sum, a process that resembled a kanban system perhaps more so than it did Scrum.  The problem he brought to me was this:  stakeholders wanted estimated dates of completion for the items on the release train. He worked with his team to come up with these dates, but they knew that the overall project goals were heavily influencing their estimates.  For example, if a project was intended to hit a market window six months out and was to be defined by a handful of key features, the team felt considerable pressure to estimate dates for those features that met the release timelines.  We discussed the possibility of trying story points – instead of asking the team to forecast the completion date of each item, ask them to estimate each item’s size using story points and then measure the team’s progress in completing the work (in terms of story points delivered per unit time) to derive estimates of completion for future items on the release train.  We agreed that would be an interesting approach to solving the problem they were most concerned with.  Now in fairness, we had a pretty wide-ranging discussion over the course of which he talked about other problems they had – among them difficulties in establishing priorities, nailing down what the release train items actually meant, and getting inputs his team needed from other groups in a timely manner.  He expressed interest in adopting Scrum “somewhere down the line” but was unwavering in his desire to fix this one problem – improving his team’s ability to estimate release train item completion – as soon as possible.

As a Certified Scrum Coach (CSC), I suppose you could make a case that I should have pushed him harder in the Scrum direction.  In private conversations with other CSCs and Certified Scrum Trainers, my approach has been questioned as perhaps overly complacent.  In all honesty, I’m not sure.  As a coach do I strive to challenge my customers – to push them to want more than they come to me wanting. Or, do I try to solve the problems they actually ask me to solve?  For better or worse, I tend to do the latter.  I can say that it doesn’t feel complacent per se, but rather doggedly determined to make progress that provides value to my customer as quickly as possible.  In the example above, just improving their estimation practices would go a long way to improving their lot.  Why not help them do just that?

A view from the perspective of another process improvement approach – the CMMI

Much of this discussion puts me in mind of the CMMI and the difference between maturity levels and capability levels.

The CMMI defines a staged approach to organizational process improvement – very comprehensive about the order in which different aspects of the overall processes (“process areas”) has to be done.  For example, achieving maturity level two implies improvements in the following process areas:  requirements management, project planning, project monitoring and control, measurement and analysis, configuration management and process and product quality assurance (also supplier agreement management, if that makes sense in the organization).  The remaining maturity levels, three through five, are defined in a similar manner.  That prescription of a process improvement path frankly seems like the kind of approach calling for all of Scrum to be deployed in one go.

But the CMMI defines another approach (technically another representation) – the continuous representation, which leaves the ordering of improvement to process areas to the organization to decide, while still offering some guidance on how to go about it (the specific and generic goals and practices).  That guidance is supported by the notion of the capability levels, which define a path for improvement for the individual process areas.  In the continuous representation, an organization would be free, for example, to focus first on improving how they approach project planning practices – estimation perhaps – if they believed that was going to offer them the greatest value.

Suddenly, insisting on deploying all of Scrum right away starts to feel perhaps a bit too prescriptive.

So is it half-assed to deploy part of Scrum to your organization?

Scrum is one useful assemblage of Agile practices. XP is another.  There are others.  So it’s not unreasonable to think an organization could skillfully define their own set of Agile practices or an incremental path through adoption of the complete set of Scrum practices that would provide decent value, tailored to their organization’s needs over time.  At the end of the day, if you held a gun to my head and made me winnow down Scrum to the absolute minimum I’d really not be willing to part with in any initial adoption, it would amount to just these two practices:

• Iterate:  define a window of time in which the team commits to delivering some potentially shippable increment of working software
• Reflect:  gather the team together at the end of each iteration just prior to planning the next iteration and ask them how they can improve

Mind you, if you do just those two for a while, you’re likely to end up inventing many of the other common Agile practices :)

But if you started even at that modest point, would you be pursuing a half-assed deployment of Scrum?  Maybe so.  But maybe a half-assed deployment of Scrum is like “half an eye” that provides value all by itself but also represents a step along the path to something amazing.

So can you deploy part of Scrum to an organization?

Sure, why not?

What do you think?

I’d like to thank Selaine Henriksen for her help in developing this post.

About the Author: Ed Willis has been a ScrumMaster, Product Owner, Scrum coach and trainer.  He is currently a developer in the telecommunications industry.

This post will be split into two parts so that it, itself, will be half-assed with the suggestion of an additional half-ass to be delivered later :) And, in keeping with that spirit, the post mistakenly went live before it was ready for prime time. This time, I meant to push the ‘publish’ button…

Can you deploy Scrum to a test team?

Scrum is at its heart a product development process.  How can you leave the part of the organization – development – that actually makes product out of any Scrum deployment? Does it even make sense for other parts of the organization to be “doing Scrum” if development is somehow doing something else? Wouldn’t you be working towards what would be, at best, a half-assed deployment of Scrum?

Craig Larman and Bas Vodde in their wonderful book Practices for Scaling Lean & Agile Development certainly agree: “…a so-called test team Scrum is a contradiction in terms.” Ken Schwaber in The Enterprise and Scrum doesn’t seem to admit the possibility of deploying to functional groups – it’s projects he’s envisioning deploying to. For example, consider this advice for early goers of an enterprise-wide adoption of Scrum: “Establish preconditions that must be met before a project can use Scrum.”

The last 10 or so years of my career have been spent in big companies with very traditional structures: functional organizations with clear separation between development, test, usability, product management, etc; running projects that are very much plan-driven. Lots of agile practices that seem relatively straight-forward in other contexts aren’t in companies like this. Consider Schwaber’s notion of organizational deployment of Scrum again – this from the introduction of The Enterprise and Scrum: “This book is for those who want to use Scrum throughout their enterprise for product development.” It’s an awfully lucky convergence of thought and opportunity that would make such a deployment possible in large, traditionally organized companies. These sets of wholly distinct sub-organizations need to be both willing and able at essentially the same time. You might get a chance like that, but I wouldn’t hold your breath waiting for it.

You can start to see why that opportunity would be rare when you look at it from their perspective.  In taking a project-by-project focus in deploying Scrum to organizations like these – and assuming you’re holding firm to deploying every part of Scrum straight away – you’re essentially asking them to:

• Reconfigure their teams
• Change how they define and manage product scope
• Empower a single person to make scope decisions on each project
• Change how they plan their work
• Change how they approach their work in areas like development and testing
• And so on …

The point is that, even if limited to the context of a small set of pilot projects, they have to do all of this stuff first before they can realize the benefits of Scrum.

To me, this is exactly the same argument that we, as agilists, are very much accustomed to facing from development teams:  “We can do that feature but first we need to re-engineer the infrastructure to support it, which will take six months.”  We encourage teams making that argument to find ways to do just a bit of the refactoring to allow just a bit of the value to become realizable, rather than predicating all of the value on all of the refactoring.  Why can’t we make a similar argument in support of deploying Scrum to just a part of the organization?

What would Voltaire say?

One of my favorite lines – frequently quoted in optimization discussions but applicable equally well here – comes from Voltaire:  “Le mieux est l’ennemi du bien” (the best is the enemy of the good). “Best” is hard to define in any complex system like a large company but “good” seems a little more tractable. We should not let an inability to approach some notion of perfection prevent us from getting better.

A colleague was presented with this exact scenario a while back.  Representatives from a test group came to him asking if he would work with them to try Scrum.  He and I spent some time talking it over.

Things like product owner, product backlog and potentially shippable product increment looked like a tough fit for a test team, to be sure. But still, we thought of goals like “verify feature X” where the challenge to the team is to find a way to work together to get that done within the time-box of the Sprint. That might be a liberating shift in thinking after heavy doses of planning of the form: “We have a bazillion manual tests to execute. At 5 per hour, that’s bazillion/5 staff hours. With 20 FTE, that’s a bazillion/(20*5*40) weeks of testing.” Looking ahead to subsequent Sprints, we envisioned helping the test team bring some of their development partners into their Scrums – perhaps through broadening the notion of the verification goals to include “hardening” – finding and fixing bugs as a cross-functional team. And from there to the odd small feature, slowly working our way towards aligning the work of the test and development organizations in cross-functional Scrums. Even with such an odd scope of initial deployment, we could see potential benefits, including improved productivity through the iterate and reflect cycle, better planning and estimation and higher morale.  Not surprising, these are the same benefits we would suggest lay before any team looking to try Scrum.

Isn’t this the good that Voltaire would caution us against passing on?

Larman and Vodde have some great advice about how to go about ever more closely approaching the “potentially shippable product increment” goal of the Sprint through expanding the Definition of Done (DoD below):

“In general, these are the ways of expanding the DoD:

• Automate – for example, performance testing is automated
• Expand team cross-functionality – for example, a person with technical-writing skills joins the team”

That latter idea suggests a path to improvement that starts in development and then spreads over time to the remaining functions.  If we view Scrum deployment as being something we do in the context of projects and products, this is both natural and reasonable.  But, if we view deploying Scrum as something we do in the context of teams of people or if we view it simply as “transforming the world of work,” then why would we believe we have to start with any particular set of people?  Why not start with testing and grow our way towards development?

Would that be a half-assed approach to deploying Scrum?  Perhaps, but like Richard Dawkins’ half a wing or half an eye, maybe half an ass may prove a more useful incremental improvement than may be apparent at first glance.

So, can you deploy Scrum to a test team?

Sure, why not?

What do you think?

About the Author: Ed Willis has been a ScrumMaster, Product Owner, Scrum coach and trainer.  He is currently a developer in the telecommunications industry.

This week both Jean and I delivered talks on the Agile organization at Agile 2010 in Orlando. Whether you were able to attend one, both or neither, this post shares the handouts and materials that we used in the talks.

If you attended, please provide comments on what you liked, were puzzled by and might change in the future.

Jean’s work was a three-hour tutorial on learning models for managing the Agile organization.   She ran three exercises and provided a bibliography of books/resources that we have used here at Rally:

Jean in action at Agile 2010

• True North Example

• True North Exercise

• Strategy A3 Template

• ORID Exercise

• Personal and Corporate Visioning Exercise

• Sample Quarterly Agenda

• Bibliography

In addition to Jean’s talk, I presented an experience report on our use of Plan-Do-Check-Act (PDCA) at Rally.  This report tells a story of our evolution of strategy execution from Gazelles/Scrum to Lean/Agile.

We hope these resources provide you with ideas for scaling your own Agile efforts beyond their current levels.  Again, please comment on the blog with what you got from the materials or the talks.  We want to hear from you on this topic.

Ryan Martens is a tomato grower, founding board member of the Entrepreneurs Foundation of Colorado, and CTO at Rally Software Development.

Scott Killen is an Agile Practice Leader at PayPal and the President of Agile Austin. He has extensive experience managing all aspects of the software development process, from a twinkle-in-the-eye to final release. In advance of his participation as a panelist at our upcoming Dallas Agile Success Tour, we sat down with Scott to chat about Agile.

1. How have you implemented Agile across your organization?

We have a three-year vision for PayPal to implement Agile development across our enterprise. In year one, we are focusing on basic practices. The idea is to lay a solid foundation for building mature teams. In year two, we’ll focus on making teams successful. That is, using the practices in a reinforcing way to build teams that predictably deliver acceptable products. In year three, we want to focus on optimization. That is, aggressively practicing incremental and continuous improvement of our Agile practices.

To baseline practices and measure improvement in year one, we have a metric that we call “Team Maturity.” This is a weighted score that reflects the number of fundamental practices a team employs and their longevity in terms of iterations completed.

We are in the process of defining the metrics we wish to use to define a successful team. It is important to us that these metrics be methodology neutral. Although not formalized, I expect that some measure of time-to-market and released-defect counts will be used.

2. What was your #1 reason for adopting Agile development?

We want more flexibility in our development process.  We seek flexibility to make late-cycle changes to develop the best product and to decrease time-to-market for those products.

3. What has been the biggest benefit of adopting Agile?

We’re looking forward to receiving the big payoffs. But, surveys generally indicate that we are more effective when we develop in Agile projects, our quality is higher, and our developers are happier.  Cross-functional communication is cited as the big win in these surveys.

4. What one piece of advice would you give to new Agile teams?

Be sure to properly set management expectations. You will not get productivity or quality gains at first, and, in fact, your productivity will decline for about six iterations until everyone begins to learn how to work collaboratively within the Agile framework. Agile development does not come without pain. I’m reminded of the expression “Pain is weakness leaving the body.”  That’s Agile – painful, but the results are worth it.

5. How do you define Agile success? Can you do it in 113 characters?

Happier customers measured by Net Promoter scores. Happier developers measured by lower turnover.

Follow this thread on Twitter - We asked Scott to define Agile success in 113 characters or less as part of a challenge we’re hosting on Twitter. What is your definition of Agile success in 113 characters or less? Tweet your answer to @RallySoftware using #AgileSuccess. The top five tweets received by May 17th will be featured in a follow-up blog post.

Yesterday Forrester Research, Inc. issued the most comprehensive, independent analysis of the Agile development tools market and 10 Agile ALM providers.

The Forrester Wave: Agile Development Management Tools, Q2 2010

Here are some highlights but what I really recommend is that you read the report titled “The Forrester Wave™: Agile Development Management Tools, Q2, 2010, Forrester Research, Inc., May, 2010″ 

• The report says, “Rally offers the best combination of capability and strategy.”
• It goes on to say Rally “has a strong services group with lots of experience around enterprise Agile adoption, benchmarking and assessment.”
• Thanks to Forrester’s deep analysis, there is a lot of other great information on Agile adoption (currently at 35%) and where this market is headed.

See the full report for details.

For me, this is a culmination of 6 years of hard work building a great product, roughly 32 product releases (that’s just on our core ALM product),  countless demos to our now 96,000 users to get the features right, and the company evolving from just me to 165 phenomenal team members at Rally. Wow, I am a proud Rally-er today.

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.

I’m traveling this week to Rally’s Agile Success Tour in San Diego.  I love attending these events because they’re a lot of fun and participants seem to get a lot of value – getting out of the office for a half day is a great way to learn and think about how you can get started or get better with Agile.  Plus, the Rancho Bernardo Inn is pretty nice place to spend a day.

The site of Rally's Agile Success Tour - the Rancho Bernardo Inn

But my day job is as a Product Owner, so I’m still trying to keep up with my team while on the road.  And this trip has been a good reminder of the challenges of working remotely.  Here are seven things I’ve remembered that make a big difference if your team has remote members:

1. Actually log in to your chat client. 
Instant messaging is a great way to quickly make contact with people on your team, but if everyone isn’t actually logged in to chat, you often can’t reach the best person.  If I want to talk to Fred, but I can’t reach him, I’ve got to make a decision – do I wait, or do I interrupt Jason, a developer on his team?

2. Dial in the bridge. 
If you’re having a meeting, and you have remote team members, make connecting to the conference bridge a habit, even if you don’t think anyone remote is going to be attending.  Plans change; something comes up such that someone who was going to be in the office is out.  If you don’t connect the conference bridge, remote employees will either give up, or frantically try to catch local participants on IM in the hopes that someone brought a laptop to the meeting.

3. Check in and out on the phone. 
Assign someone in your meeting to remember the remote team members during the discussion.   And make sure you check in with the people on the phone before you hang up at the end of the call.  (Give them a few seconds to unmute before you assume they’re gone!)

4. List your cell numbers.
At Rally, we have a Google spreadsheet that lists office and cell numbers for everyone.  I’m rarely at my desk during the workday, so cell is the only reliable way to reach me.

5. Skype your standups.  
In our team room, a couple of the machines have Skype running.  When you’re remote, video goes a long way to improving connection with the team.  Showing some video of the absurd furnishings or the view outside the hotel room makes it fun.  This morning, I had some bandwidth issues and could only use voice – it didn’t work nearly as well.  Also, with a team like mine, a remote employee who doesn’t enable video for an early morning Skype session will invariably be subject to baseless accusations of not wearing pants.

6. Leave Skype running for a few minutes after the standup is over. 
Often interesting conversations pop up in the 30 minutes following this meeting.  As a PO, I often overhear useful bits of information at this time, and it makes it easy for people to ask me questions they might have forgotten during the standup.

7. Update your stories. 
This morning, when I logged into Rally, it looked like a ton of work was in progress.  Turns out, my team just hadn’t updated their tasks and stories.  Often Rally is the window your remote team members have into what’s going on.  If you don’t update stories, you can end up with unnecessary confusion.  Fortunately, we cleared it up in our daily standup meeting.

These were the things I remembered this week.  So what tips do you have for making life easier on remote team members?

Once upon a time, Frederick Winslow Taylor and W. Edwards Deming lined up across a ping-pong table and went at it.

“There is only one correct way to do any job!” said Taylor, smashing one of those real curvy, tricky serves at Deming.

“Let people contribute in the best way that they can envision,” retorted Deming as he calmly returned the serve from 8 feet behind the table.

“Employees are evil and lazy!” screamed Taylor as he sliced a murderous shot high into the air, the backspin causing a local singularity in the spacetime continuum.

“The success of the company is good for all, and people want to succeed,” offered Deming, backhanding a low shot with sideways spin just over the net.

“Managers are the ones that know the answers!” shouted Taylor, cutting his forehand all the way across the table.

“Hmmmmm,” said Deming, who could be a very thoughtful guy given the right circumstances, “the people closest to the problem are more likely to come up with a correct answer.”

“Supervision!”

“Empowerment.”

“Punishment!”

“Trust.”

And on and on. They never did finish the game.

Here’s the interesting thing: we’re still playing this ping-pong game.

Here’s another interesting thing: many people don’t seem to know it.

Many people make the mistake of viewing Scrum and Agile and Lean as sets of practices. “If I do kanban, I’m Lean.” “If I do sprints, I’m scrummy.” “If I do BDUF and most of my projects are late, then I’m waterfall.” (Oops, well, the last one is actually true, but the first two aren’t.)

The thing is, you’re not Lean unless your company commits to the two pillars of Lean: continuous improvement and developing people. You’re not Agile unless you create and foster self-organizing teams. You might be doing a lot of Agile practices, and you might even get better results than you used to, but you won’t be Agile. If you accept this limitation and you are doing Scrum, then you will be doing ScrumBut.

So I smile to myself (I think it’s to myself) when I hear management say things like “We’ll never be totally Agile in this company. There will always be waterfall projects.” I smile because what that really means is that they’ll never be Agile at all. Lean and Agile fit into the framework of Deming’s System of Profound Knowledge. Plan-driven, hierarchical command & control methods descend from Taylor. You can’t follow both at the same time.

Really? Yes. Would those managers supervise and micromanage some employees while supporting and developing others? Would they dictate commitments and solutions to some while allowing others to determine their own fate? Would they trust the people on the Agile projects and punish the ones on the waterfall projects? Would they hold individuals accountable on waterfall projects while holding teams accountable on Agile projects?

Of course not.

What they will do is treat everybody the way they always have. They will beam with pride when teams gather in their little circles every day, and then they will dictate to them that the manager is actually still responsible for delivery and ask for lists of who will be assigned to which task in the next sprint. They will refuse to make priority decisions and instead direct people to work on multiple projects at a time, and they might even decide just how many design documents each team should have. They will do this because that’s how un-Agile projects do it and for some reason this makes management require it of all teams. (What has always seemed odd to me is that they won’t demand that waterfall teams release an increment of working software each month because the Agile teams do it. So I guess it only works one way.)

And they’ll wonder why this Agile thing gets so much hype, since it really doesn’t seem all that different from what they’ve always done. And really, the results aren’t that great.

You can’t be both Agile and not Agile. You can’t be both Lean and fat…er…not Lean. Not at the same time.

If your company is not fully committed to agility then you won’t achieve it, and your results will be a self-fulfilling prophecy of unrealized potential.

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.

I have been back in the Fifth Discipline Fieldbook this week thinking about strategies for creating a shared vision to 2020 at Rally.

With our newest round of funding, we will be growing rapidly in multiple locations and beyond the max tribe size of 150-170 people. (Dunbar’s Number)  Over that last year, we grew the business well but without advancing our total headcount numbers.  Now with headcount growth slated in the field and in two development centers, we need a stronger foundation to steer our growth.  Doing this work, hit me with a BFO (Brilliant Flash of the Obvious) that is impacting many of largest Agile adoptions that I am working with.

Many leaders are seeing the benefits of Agile and “Telling” or “Selling” their organizations to go there.  But, the “Telling” and “Selling” strategies run counter to many of the guiding ideas behind Agile itself.  I have seen this rub  limit or slow the positive impact of an Agile adoption.  This rub almost guarantees you will only get incremental benefits from Agile and will most likely fall back to your old ways.

As Bryan Smith and Peter Senge remind us “Telling” is just the first developmental step in creating a shared vision to adopt.   This strategy has many flaws including that fact that most people only remember 25% of what they are told.  However, it might be the right strategy given a dire current reality.

In extreme contrast to Telling, is the Co-Creating strategy that has the whole organization working together to create the vision and implement it.  This requires a leadership group that can truly let go and an employee base that has enough personal mastery to understand their own personal vision.   Those are big pre-requisites to this strategy, but it should be obvious that if you can run this strategy, the self-motivating benefits will be highly supportive to getting the most benefit out of Agile.

The complete model, from the Shared Vision section of the Fieldbook includes five strategies that can be grown into over time:

1. Telling
2. Selling
3. Testing
4. Consulting
5. Co-Creating

We have discussed our Flow-Pull-Innovate approach for adopting Agile in larger organizations, but I have talked very little about strategies for leading this adoption process.  I think it is because most Agile adoptions get started in a grassroots approach and are led by the teams that testing it out.  The success of these teams then caused people to take notice and start talking about how to replicate this success.  In essence, I have been assuming, and the market has been executing a Testing level strategy.

I believe to put an organization on the path to continuous improvement, you must at least be executing a Testing level strategy to scale your adoption.  Over time, I believe your ultimate ability to move to the Innovate level of Flow-Pull-Innovate will be tied to your ability to adopt a Consulting or Co-Creating strategies.  As Agile is a journey to greatness, this journey depends upon your organization maturing in all including strategy execution.

What are your experiences with these strategies in your Agile adoption?

At Rally in 2010, our planning team is running a two pronged approach using a Testing strategy with the organization in Q1 for our 2010 plans and a three quarter long co-creating strategy for our 2020 vision.

About the Author: Ryan Martens is a lego building 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.

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.