Agile Development Blog

In the last month, I have gotten the question “Where does Agile *not* work?” numerous times, mainly from large firms planning their first Agile rollout efforts.  That question is quickly followed by, “And I don’t want to hear that it works everywhere!”

Admittedly, that’s a tough one for me. My answer is that Agile approaches can be applied anywhere – from your home moving project to the creation of space crafts. So I usually flip the question. If Agile conceivably could work anywhere, the question is really, “On which projects do you choose to start your Agile adoption?”

Where To Start

Jean and I and our fellow Rally coach Ronica Roth tend to apply two criteria: the strategic importance and risk of the effort. The iterative nature of Agile development is going to provide you with the tools to steer a risky and highly strategic project much better than phased development approach.

Our rendition from "Stand Back and Deliver"

In their new book Stand Back and Deliver, Pollyanna Pixton, Niel Nickolaisen, Todd Little and Kent McDonald provide a more elaborate portfolio model to assess your efforts.  They map uncertainty versus complexity in a 2×2 matrix with nice labels of colts, bulls, sheepdogs and cows. I find the model is very effectively elaborated in the book and some very useful implications for staffing, selecting and managing the value flow are discussed.  The variables used in the book include:

• Uncertainty Attributes: Market, technology, customer size, project duration, scope of change
• Complexity Attributes: Team size, mission critical, team locations, team maturity, domain gaps, dependencies

Three Perspectives

1. We agree with the authors, the best place to start using Agile practices are projects that are High Uncertainty (because you leverage Agile to learn as you go) and Low Complexity (to avoid the headaches of technical risk).
2. If the risk to the business is significant, such as eroding market share or the possibility the project will be canceled, then accept the technical risk and use Agile for a High Uncertainty-High Complexity project.  The use of Agile will help with the uncertainty. It will be important on those projects to increase the discipline level around process and communication.
3. Projects of Low Uncertainty and Low Complexity rank third.  They could easily transition to Agile and benefit from the improvements to productivity, quality, and collaboration. Yet they don’t need Agile to be successful. For these projects, the tie-breaker may be the next set of criteria – the environment.

Environmental Factors

Once the project is right for Agile by its nature, the next question is whether you can quickly create an environment for success.  Many people talk about this as the organizational readiness for Agile or assess these concepts via Agile team assessments.  Here is a snippet of that kind of team assessment:

Does the Product Owner have the right level of authority and influence? Are they…

• Embedded with team?
• Dedicated to the project?
• Able to gain consensus from stakeholders on goals and features?
• Able to evolve the product backlog (with training)?
• Able to support the team through constant feedback and decision-making?
• Able to plan at multiple levels (with training)?

Is there a dedicated, persistent, cross-functional team?

• The team is dedicated to the work being planned using Agile (note: The team could actually work on multiple projects, as long as they are working a single backlog and work from all projects is scheduled via Agile planning cycles).
• ScrumMaster, Product Owner, Product Development and Quality Assurance must be full-time dedicated resources.
• Other resources might be part-time for any one Scrum team, but they should be spread across as few Scrum teams as possible. These include: Database, User Education, Apps Architect and Ops Architect.
• Architects might be contributing members, or might be advisory.

Is the team co-located?

• It’s not required, but can be a risk factor.
• For distributed teams, it is important to have good communication constructs, and to have a leader in remote locations to partner with the ScrumMaster and Product Owner of the core team.

Do you have an Uber Product Owner and Uber ScrumMaster?

• For multi-Scrum-team projects, it is important to have an overall Product Owner and ScrumMaster to own releases and communication across teams.

Is there a controlled build environment?

• To ensure quality and a smooth flow of work, the team should be able to provide QA with builds multiple times during a two-week sprint.
• As a Scrum team matures, and to increase velocity, the team will want to integrate code to a shared dev environment continuously (at least daily).

You can get a copy of Rally’s Team Agility Assessment and we welcome your feedback. I hope you will buy their book and try team assessments to help you map your own approach.  To me, Agile works everywhere,  it is just a question of how good do you want to be and by when.

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.