7 Pitfalls to Avoid When Adopting Agile

Are you thinking about adopting an Agile approach? Or are you currently using Agile on your projects? Where ever you are on your Agile journey, it is important to know the seven pitfalls organizations make when adopting agile approaches.  This post, along with our post on Introducing Agile-Chance Resistance Strategies give you helpful information about adopting agile approaches.  We will also introduce the five Ws (Why, Who, What, When, and Where) of introducing agile.

7 Adopting Agile Pitfalls to Avoid

1. Adopting Agile Without a Clearly Understood, Agreed to and Articulated Need
2. Not Engaging All the Necessary Stakeholders
3. Not Considering the Full Scope of Changes Required
4. Not Considering the Social Factor Change Impacts of the Change
5. Assuming it is Always Best to Use an Agile Approach
6. Choosing an Inappropriately Sized Project When Adopting Agile
7. Calling the Initial Project a “Pilot” Project

#1: Adopting Agile Without a Clearly Understood, Agreed to and Articulated Need

Most organizations have plenty of room for improvement in their software development process. The Standish Group’s CHAOS Reports repeatedly give low figures for project success rates and metrics:

16% of projects are completed on time and on budget
31% of projects are cancelled
53% of projects see cost growth exceed 89%

While these reports are showing small signs of improvement year after year, most companies continue to struggle at delivering successful projects. Organizations need to look to different methods to address process shortcomings.

Who to Change?

When planning the introduction of agile approaches, we have far more than just the development team to consider. In fact, the successful adoption depends on a variety of stakeholders.

Executives

We need to win their support for the change. They are our enablers and obstacle removers.

Project Sponsors

These people hold the budget and are powerful project influencers. If we want to get approval to try new approaches, we need to convince sponsors, too.

Managers

Managers are typically the resource controllers, so we really need them on board. They can be useful allies or roadblocks to adopting a new process.

The Development Team

This is where the rubber hits the road. We need to make sure the development team is truly engaged in the process and involved in the planning and roll-out.

The User Community

Often the user community is a new partner in the process. If they have previously played only a passive role, we must now excite them with opportunities for more control and work on new engagement models to get them involved.

Supporting Groups

A database group, quality group, or project management office can be enablers or blockers to a process adoption. We need to ensure they have input.

#2: Not Engaging All the Necessary Stakeholders

You don’t need to get formal written approval from each of these groups before introducing agile, but be aware the success of an agile introduction goes much beyond the development team. Plan to interact and communicate often to win over as wide an audience as you can.

What to Change?

What may require changing is likely to be wider ranging than you might think.

New Methods of Decision-making

Dictatorial, command-and-control decision-making does not fit agile approaches. When the team does more of their own local planning, we should have better ways of gaining consensus and resolving conflicts.

Empowered Teams

Are the project managers ready and willing to turn over iteration planning to the team? Is the team ready? While iterative projects can be run as short waterfall projects, the real benefits of agile are only realized when we learn how to tap into the ownership, power, and accountability of empowered teams.

Business Prioritized Features

Is the business ready to get involved in prioritizing stories and evaluating increments of code on a regular basis? Is the project team ready to accept these development priorities and be directed by their customers?

Working with a New Group of Colleagues

For some organizations, having the development team working closely with the users of the system is new and disturbing. Some developers like to get their head down and code, deep in the moment of creative development. Users have a habit of interrupting coding nirvana with nasty exceptions to business processes and special cases that not all developers enjoy. Many business people equate working with the development team with joining their mechanic in the muck and oil of a garage when getting their car repaired. If it’s an IT job, do users need to be exposed to it?

Doing your Job Differently

Switching to an agile approach is likely to lead to less project documentation and more change requests, but these two are not directly linked. We are not getting more change requests due to poor documentation. Instead, the user community is engaged throughout the lifecycle and given more opportunities to interact and think about the evolving system, so a higher percentage of changes are uncovered during development when the costs of change are much lower.

