I made a new friend at a user group meeting recently and he started talking about some challenges he was facing with his team to transition them to agile software development. He read a lot about the subject matter and wanted my opinion on what his team needed to do to be successful in their transition. To read my thoughts on what they can do, please read on…

For transitioning teams, I always tell the leaders to first educate themselves, then educate their teams. For my new friend, he was already knowledgeable, this puts him ahead of the game, but his main challenge is that he does not have the time to educate his team. When in this situation, find others on the team that can help get the message across or hire a pro to do the training.

You need to understand there may be reluctance to change on your team. The best way to deal with this is to bring incremental change and use your retrospectives to help drive further improvements. Be consistent and make sure people know why they are doing and the benefits it will bring them to do it.

The next task is to identify who will be the Product Owner and work with that person to create a product backlog the team can work with. It may also be helpful for the Product Owner to build a vision of where the product needs to be down the road as this helps the team make sure they are doing the right things.

Initially, the Product Owner should identify as many high-level user stories as they can to create an early backlog. After doing this, one approach to round out the backlog is to hold story creation workshops where the team members can discuss the high-level stories with the Product Owner and start breaking them down in more manageable pieces.

Sometimes, customer commitments may drive the short-term vision of the product. In cases such as this, use the commitments to help identify the work in the backlog. As you are identifying more and more of the work, group them by themes and go back to the customer to allow them to identify what your next short-term priority should be. This is usually easier when dealing with a small set of stakeholders. The benefit of this approach is that it helps better manage expectations and allows the team to work on what is most important to the people using the software. Feature X may seem important initially, but if you deliver something else earlier, you may deliver more business value to your stakeholders faster.

There are times when transitioning teams are carrying a large technical debt with them (that is a large defect backlog). In cases such as these, teams need to get the defects backlog back under control. It is important not to increase the number of open defects so as the team is working on stories in a Sprint, they should fix new defects as they come in. Yes, it may impact the delivery of other stories, but one could argue the original story is incomplete if it still has open defects remaining.

To help prevent introducing more defects, using continuous integration with an automated unit test suit can help identify defects early. If you have no automated unit testing in place, a good start is to create tests for all new stories the team worked on as well as unit tests for any defects the team fixes. An alternative is to use interns to help build up a test suite.

To get the defect backlog back under control, some teams use alternating sprints. One to develop new features and the next one to target older defects from their backlog.

When adopting agile methodologies such as Scrum, even after you educate your team, there’s no guarantee they will not just go through the motions in the different meetings. One approach you may want to take is to invite an external observer with experience to help guide the team. The benefit of using an observer is to help the team achieve small successes faster. When teams fail early and often, the early enthusiasm may dwindle and the reluctant team members gain ammunition to keep resisting.

One point I cannot stress enough is to be consistent in what you do as you are trying to change habits and routines that people are already comfortable with. Hold your Daily Scrums at the same time each day, have your Sprint Planning, demos and retrospectives at a regular time as well each Sprint. Remember, you are trying to replace old habits with new ones. Skipping these meetings reduces their importance in the eyes of team members and makes them easier to skip again the next time.

This is a only a starting point of course… 😉 If you guys are facing challenges you are not sure how to deal with, feel free to e-mail me or to leave a comment.