That said most organizations have plenty of room for improvement in their software development process. The Standish “Chaos Reports” repeatedly give low figures for project success rates and metrics such as:

• Only 16% of project complete on time and budget
• 31% of projects are cancelled
• 53% of projects cost growth exceeded 89%

While the Standish reports are showing small signs of improvement year on year, the main theme is that the majority of companies continue to struggle at delivering successful projects. Given that the definition of stupidity is “Stupidity: doing the same thing over and over and expecting different results.” Organizations need to look to different methods to address the process short comings. Otherwise, as Sir Francis Bacon observed in 1590, “He who will not apply new remedies must expect old evils.”

Who to Change?
When planning the introduction of agile methods we have far more than just the development team to consider.  In fact the successful adoption depends upon a variety of stakeholders including:

Executives

• We need to win their support and buy-in to 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 then we need to convince these folks 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 so get them on side.

The development team

• This is where the rubber hits the road, we need to make sure they are truly engaged in the process and involved in the planning and roll-out.

The user community

• Often the user community are new partners in the process. If they have previously played only a passive role, we need to now ignite them with the opportunities for more control and work on new engagement models to get them involved.

Supporting groups

• Specialized groups like a database group, quality, or a project management office can be enablers or blockers to a process adoption. We need to ensure they have an input too.

Now, I am not stating that you need to get formal written approval from each of these groups before introducing agile. Rather, be aware that the success of an agile introduction goes much beyond the development team. So plan to interact, communicate and win over as wide an audience as you can

Mistake # 2: Not engaging all the necessary stakeholders.

What Changes Might be Necessary?
Just what may require changing is likely to be wider ranging than you might think. These typically include:

New methods of decision making – dictatorial, command-and-control decision making does not fit agile methods, plus since the team will be doing more of their own local planning we ought to  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 multiple, 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 evaluate 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. Likewise, many business folks equate working with the development team as having to join their mechanic in the muck and oil of a garage when getting their car repaired. It is an IT job, do they need to be exposed to it?

Doing your job differently – A switch to agile is likely to lead to less project documentation and more change requests. (The two are not directly linked; we are not getting more change requests because things were not documented properly. Instead the user community is engaged throughout the lifecycle and given more opportunities to interact and think about the evolving system so higher percentage of changes are uncovered during development when the costs of change are much lower than after deployment.) Also 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 sat on their desk. Document centric people will be forced to communicate more with other project stakeholders and attend software demo’s to get the information they need, which for some people is uncomfortable.

Relating to one's superiors and/or staff members differently – The role of a project manager on an agile team is more a servant leadership role than command-and-control directing. Most good project managers already know that they are there to make the project team successful, they do not add a lot of business value to software products so they need to support the team. However for some project managers this downward serving model and increased levels of team planning and decision making can feel threatening. Make no mistake there is still lots to be done, just the role and relationship may be different than previously experienced. Likewise the team needs to be able to communicate bad news as well as good. Teams or cultures where giving your boss bad news is difficult struggle to adopt agile methods. Project managers or scrum masters can not remove impediments or help with resourcing problems if people are afraid to tell them what they are.

Mistake # 3: Not considering the full scope of changes required.

Mistake # 4: Not considering the social factor impacts of the change.

When to Change?

We need to consider the timing of the change. For the introduction of agile methods, it may well be appropriate:

When there are problems with current processes – if the current process consistently delivers late, or over budget, or poorly accepted software.

When new projects occur with high levels of requirements uncertainty – for instance a project with vague requirements “We need a customer self-service portal” that is likely to have a high rate of requirements evolution as the details become clear.

When new projects occur with high technical risk – for instance using new languages, unprecedented technology, 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 – for instance if a product has to be ready for a November trade show. Timeboxed iterations and feature prioritization are effective ways of ensuring the best possible delivery for an immovable date.

We can also look to Barry Boehm and Richard Turner’s Agility Radar Diagram to help guide us.

If, when we assess our project factors we see that the project has characteristics close to the inside of the chart then an agile approach is suitable. If however it scores further out, around the plan-driven periphery then perhaps agile is not the best approach to use this time.

Mistake # 5: Assuming it is always best to use an agile approach.

Where to Change first?
Deciding on where to first introduce agile methods can be tricky. It needs to be 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 one”. Balance with this the need to see results quickly and roll out successful approaches to other projects, so they can get the benefits too. So do not choose a two year plus monster project if you want to use the results to win over other groups quickly.

IBM Rational had some nice recommendations on initial project selection for switching to RUP that I have found to be successful on agile projects also:

Real business need
• Not a toy project, but a real one people know needs to be done and is likely to be troubled by the same issues as other projects

High visibility
• One that people will see and have to take notice of
• Easy to publicize the successes  (just make sure it is a success!)
• Has a good business spokesperson to spread the word

3 - 6 month schedule
• This is big enough (just) 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 3-6 months. During this time the team is training in agile methods and mentoring is provided. Then we review and document the project, publicizing its success and how happy the sponsor and users are. Then individuals from that initial project can go on to be mentors for subsequent projects, scaling out the knowledge through the organization.

Note I did not call the initial project a “Pilot” project, it was pointed out to me many years ago that using the term “pilot” indicates that something 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 there will be follow-on projects and you will avoid this uncertainty risk. Little items like this can make big differences on project introduction initiatives.

Mistake # 6: Choosing and inappropriately sized project to rollout the new approach on.

Mistake # 7: Calling the initial project a “Pilot” project.

“It's easier to act your way into a new way of thinking than to think your way into a new way of acting.”  --Millard Fuller

Check back soon for Part 2 when I will explain why change is difficult, why people naturally resist change, and when people do accept changes.