I would like to think that I have been doing Agile my whole life. Not scrum and stories and all that, just the spirit of Agile. Breaking big tasks down into little tiny chunks and designing each piece so that it fits into the big picture. When I started my career after college, I started in small companies with folks that were extremely talented and didn’t need a lot of management for the day to day tasks, so what meetings we did have were mostly about communicating what it was that needed to be done.
When I moved to larger companies, a lot of that changed. I no longer had a small team that was independent and could easily divide and conquer work. Instead, we had projects that were sophisticated but were themselves just small pieces in the larger picture, and the integrations between my projects and other projects really made it much harder to effectively work out the plan for delivering results.
Companies have relied on Waterfall for a long time to help manage this because sometimes you do need a decent amount of planning up front when you are trying to integrate these projects together to deliver enterprise solutions. Even with Agile, that doesn’t entirely go away. What does go away is the need to specify every last detail of every aspect of your application before even starting work. Instead, you identify some pieces of work that can be started while still figuring out the harder stuff.
This process is a journey, and it might not happen smoothly. You have to train folks to pick up new routines, change how they think about requirement definitions, and really let go of that desire to have it all spelled out ahead of time. It can be hard for folks that are used to building out requirements in template documents that have predefined sections that they fill in. Those documents help folks think about all the different things that will be required to build the application.
At the same time, however, those documents are a huge drain on time and often get put on a shelf as a reference while the project is underway and then forgotten afterwards. Agile stories can sometimes be like that as well, but you can write an Agile story in minutes. A business requirements document for a waterfall project can take days, weeks, or even months to put together. They also contain a lot of redundancies, unnecessary specifications, and empty sections that just are distractions from the actual content.
One thing that can help is to build templates for your Agile documents (features, stories, etc) that folks can fill in for every story. Teams will have to decide how strict they want to be about the contents (I sometimes have trouble formulating a story in the “As the user of the system I need XYZ” format), but having those templates can help folks transition from the business requirement documents to writing stories and features.
Another thing that can help is to understand the fact that part of being Agile is figuring out how you want the process to work. You will take training, read books, watch webinars, etc., but ultimately teams will have to try some different approaches and figure out what helps them be more effective. Depending on what kind of solutions you are trying to build, you might find different approaches work better. Kanban might make more sense than Scrum. You might find it better to have an actual board in your team room and folks move index cards around. Try different things and get feedback from the retrospectives on what is working and what isn’t.
Most of all, don’t spend time debating about whether Agile is more effective than Waterfall or not. Start small with a few teams if you aren’t sure it will work. It might not. Sometimes projects are so dependent on each other that you might need that business requirement document up front to coordinate a larger design. In general, however, Agile works with most projects, and sooner or later you will likely end up making the move.
Start the journey today. The sooner you get sprinting, the sooner you will be shipping results to customers and delivering value.