Don’t Miss The Product Roadmap
Agile is the way to go; but Agile needs to be guided by a roadmap
There is a lot of literature that covers different software development methodologies so I won’t go in detail about them. Traditionally there was a waterfall method that software giants were very much focused on. With the new tech products coming out quickly the waterfall approach is gradually becoming obsolete. BUT ONLY for the products that need to be rolled out quickly. For some products waterfall (or Spiral) would still make sense.
Agile is the way to go now. Build quickly, deploy quickly, get feedback and then build on top of it incrementally. One of the most important element of the Agile program is the roadmap. Agile DOES NOT mean running hackathons and producing builds. Agile is also a very sophisticated software development methodology which requires a lot of planning.
I have seen teams getting excited about hopping on to Sprints very quickly with very limited planning done. If you are having daily SCRUM meetings or are managing your tasks through a Kanban, it does not mean you are running a true Agile program. An Agile program cannot be directionless. It starts with a roadmap. Of course this is not a set in stone sort of a document but this needs to be drafted to an extent that the complete team is in sync on what needs to be developed. The team needs to own the roadmap. The roadmap will contain short term and long term goals of the product. This roadmap will later translate into a set of requirements which will go into product backlog.
I have been reading a bunch of articles on Agile and have found this very useful. I will just focus more on the roadmap in this piece of writing. Product roadmap does not need to confused with traditional detailed software requirements specification documents and project plans that were developed in Waterfall projects. Of course if you can make them, nothing like it. The problem is that we do not want to spend too much time drafting something that may change over time. This can be a list of features and /or a presentation of customer needs with relative priorities mentioned. A timeline can be mentioned against the feature sets as well. This will be a living document and can change over time. It is important to build it, share it with the complete team and get their buy in on it. Over the period of time this roadmap will evolve so it is very important that the whole team stays in sync on its evolution. There are a number of tools that allow us to do that.
Remember Agile requires a lot of trust in the complete team. The product owner, product manager, development manager, development and testing team are expected to give feedback very regularly. All stake holders are required to modify the expectations based on this feedback. The expectations from an Agile development program should not be those of a waterfall dev cycle. Since the roadmap is drafted to be a flexible document, it needs to be evolved based on the progress made during every Sprint. It is the responsibility of the Product owner to make the required modifications to the roadmap and share it with the team.
Here is a very good article to understand the importance of roadmaps as the start point of all Agile development programs. It starts like this:
Do give it a read.