Having watched the stream yesterday, for me it feels that not the roadmap itself is the key issue but the organization behind it at DTG. Probably this has a lot to do with the growth of the business and this happens to most companies sooner or later. I have a lot of experience with steering software maintenance and organizing the work. So maybe it is helpful to post some ideas, but before that some observations - Apparently all DTG development teams are somehow involved in fixing bugs and improvements of the product, but they seem to work very independently. - This causes a complete lack of overview on who is doing what. - The poor QA problem is informed after the work is done and needs to sort out if this is going to work together and push all effort towards a release schedule. - In their enthusiasm a lot of effort is put in trying to make a complete list of all issues to solve and all wishes for improvement.In the stream I saw it happen twice. Adam telling something is a good idea and adding it to his list. The result of all this is a a lot of communication effort (waste of money) and probably a lot of work that never makes it to production (also a waste of money). and finally long lead times to push anything through the process. A few things need to be done: 1. Define clear responsibilities by appointing people in the role of product owner. The product owner is the sole person that sets what should be done. You probably will need 3-4 persons having this role. One for the core, and maybe few others to divide the content in a sensible way. 2. There should be one backlog with all bugs. This backlog is the responsibility of the product owner. 3. The backlog should be written in functional terms and be motivated.It may include ways to solve and all information you need to solve the issue. It also should have an indication of value (how important is it to solve) and estimated effort (how much work is it). Dividing value by effort gives a ranking of what to look after first. One of the present problems seems to be that issues are described in terms of technical solutions. Tha, in general is not a very good idea. Users of the solution must be able to understand what they will get (the present roadmap is not good enough for that purpose) 4. The teams get their issues from the product owners,do their job and then proceed to the next one. 5. I would suggest to locate the product owners in the QA team, because there you have most overview. By selecting higher level goals like we want to upgrade LIRR this month may help to create additional focus. They also may pull fixes to release instead of the present process where things are pushed to the QA team. Start from what can be released instead of what can be built. What can you gain? - A harmonized issue list you can share and is readable for all people. - More focus - Avoid duplicated work - Less co-ordination effort - Much more bugs fixed. To get this all working, you may consider to hire an experienced agile coach for at least 3-6 months. These people are trained to make this happen and develop teams in their effectiveness. It also may lead to a higher first time right. This is a lot of text. I hope this may help a bit DTG will need to find its own way of doing things that fits the organization. That is something we cannot do from a distance. But I know these rather generic principles work.
