You want your software development team to switch from using a waterfall approach to using an agile approach like Scrum, Kanban, Lean or XP. Should you do it gradually or go cold turkey (all at once)?
Before you answer that question there are a few things to consider. Let’s walk through an example. This will be a rather extreme case to get you to think about how complex this transition can be.
For this example, we have a strong software development team. They have a good track record. There are no pressing problems to solve. The motivation for changing the development approach is to try something new and see what effect it has.
Management identifies a new product. It’s not a desktop application that has been the company’s strength. It’s a web-based application taking the company in a new direction. This is a great time to try a new development approach, right?
Here is a list of the major things that will need to change in adopting the new approach and building the new application. Let’s assume they’ve decided to adopt Scrum.
- Approach – From Waterfall to Scrum
- Tools – From desktop software build tools to browser- and server-based tools
- Office Layout – From distributed cubes to cohabited open space
- Work Style – From individual efforts to team efforts
- Control Style – From tasks assigned by a manager to self-organizing workflow
- Alignment – From isolated work efforts to collaboration with business people
- Documentation – From formal, lengthy specifications to informal, brief stories
- Meetings – From formal status and review meetings to informal daily standups
- Deployments – From two (QA and production) to many (after each sprint)
I could go on but you get the idea. A lot is changing — in fact, everything is changing. Will this team be successful?
Maybe but not likely — too much is changing too fast. For this team to succeed, here’s what needs to happen.
- Training – The team won’t know where to begin. Scrum training and web-based application development training are essential.
- Coaching – Even with training, they will make rookie mistakes. Direct assistance from someone who has experience with Scrum and web-based software development is needed (not necessarily one person).
- Time to fail – The team cannot estimate tasks with any precision. There are too many unknowns. They need time to experiment and mature.
If the management team is willing to put money and time into this effort, the team will succeed. Unfortunately, senior managers tend to be impatient and cheap. They want instant results. Problems can always be fixed later — if there is a “later“.
If you decide to make such drastic changes, tread carefully. If money and time are not on your side, consider changing one or two things such as the language and the tools. Once the team is comfortable, change one or two more and keep at it.
Lastly, have good reasons for changing. Simply wanting to “try something new” is not a good reason.