This is the first of two blog posts that accompany RMC’s Introducing Agile webinars.This post covers the five Ws (Why, Who, What, When, and Where) of introducing agile and describes seven common pitfalls organizations make when adopting agile approaches.Why Change?
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.
Pitfall #1: Introducing 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.
We need to win their support for the change. They are our enablers and obstacle removers.
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 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.
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.
Pitfall #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.
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.
Pitfall #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.
Pitfall #4: Not considering the social factor 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.
Pitfall #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.
Pitfall #6: Choosing an inappropriately sized project to roll-out the new approach.
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
A project that is both important enough to notice and has a good business spokesperson to easily publicize the successes.
Big enough to be deemed a real project, but short enough to quickly make use of the benefits.
An effective model for rolling out agile methods is shown below:
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.
Pitfall #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.
Continue reading Part two of Introducing Agile-Resistance to Change Strategies on converging 360 and examine resistance to change and effective strategies of overcoming it.
Related Webinar: Implementing Agile: Part One of a Two Part Series
Access Here: https://rmcls.com/360/implementing-agilepart-one-two-part-series-webinar-recording/