Identifying the right pilot project is an extremely important first step towards your Agile transformation journey.

While selecting a pilot project, I generally look for the following characteristics:

• Importance: We don’t want to start with a project, which could shut down your business if things went wild. Nor do we want to pick a small pet project. Even if we proved Agile works well, it won’t appeal to the organization as it won’t be representative nor credible. A critical project with high-enough stakes is ideal.
• Dependencies: Fairly self-contained projects with minimum external dependencies are relatively easier for introducing change. If the team does not have the necessary skill or authority to take decision or if most of the project’s attributes are outside the organization’s control, it would be a very difficult pilot project.
• Stakeholder Engagement: Access to all the stakeholders is critical. Their involvement and buy-in is extremely important to make any sustainable change.
• Top-Management Support: During the transition, the team will run into many roadblocks and challenges. Having a good management support and backing will motivate the team to creatively solve those problems.
• Duration: To effectively capitalize on the learning and excitement, it’s important for the pilot project to be between 4-9 months.
• Size: A single collocated team with less than 10 members is an ideal size to coach. Gradually we can grow this team to large multi-site geographically distributed team/s.
• Stage: If the project was already in a fire-fighting mode, the team members would be under too much pressure to try anything different. If it’s a laid-back large maintenance project, team members might not have the motivation to change large legacy system. Project in its early stages with most of its team members on-board, seems to be a good stage to introduce Agile and Lean thinking.
• Team Composition: Most successful organizations have strong (vocal) leaders or connectors at the grass-root level. If we can influence these folks early on, they can be our internal change-agents. Hence while picking a pilot project, we consider their density in the pilot team.

Identifying a project with all these characteristics would be ideal, but is rarely the case. A good coach knows how to make reasonable trade-offs.

If you’ve inherited a Legacy Project (project without any tests) and say you want to enhance an existing feature, where do you start?

In such situations, I find myself building some form of workflow tests (scaffolding). I start off using a record and play back testing tool to record couple of scenarios for the feature, I want to enhance. Most often, I would take the recorded tests and covert them into a re-entrant, independent scripts. So that I can execute them over and over again, without needing manual intervention. Basically this would mean, automating the set up and tear down of the application’s external dependencies like data-stores, email servers, etc correctly. This should not take more than a couple of hours to configure.

This helps me build the initially safety net to start off. This also gives me a decent understanding of how the feature works. Now I can go inside the code, change something really small and see what impact it has on my tests. Some times I tweak my test to see what impact it has on the feature. Basically I’m using this test as a probe to gain deeper understanding of the feature’s functionality.

Doing this give me some confidence to jump in and start refactoring the code, so that I can create an inflection point, break dependencies and start writing unit tests around the core of my feature. In couple of hours, I should be able to build a solid safety net, around my feature using unit tests and/or business logic acceptance tests.

At this point, I almost always, go and delete the initial workflow test that I had built. This is the reason, I call this approach as the scaffolding technique.

• Build some initial workflow tests to help you get in there,
• Make the necessary code/config changes to write direct tests
• Gradually build a solid safety net around the feature
• The scaffolding (initial workflow tests) did its job, now its time to throw them away