There was a great article recently over on LeadingAgile titled No Excuses.  It was talking about the fact that there is never a perfect time to start a transformation.

With an agile transformation, each day will bring new lessons and experiences that make tomorrow easier. Challenges today will become routine capabilities in the future. Tomorrow will bring greater challenges than today and by continuing to move forward you build confidence in your abilities and I bet you’ll look with surprise and delight at how far you’ve come.

I’ve seen this in many transformations and have suffered from this myself.  We always want to wait for the conditions to be perfect, for everything to line up before we move to agile.  We want to talk through all the options and account for all the potential issues.  However, what often ends up happening is you just keep talking forever and you never start.  I think a good challenge to take is to stop talking and start doing.

A common scenario when starting an agile transformation if you have been following a more waterfall approach is that development is ahead of testing.  They may be a couple weeks ahead or a couple months ahead.  In this model, how do you form those cross functional teams?  You can’t decide not test the development work that has been completed but not yet tested, but if development continues to work ahead you are just adding to the problem.  I guess you could theoretically send your development staff on mandatory vacation for awhile, but that probably won’t go over very well and then they will have to fix the bugs that were found by testing while they were gone when they get back.

I’ve heard of several solutions to this problem but the one I like the best is the option of forming the teams today and the initial backlogs consist of stories to complete the testing effort on the completed development.  The team then has to plan how to accomplish this as a team.  What can the developers do to help the testers complete the testing effort?  There are automation scripts they can write.  They can execute manual test plans (I’d be willing to bet you will end up with more automation if you try and get developers to execute manual test plans).  They can help build some better tools and test harnesses to improve automation.  They can write unit tests if they haven’t already been doing that.  At the very least they can be pairing with the testers and fixing bugs found along the way right then and there.  Then, as the team starts to get through the testing backlog, they can start grooming sessions to prepare for the next set of work.

Honestly, I think one of the biggest benefits of this approach is that it puts a bigger emphasis on the team working together as a single unit.  With “standard” work (features) it is very easy for new teams to fall into scrummerfall and start planning out the work in functional silos within the sprint.  Since this backlog of testing isn’t the “normal” work that will utilize everyone’s specialty and that they are used to planning in that waterfall fashion, it puts pressure on the other team members to collaborate more and find ways to work better as a single unit.

Of course, that is just one example of something that is often viewed as an obstacle to starting an agile transformation and only one example of a solution.  If you are suffering from that problem and are struggling to get started, maybe this approach will work for you.  Even if it won’t, hopefully this has encouraged you to maybe think outside the box a little and come up with another solution that will allow you to get started today instead of waiting for the perfect conditions.