A lire sur: http://www.techrepublic.com/blog/project-management/apply-positive-agile-development-roadmap-practices-in-your-organization/4674?tag=nl.e053
I ask this question because many of the clients I meet in my training and consulting practice seem to see agile adoption as a methodology question. “If I can just get my PMO to use burn-down charts instead of Gantt charts, and to substitute daily standups for weekly task review meetings, I’ll be agile!” Unfortunately, my experience is that this view, of agile as a simple methodology shift, is a predictor of failure. It frequently goes together with a lack of management buy-in (”our managers don’t care what methodology we use as long as we deliver projects!”), lack of team training (”we’ll train the PMO and they can enforce the new standards!”), and, in the context of this discussion about roadmaps, lack of an overall guiding vision of both the migration (”why are we migrating to agile?”) and the project portfolio.
I often see agile trainers who unfortunately promote the methodology view of agile. They focus their training on the techniques and protocols, such as daily standups and scrum or kanban boards, and give short shrift to the strategic and “vision” elements of development. I agree that there’s merit in the philosophy that says new agile teams should hew closely to the known practices of scrum (or whatever their chosen approach), rather than starting their agile journey by making up their own set of techniques. I resist, however, when this becomes a process-driven exercise, in which the application of strict scrum practices is emphasized above the core values of collaboration, self-direction and, above all, individual accountability. The process adds value, but it’s not the process that drives results, it’s the people and their interactions.
Why am I digging down into the philosophy of agile in this conversation about roadmaps? The risk of a methodological focus in agile migrations is that the organization can become expert at the techniques of agile development while still missing the point of their development efforts. As depicted in the well-known Version One agile poster, agile development consists of a concentric set of planning activities, all of which are reliant on the strategic plan that drives the organization’s development efforts. Said more simply, without a roadmap, we may be great drivers but we don’t know where we’re heading. In an innovative culture that’s inventing something new, exploring the scenic byways is often an important element of our creative process, but, even in those circumstances, having a general roadmap that calls out the opportunities we’re trying to exploit and the possible endpoints we visualize can help focus the team’s energies.
Before we get to the user stories and the release planning, before we map out the iterations and the individual responsibilities, we need to build consensus around a roadmap that defines that vision and strategy we’re pursuing. I often draw the distinction here between the traditional style of strategic planning, in which only senior managers are invited to a closed door or off-site meeting, and they often return with a set of “sacred scrolls” that outline the enterprise’s strategic direction and high-priority initiatives for the next year or two, and the all-hands, iterative, and facilitated exercise that constitutes an agile strategy workshop. I’ve seen too many strategic off-sites that produce an unprioritized wish list of hundreds of initiatives, with no clear over-arching strategic purpose other than scratching the itch of each department or manager. Without an understanding of the strategic meaning of these programs, implementers (like the IT department) struggle to understand where they should be focusing their energies, and projects end up selected due to political clout or technical familiarity rather than strategic importance.
After all this talk about what a roadmap shouldn’t be, how can we apply positive roadmap practices in our organization? Here are some observations from my consulting work with high-performing agile teams:
Takeaway: The
view of agile development as a simple methodology shift is a predictor
of failure, according to Rick Freedman. Read his four tips on applying
positive agile roadmap practices.
I mentioned in a previous post that the current “word of the month” in the agile community is “roadmap.”
Let’s explore the idea of the roadmap a bit more and see why it has
captured the imagination of the agile community. To do so, we need to
ask a fundamental question: Is agile development a methodology or a
philosophy?I ask this question because many of the clients I meet in my training and consulting practice seem to see agile adoption as a methodology question. “If I can just get my PMO to use burn-down charts instead of Gantt charts, and to substitute daily standups for weekly task review meetings, I’ll be agile!” Unfortunately, my experience is that this view, of agile as a simple methodology shift, is a predictor of failure. It frequently goes together with a lack of management buy-in (”our managers don’t care what methodology we use as long as we deliver projects!”), lack of team training (”we’ll train the PMO and they can enforce the new standards!”), and, in the context of this discussion about roadmaps, lack of an overall guiding vision of both the migration (”why are we migrating to agile?”) and the project portfolio.
I often see agile trainers who unfortunately promote the methodology view of agile. They focus their training on the techniques and protocols, such as daily standups and scrum or kanban boards, and give short shrift to the strategic and “vision” elements of development. I agree that there’s merit in the philosophy that says new agile teams should hew closely to the known practices of scrum (or whatever their chosen approach), rather than starting their agile journey by making up their own set of techniques. I resist, however, when this becomes a process-driven exercise, in which the application of strict scrum practices is emphasized above the core values of collaboration, self-direction and, above all, individual accountability. The process adds value, but it’s not the process that drives results, it’s the people and their interactions.
Why am I digging down into the philosophy of agile in this conversation about roadmaps? The risk of a methodological focus in agile migrations is that the organization can become expert at the techniques of agile development while still missing the point of their development efforts. As depicted in the well-known Version One agile poster, agile development consists of a concentric set of planning activities, all of which are reliant on the strategic plan that drives the organization’s development efforts. Said more simply, without a roadmap, we may be great drivers but we don’t know where we’re heading. In an innovative culture that’s inventing something new, exploring the scenic byways is often an important element of our creative process, but, even in those circumstances, having a general roadmap that calls out the opportunities we’re trying to exploit and the possible endpoints we visualize can help focus the team’s energies.
Before we get to the user stories and the release planning, before we map out the iterations and the individual responsibilities, we need to build consensus around a roadmap that defines that vision and strategy we’re pursuing. I often draw the distinction here between the traditional style of strategic planning, in which only senior managers are invited to a closed door or off-site meeting, and they often return with a set of “sacred scrolls” that outline the enterprise’s strategic direction and high-priority initiatives for the next year or two, and the all-hands, iterative, and facilitated exercise that constitutes an agile strategy workshop. I’ve seen too many strategic off-sites that produce an unprioritized wish list of hundreds of initiatives, with no clear over-arching strategic purpose other than scratching the itch of each department or manager. Without an understanding of the strategic meaning of these programs, implementers (like the IT department) struggle to understand where they should be focusing their energies, and projects end up selected due to political clout or technical familiarity rather than strategic importance.
After all this talk about what a roadmap shouldn’t be, how can we apply positive roadmap practices in our organization? Here are some observations from my consulting work with high-performing agile teams:
- Roadmap planning is inclusive: The old model of strategy as an exclusive club where senior managers only are invited is dead. The core values of agile teach us that innovation requires collaboration and self-direction; this doesn’t apply only at the tactical, methodological level but at the vision and strategy level as well. Invite the IT teams, the developers, the rank-and-file business “do-ers” to the table, and develop strategies that actually resonate team-wide and have enthusiasm and commitment behind them.
- Prioritization means selection and sacrifice: Prioritizing efforts for investment and resource is about more than a stack-ranked list; if that list includes more projects than the team can possibly achieve, and lacks the support or understanding of the developers, it typically results in death-march projects with unrealistic and arbitrary deadlines, and lackluster efforts by uncommitted developers. We all know we’re not going to complete 165 projects this year; let’s stop fooling ourselves and do the heavy lifting of selecting the small number of real impact projects, and of getting the organization to agree on those and commit, not just dollars, but passion, personal accountability, and reputation on their completion.
- Predict but don’t prescribe: Persuasive roadmaps draw a broad picture of how the strategy will evolve, often describing the features and opportunities we hope to tackle in the first release or current year, and then, in gradually less specificity, define the general direction in which we hope to move the initiative. Good agile planners understand that, the further out we look, the hazier the picture and the more likely changing realities will drive changing priorities, but they also understand that a complete vacuum of planning creates confusion and saps commitment. On the other extreme, agile strategists need to ensure that general roadmap exercises don’t become estimations; especially in traditional environments accustomed to long-range estimates, stakeholders often try to turn vision exercises into “over the horizon” cost and schedule estimates.
- Share the vision: Good roadmaps don’t just tell us where we’re going - they tell us what waits at the end. Too many traditional strategic plans look like an update of the original business plan - dry, uninspiring, and written for accountants and bankers. Good roadmaps are marketing documents as well as strategic plans - they convince and persuade the enterprise that each selected program is worth doing, will bring defined benefits, and will reward the extra effort by improving the business and our business life.
Aucun commentaire:
Enregistrer un commentaire