We always want to know future especially when it’s related to delivery of complex software projects. I personally failed in making plans almost always in my career, but improved myself in planning: setting boundaries, watching trends, adjusting often, planning very little ahead, changing direction completely and more…
Also realised that creating too much overhead in formalizing plans and decision making slows you down and reduces motivation in making changes in the plan. We need to change fast and often (at least in certain types of activities) for the following reasons:
- imperfect, incomplete knowledge
- the unknown
- variety of outcomes
- simplification of activities
Probably any person who wants to have a very good plan
must have some checklist with things mentioned above which helps to evaluate context. And the more “yes” you have for you context than less formalised plan you should have, adjust it often and shift faster towards network organisation.
When you know what you want to achieve, but don’t know how – you need Strategy.
Strategy = boundaries and set of principles, nothing more. Executing strategy – operating within those boundaries and according described principles.
Plans are helpful when task is well-known. If you don’t know how to do it – just ask people who already know that. No need to reinvent.
Various Agile frameworks are struggling to uncover better ways of developing software or probably not only
As Agile manifesto states that we need to focus on these things:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Since we mostly work in fast changing environments it becomes obvious that it is important to have an ability to respond to changes during the project.
I noticed based on mine experience that it’s quite a challenging task to achieve due to various number of rules and number of people involved in decision making.
Various planning tools that are commonly used for plans, documentation and communication are not so visual and require special knowledge. As the result it is not so easy to change those plans and communicate them to everyone in the team sometimes.
And the most important thing that developers do not refer to those global plans during everyday work and don’t have a long term vision of what is planned e.g. in 3 months.
In order to improve this we decided to bring one more paper with sticky notes into team’s room called “RoadMap”. It helps us to visualize Roadmap and we use it on Quarter basis.
This chart is placed besides our daily Burndown chart and team is always aware if any changes occur in high level vision. (It’s important for us since we are working on Product, not Project) You will see two samples inline below.
So, I believe that such way of representing road map helps to solve following problems:
- Share high level vision with the team and allign expectations
- Easier/faster communication of changes
- Additional tool for grooming upcoming items
- Visual representation of plan for better decision making
- It is fun, easy and always in front of you
P.S. And don’t forget Plans are nothing, Planning is everything