#3: Not Considering the Full Scope of Changes Required

Agile change processes welcome late-breaking changes while many traditional change management processes are really “change prevention” processes. However, some people will feel uncomfortable without the two-inch-thick binder of (out of date) requirements on their desk. Document-centric people will be forced to communicate more with other project stakeholders and attend software demos to get the information they need, which is uncomfortable for some.

Relating to Superiors and/or Staff Members Differently

The role of a project leader on an agile team is more a servant leadership role than command-and-control directing. Most good project managers already know their role is to make the project team successful. Project managers do not add a lot of business value to software products, so they need to support the team.

#4: Not Considering the Social Factor Change Impacts of the Change

However, for some traditional project managers, this downward-serving model and increased levels of team planning and decision-making can feel threatening. Make no mistake, project leaders will still have a lot of responsibility, but their role and relationship with the team may be different. Furthermore, the team needs to be able to communicate bad news as well as good. Teams that struggle to give the boss bad news will also struggle to adopt agile methods.

When to Change?

We must also consider the timing of the change to agile. Below are some potential scenarios to consider.

When There are Problems with Current Processes

The current process consistently delivers late, over budget, or poorly accepted software.

When New Projects have Unknown Requirements

A project requirement like, “We need a customer self-service portal,” is likely to have a high rate of requirements evolution as the details become clear.

When New Projects Occur with High Technical Risk

Examples include using new languages, unprecedented technology, and untested interfaces. Whenever there is high technology risk, the iterative nature of agile projects is great for reducing risks early in the lifecycle.

Time Critical Projects

Timeboxed iterations and feature prioritization are effective ways of ensuring the best possible delivery for a fixed deadline.

#5: Assuming it is Always Best to Use an Agile Approach

We can also look to suitability filters to help guide us.

If, for example, our project has characteristics close to the inside of the chart, then an agile approach is suitable. However, if our project scores toward the middle of the chart, a hybrid may be best. Scores around the plan-driven periphery indicate an agile approach may not be the best approach for the project.

#6: Choosing an Inappropriately Sized Project When Adopting Agile

Deciding on where to first introduce agile approaches can be tricky. The change needs to be on a real project, otherwise people will dismiss any success as trivial. “Well it was only a toy project; it would not work on a real-world, complex project.” You must also see results quickly, so the new approach can be used on other projects. Do not choose a two-year monster project if you want to use the results to win over other groups quickly.

Real business need

Not a toy project, but a real one that must be done and is likely to experience the same issues as other projects

High visibility

A project that is both important enough to notice and has a good business spokesperson to easily publicize the successes.

Three-to-six-month schedule

Big enough to be deemed a real project, but short enough to quickly make use of the benefits.

With this approach, we run an initial project that has a real business need and is highly visible for two to six months. During this time, the team is training in agile methods with mentors. Then we review and document the project, publicizing its success and the satisfaction of the sponsor and users. Individuals from that initial project can go on to be mentors for subsequent projects, spreading the knowledge throughout the organization.

#7: Calling the Initial Project a “Pilot” Project

Using the term “pilot” indicates the project is a trial and may not continue. Obviously, our initial project is a trial, but why sow the seeds of doubt deliberately? Call it an initial project with the assumption of follow-up projects, and avoid this uncertainty risk. Little items like this can make big differences on project introduction initiatives.

Your Organization Adopting Agile?

With any change initiative, we should clearly understand why change is necessary. If an organization is having success with their existing process, even if it’s chaotic, I would question the need to introduce a new methodology. Instead, perhaps our efforts could be best used addressing incremental improvement.

More Agile Resources

Check out the types of resistors you may encounter when adopting agile. You can also listen to my webinar on Implementing Agile: Part One of a Two Part Series.  You can also read about the embracing agile methodologies.

If you’re finding you need a deeper understand of Agile to support adopting agile in your organization,  read my new book Agile Fundamentals: A Comprehensive Guide to Using an Agile Approach.