How to start Agile coming from Waterfall

As I’ve mentioned in earlier posts, I have been coaching teams for the better part of the year now. The vast majority of these teams are trying out a type of agile methodology, coming from a waterfall SDLC. Below are a few pointers to help those out who are embarking upon the same path of converting the team from waterfall to agile.

1. Determine the old SDLC and the new SDLC
2. Determine if we need additional people to support the team through the transition to the new methodology
3. Gauge the team’s knowledge of the new SDLC
4. Determine the team training needs
5. Get the team trained
6. Staff folks who know the new methodology with folks who do not, to act as a coach and mentor
7. Coach and push the team into the new methodology. Some folks may want to start by dipping a toe in by taking only a subset of scope through the new process while others may want to rip the band-aid off and jump into the deep end first.

There were specific steps I took to help the team migrate from a waterfall environment to agile also taking into consideration the requirements methodology that ArgonDigital employs, which come after step 6 above:

1. Team kickoff for the new methodology
2. Discuss goals and what success looks like within the new methodology, knowing that there will be a learning curve and potential issues the team will need to work out
3. Review available/existing project documentation
4. Set up the team’s tools (eg. requirements management and delivery tools) and determine how the team will self-organize
5. Create the business objectives model, org chart, and feature tree
6. Create process flows, data models, and system models
7. Determine minimum viable product (MVP)
8. Review or create (depending on existing project documentation) EPICs and start user stories (this is about where sprint 0 starts)
9. Continue with user story refinement sessions, and prior to exiting sprint 0 the team should be 2-3 sprints ahead of development in terms of user story creation

The team must be tolerant of mistakes and issues, but also be committed to work through those together. There will be a learning curve. Progress will be made. It’s important to learn that the coach cannot complete everything for the team. The coach must teach the team to act on their own. Notice that I didn’t mandate co-location. Although a common request within agile methodologies, it’s typically not possible for large companies, as folks tend to be distributed. For those who are looking to get into the space and move forward, this should provide a jumping board from which you can jump off to start your own process to improve your own methodology.