Agile Development Blog

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.

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.