Eduardo Miranda
mirandae@andrew.cmu.edu
Carnegie Mellon University, USA
INTRODUCTION
Any team or ensemble of teams, whether traditional or agile, working in a project of any size or consequence, needs a shared understanding of the work to be done to guide everybody’s contribution towards the desired outcome. This understanding will typically include [1] a vision for what the end product should look like from a user as well as from a technical perspective, the work strategy, and a schedule with dates for key events such as conferences, press announcements, for when major product capabilities must come together, and target metrics such as performance, scale, or participation, must be reached. The work strategy together with the key dates constitutes the project’s high level or strategic plan. Without such a plan, project members struggle with what to do next and stakeholders with what to expect, when. Cohn [2], for example, suggests the use of a release plan, without which teams move endlessly from one iteration to the next; Cockburn [3], a coarse-grained project plan, possibly created from a project map or a set of stories and releases to make sure the project is delivering suitable business value for suitable expense in a suitable time period; Highsmith [4], a Speculate Phase, in which a capability and/or feature-based release plan to deliver on the vision is developed as well as a wave (or milestone) plan spanning several iterations used as major synchronization and integration points; and the Scaled Agile Framework [5] [6], a Program Increment Planning, in which all teams – and wherever possible, all team members – attend PI Planning, where they plan and commit to a set of PI objectives together. They work with a common vision and Roadmap, and they collaborate on ways to achieve the objectives.
What all these approaches have in common, is that the proposed plans are collaboratively formulated by the team, not in terms of the tasks to be performed, but in terms of the outcomes the project must deliver, e.g. a basic version of the app is released, and the relevant states the project must go through on its way to achieve its objectives, e.g. the website information architecture is approved, a necessary piece of hardware is made available to the project, and so forth. In other words, the plan outlines the chosen strategy but does not dictate the myriad of tasks that ought to be executed to realize it, which will be decided as work progresses. As outcomes and relevant states synthetize the results of the, usually many, tasks necessary to produce or reach them, there will be fewer of them than tasks, making milestone plans more robust, easier to produce and communicate than traditional activity based plans.
The Milestone Driven Agile Execution (MDAX) [7] described in this paper, see Figure 1, is a hybrid software management framework [8] [9], where the empirical process control and the just‑in‑time planning of tasks advocated by agile methods are retained, but the prioritization of the backlog is done according to a milestone plan [10] [11], instead of the biweekly or monthly reactive concerns of the product owner or the development team. Selecting work items from the backlog according to a plan adds visibility, predictability, and structure to the work while preserving the adaptive advantages of agile development. MDAX is method agnostic in the sense that the development approach, much like an app running in a Java Virtual Machine, is not encoded in its mechanics, but rather in the plan that drives it.
MDAX has three advantages over other methods. First, the above-mentioned method independence, which allows those adopting MDAX to choose the development approach that suits them best. Second, the explicit consideration of the team capacity and availability in the planning process that results in feasible sequences of work not only from a dependency perspective but also from a resource point of view. Third, a step by step process requiring explicit inputs and estimates, makes the process more traceable, teachable, and repeatable, as the reader will have the opportunity to appreciate.
| Figure 1. Milestone Driven Agile Execution. Adapted from [7] |
Since MDAX is basically a planning superstructure on top of Scrum, in what follows, we will focus on what is novel or unique about the approach, assuming the reader has a basic understanding of Scrum, which allows him or her to fill in the blanks in the cases where we have borrowed an established practice or concept from it. The rest of the paper is organized as follows: In the Milestone Plans section, we will introduce the concept of planning in terms of milestones instead of tasks. In the Work Package Schedules section will explain how to depict the workspaces in which, the yet to be defined tasks, associated with a milestone will be executed. In the MDAX Framework section, we will provide a detailed description of MDAX in terms of its roles, activities, meetings, and artifacts. In the Visual Milestone Planning section, we will explain the planning technique at the core of the MDAX approach. In the Milestone Planning Example, we will walk the reader through the entire planning process, and in the last section, Conclusion, we will provide a summary of the framework and its advantages.
