Scott RollinsSr. Agile Consultant| AccenturePleasanton, Ca, United States
I''m often asked about best practices as it pertains to building or releasing a product roadmap? I''m curious to see how other Agile leaders field this particular question?
My first response is, why are you releasing a roadmap to begin with? A roadmap is really just a plan to release certain features at certain time frames. The whole value of being agile is adapting to the marketplace when it''s necessary to do so. The whole reason I never planned in the military is it''s just a waste of time. Never plan. Be prepared. Train. But, never plan. Every plan I''ve ever seen or heard went right out the door the second the first shot was fired. Plan to adapt. Plan to be available to the most valuable idea available the second its available. That''s a lot of available(s). But, makes the case of how important flexibility really is. Not just on the battlefield, but in business as well. Once it''s put on the roadmap, it''s like God put it there or something. And, no one has the courage to take it off.
I suggest not releasing any kind of roadmap. Just tell everyone, you are in for a surprise. It will also give you a excellent understanding of the value you are really providing for your stakeholders. Remember, 80% o the software we make never gets used. And, 98% o all software sold is considered crap and a failure. Stick to the one or two things your currently working on and call that good to go for a roadmap. Anything else is just marketing and not agile, in my opinion. Let marketing figure out some other way to earn their money.
Alistair DuguidTechnical Delivery Manager| Informatica CorporationShelton, Ct, United States
Hi Scott, ever heard of "setting expectations"? We do that because, regardless of whether you want to plan or not, people are going to have expectations. So giving them a roadmap helps to shape those expectations, rather than let them make up their own, and then be disappointed by how they don''t align with reality as it plays out.
That said, I don''t think an "agile team" is in the business of publishing road maps. I would see that as the exclusive preserve of the Customer or Product Owner. It''s up to the Product Owner to know her audience and to decide whether publishing a road map is desirable. Most audiences or end-users benefit from some sort of road map, and moreover, expect it. I personally believe a road map is of immense benefit to most end-users, managers, and customers, so I would support preparing one.
But a road map isn''t a project plan. It''s just today''s version of the product backlog, today''s list of features placed in a certain order and chunked up into potential releases. It can change, and it will change. The degree to which a feature-level road map will change along with the product backlog is probably a function of how large-grained and abstract the road map is. If it says "in 2016 we plan to introduce automatic data export from our application to Salesforce.com", then there''s a good chance you''ll be able to meet that goal even if lower-level, more detailed stories are undergoing substantial change and the requirements for them are not fully known. If on the other hand, your road map has huge amounts of detail, and promises specific delivery dates for all of it, well, the chances that you won''t execute exactly according to that plan go up.
Lastly, I have to ask, were you a junior officer in the military, perhaps in the infantry? I wonder how your advice to "never plan" would have gone down say, at major command level, where plans are what they live and breathe? Or in the artillery, where the planning of "plotted fires" or "pre-registered targets" is normal? And isn''t it Ike Eisenhower''s own quote that "plans are useless but planning is essential"? Does that square with "never plan"?
Nobody is disputing that in a fluid combat situation, a rigid and detailed plan will quickly become irrelevant to the situation on the ground, but does that really mean that you shouldn''t even plan? Doesn''t it rather suggest that the granularity of the plan is too fine? Shouldn''t you still have a some strategic and tactical ideas that are still valid, even if you can''t predict how things will go in any detail? Isn''t that still part of "planning"?
And in a similar vein, in moving towards agile aren''t we just relaxing the way we plan to make it less rigid, and more accepting of change, and therefore more likely to be still relevant and useful when our project is underway? Saving Changes...
Alistair DuguidTechnical Delivery Manager| Informatica CorporationShelton, Ct, United States
Looks like there is a new posting script that does something weird to single quotes!
Scott RollinsSr. Agile Consultant| AccenturePleasanton, Ca, United States
Thanks for the feedback Alistair. I think we are probably dealing with a fair amount of semantics. I bet we are more on the same page then we appear.
Believe it or not, we don''t plan in the military. We plan to re-plan if anything. We have our mission and vision and an overall game plan so to speak. But, how we accomplish a certain task in the field is accomplished through training and not following a prescribed plan. We practice until we don''t have to think about it. Then, we adapt and overcome. Really, it''s that simple.
Sorry if I spoke out of line or offended you. Public speaking and writing is not my strong suit and I tend to come across as an asshole.
By the way, I spent every day of my military career on the ground with my team as a enlisted non commissioned officer. We you to joke that, "we weren''t officers, we worked for a living."
Good day. -- Scott Saving Changes...
Alistair DuguidTechnical Delivery Manager| Informatica CorporationShelton, Ct, United States
Not to worry, Scott, I wasn''t in the least offended! I agree that we are indeed probably more on the same page than it might appear, as you suggest.
It''s interesting that "not planning" has risen to the level of doctrine in the military. But would it be fair to call it "just-in-time planning" rather than not planning at all? I''m thinking maybe as a senior NCO you roll up to some situation, you jump out of your Humvee, and you make a plan of action on the spot, rather than having brought one with you. So you''d be planning to some degree, but in a very immediate way. Do you agree?
After all, as an NCO encountering some situation, you need to issue orders to your guys, and tell them what to do to some degree, right? (No matter how well trained thay are.) Or at least tell them what your perception of the situation is, your intentions and goals, the commander''s intentions and goals, and how your team might achieve those goals through specific immediate actions of their own. Couldn''t you call that sort of immediate tactical decision making and goal setting "planning" as well? Planning done just-in-time, when it is relevant to the actual situation on the battlefield, and therefore more valuable than a plan concocted two days before, with incomplete knowledge, and back at HQ? Saving Changes...
Scott RollinsSr. Agile Consultant| AccenturePleasanton, Ca, United States
That''s it Alistair. You hit it right on the head. Planning is attempted. We like to think we can anticipate and plan and we do to a big extent. However, we always try to disclaim the need to be adaptable and flexible. That''s why we train so much. We train to be able to cover all possible situations and be able to react quickly when a plan needs to change. Your just-in-time example is right on. Couldn''t have said it better myself. That''s exactly what happens during a real mission. We come up with short term plans and adapt the best we can. But, you are right. It might be something as easy as, "cover me as I move." But, that''s a plan when you think about it. I wish our business plans had as much flexibility. Seems, we just look at the plan and follow it blindly. At Nokia, we had an 18 month BRD we were working on when the iPhone first came out. Nokia still went forward with the plan we already had and 18 months later we we''re relevant in the US market anymore. Following our plan cost the company billions. Very dangerous not being adaptive as a culture. I guess that''s the point I''m trying to make to my team I currently working with. However, it seems my warnings fall on deaf ears. Saving Changes...
Stefan SchneiderBusiness Analyst| OTTOGROUPHenstedt-Ulzburg, Sh, Germany
I think if a project has such erratic needs, that no more than one or two deliverables could be prepared to work out next, then it is not really a project but moreover an ongoing maintenance effort.
If the requirements are stable in the core, but often changing with details and priority, the roadmap should be versioned and any start of working on the next priorised deliverable as of the last version should be kept on hold until the roadmap again was verified and turns out actual further. Or changed, which perhaps make another need more important, which is OK when agile approach is used. Saving Changes...
John MwakaProject Manager| Aurelec PME LtdTanzania, Tanzania, United Republic Of
I think that Agile teams should set expectations or road-maps to begin with and in the process of execution they will be applying the necessary on-time plans which will get them there!
My two comments are:
1. Agile team(s) will do the job differently most of the time.
2. Agile teams must be very well trained or must be very experienced in order to respond strategically in order to achieve the goal. Saving Changes...
Wayne MackRetired| RetiredSouth Riding, Va, United States
Yes, a Release Roadmap is another name for a plan, but the difference is what is being planned. In a traditional schedule, one plans the sequence of development activities, while in a release roadmap, one plans a sequence of releases.
How would one specify what development should occur without some expectation of a result? Why would one even have a development team? If one has a product to development and maintain, there must be some unmet needs, so how should the organization determine what to do next? How does the organization determine how to decompose a large effort into a sequence smaller, releasable efforts? Which one gets done first?
Developing a Release Roadmap is a significantly different planning effort than traditional development scheduling, but one the relates directly to value realization by the organization. It is a needed activity. Saving Changes...
Lawrence CooperCreator, Lean-Agile Strategy| AdaptiveOrg Inc.Kanata, Ontario, Canada
I seen planning as needing to be both adaptive and continuous. Roadmaps, product visions, etc. are not inherently bad as they do serve to give some sense of what we are trying to accomplish and can be used to create a shared understanding of the goals. As long as we aren''t doctrinaire about it I don''t see the big issue.
In our book we extended the notion of emergence to also include problem understanding (or problem solving) as rightly so beyond YAGNI (the stuff we don''t need) people also say IKIWISI for the emergent and adaptive aspects.
I, like I think Wayne implies, come at it from the Value perspective using Outcomes Maps or Impact Maps to help answer the "why" questions up front and along the way to help us grapple with the what, when, where and how of it. This helps us to identify what benefits we should expect when and gives us thee tools to determine the business value of things so they can then be appropriately prioritized on the way to being realized. Saving Changes...
A Release Roadmap can serve as a communication tools to set expectations for different groups of people in the company. For example, Marketing people may need to know when a release of a mobile app will be expected and plan for a marketing campaign.
The other function of a release Roadmap can be used to predict the effort, risk, and timeline for such release. One technique that my company is using is called the "Extreme Quotation". Saving Changes...
