Pilot agile projects are usually successful, but it is just a beginning

The first agile project is usually very exciting and goes really well. It might be concluded then that the new solid process is established and from now on all projects would follow that successful path.

However, that does not always happen. This is just a first step to evolve to the process (set of practices) that will maximize well-being of the organization (productivity, quality and well-being of the participants).

Here is a little theory on why this is just the beginning and where to go from there.

The successful pilot

Perfect conditions are usually created for the pilot:

• New process is defined by internal team or external consulting organization.
• New project is selected that is sizable, but not too large – perfect example for the proof of concept.
• There is full executive support behind the project to make sure that space, support, money, resources are all aligned and available.
• Agile coaches and sometimes architecture, design and development mentors are on stand-by.
• Business owners are relieved from conflicting responsibilities to fully support this project.
• Best architects, analysts, designers, developers, testers are allocated and moved from other projects if necessary.
• Team is co-located. Best room is allocated. Snacks are never ending. Any roadblocks along the way are removed by supportive executive team.

And results are there:

• Team is enthusiastic and productive.
• Interfacing teams are fully cooperating.
• Project is delivered with the expected quality and usually within expected timeframe.

Cost is typically high if you count consulting support, impact on other projects by moving resources, and other unusual expenses. But the hope here is that extra cost would disappear when agile process becomes a norm. 

The expectations

The expectations at this point are usually high:

• Since the process proved to be working it seems like it can be finalized.
• Now it is time to finish the training and roll out the process to the entire organization.
• Consulting support could be reduced as former trainee could become trainers. 
• All projects now should follow the new process exactly as defined and the results will continue to show.

The Reality

If all projects in the organization are similar to the pilot, and if the perfect conditions that were created for the pilot continue to exist, the similar success will likely happen for the incoming projects.

However, that is rarely the case in any sizable organization with some level of resource and budget constraints and multiple parallel projects of different complexity.

As a result, the high expectations are not usually achieved soon enough or at all.

Here are few typical reasons for that:

• Executive focus shifts to other priorities.
• Funding for process support is reduced.
• People on the projects are forced to multitask to deal with conflicting priorities.
• One-off situations are not cleanly supported by the new process. The few examples are: dealing with projects that started well before the new process; getting help from interfacing teams that did not switch to new process or have conflicting schedules for their own projects; testing teams and development environments are not ready for multiple agile projects.
• Firm deadlines force teams to compromise on adequate user story development, analysis, design and testing.
• Process is not evolving to adapt to more complex reality. 

At that point there are few options (I like the last one the best):

1. Keep process the same and let people fake it.
2. Go to the old process or implement different version of the process.
3. Collect feedback, act on it and keep evolving the process.

The road ahead

When you develop a good user story, or do a software design, or a comprehensive test plan it is clear that there is usually a happy path and exceptions. All of those need to be supported. In addition, some necessary information can only be discovered later in the project. Because of that iterative development processes (including agile) along with the genuine drive for the continuous improvements are very helpful.

Same principles apply to the process design. It might be useful to recognize that it is an iterative effort to optimize your new development process and to make it stick.

Here are few suggestions on how to deal with that:

• Encourage open feedback on process execution from all levels on business and development side. Then analyze and act on that feedback.
• Identify all the gaps (for example, one off projects, resources, organizational structure and other constraints, and so on). Then design practical approaches / process enhancements to address those gaps. That might include process adjustments as well as other changes including tool set, organizational structure, defining priorities and product release schedules across the organization.
• Be realistic, practical and flexible about you process implementation to make sure it addresses your unique needs. Here are few thought on how to be more agile about your agile implementation that I shared in another article: Be more agile about agile

Defining the foundation for your agile process and executing the successful pilot are great first steps, but it will take few iterations to make it right and ongoing adjustments to keep it right.

Establishing agile process that perfectly fits your company and your projects is a complex and exciting project. That project itself could be managed using the agile methodology. It totally worth the effort as it improves your chances to create great products, to have a happy team and ultimately happy customers.   

And that is the story.