Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Incremental Agile Implementation
I used to be a rabid opponent of incremental implementation of agile processes. I even posted a warning against it at my web site. I've become more flexible as I've come to understand the degree of change required by agile processes and the reluctance of people to change without personally compelling reasons. I still work project by project in these organizations, but most of my effort is to help the people involved in the project—the customers, businesspeople, and developers—to want to change. I do this by several methods:
Downplay the agile process. These people aren't interested in something new; they're quite comfortable. Any training is academic. Let's talk about their project, not the agile process.
Play up the use of specific agile practices to solve point problems. Where are these people having problems, right then and there? Solve these problems by implementing a specific practice. If code quality is a problem, implement test first, followed by code or frequent builds. If analysis-paralysis is a problem, implement incremental, iterative delivery of code. If customer involvement is a problem, introduce a prioritized product backlog with incremental review of functionality.
Simplify the implementation and use of the agile practices. Conduct sessions in which the immediate problems are worked through by using the agile practices. Show people how they will work on the problem in a new way—a way that's productive and helpful right then. Since they aren't aware of their overall pain caused by dysfunctional practices, help them solve the pain that they know, that they feel right then. Each agile practice is a point tool to solve a specific problem.
Some examples:
At one organization, user departments were discontented with the workflow system being built by IT. Everyone wanted something different, and they were all going to be unhappy if they didn't get it. The developers were frustrated because they felt they could never capture all of the requirements. The users were frustrated because they weren't getting anything. I had them start meeting monthly. The users presented to the developers their most pressing problems. Then the users and developers mutually brainstormed about what problems the developers could solve over the next thirty days. The developers came back thirty days later and showed the users what they had accomplished. The users and developers collaborated. Without knowing the terminology, they nonetheless started using a prioritized product backlog, self-organization, emergence, and incremental product delivery. They became partners in a joint effort to solve user problems.
At another organization, IT development was divided into analysis and development. The analysts had moved ahead and completed some use cases and object models. I had the developers form into agile teams to turn these artifacts into working functionality. The teams weren't truly cross-functional, since much of the analysis was already done. I had the customer prioritize the artifacts into a functionality list that drove the development teams. The developers incrementally built the product, letting the detailed architecture and design emerge. The developers avoided having to understand everything to proceed. All they needed to know was what would keep them going for the next thirty days. Again, emergence, self-organization, and incremental delivery were implemented.
I know. This isn't elegant. This implementation style doesn't show that the old way is wrong. The organization doesn't even understand the underlying reason why the new approach works better than the old approach. But they know that something feels better. They want to know more. They begin to trust that the agile processes may be worthwhile. They become willing to try more change. My role then becomes that of a mentor. I help them identify and solve new problems with agile practices. I help them devise organizational strategies around these agile practices. As pain in one area is addressed, I help them see other areas where they could improve. I then work with them to implement agile practices in those areas, focusing on solving the problem rather than implementing a methodology.
The desired end result is organization using agile processes and realizing all of the benefits we've come to know. When agile processes are implemented piecemeal to solve problems, improvements occur. Compared to other projects, the agile project stands out. The results are dramatic. The teams are glad to come to work. The customers are delighted and tell their friends. Change becomes a pull from the customer rather than a push into the customer. This is only possible, however, by building trust through small successes.