Had a Twitter conversation today about deadlines and how to remove the stigma of a deadline and replace it with a more Politically Correct term. Like most Twitter conversations there is a kernel of truth in there somewhere that sparks a thought that turns into a Blog post. This was one of those.
In our Software Intensive System of Systems world, we are not 5 people sitting around the table with the customer building a warehouse management application for our privately help gadget making company. We work on large scale, mission critical systems - critical to the Enterprise or critical to the sovereign funding an Enterprise application, building a weapon, or accomplishing something that'll you'll read about in the paper. This is not to say those 5 developers sitting around the table with the Product Owner and the Scrum Master are not working on vitally important code. But Agile at Scale has a different paradigm than Agile at the Table.
One critical paradigm is the Product Roadmap and the resulting Release Plan. Release Plans come in two flavors.
- Cadence Release - when a fixed period ends, go with what is ready to go. Cadence Release paradigm, is a flow-based approach. A predictive rhythm defines when the release will be released. The variability of the development work is minimized through the planned cadence. What is variable is what is the in the Release. Focusing on meeting the needs of the customer or market is key to success in the Cadence approach. Releasing with less than the planned Capabilities reduces the ROI. These planned Capabilities are defined in the Product Roadmap. Success of the Cadence approach relies on:
- Schedule margin is needed to protect the deliverables.
- The wait time to receive the deliverables is predictable - fixed actually.
- Small batch sizes for work help control variances of the work that fits inside the cadence.
- Capabilities Release - a collection of needed business capabilities ready to go, when they are complete. This approach starts with a customer agreement that specifies what the product Capabilities must do in context to the release plan/ When those capabilities are ready they are released. The timing of the release is dependent on the completion of the set of capabilities.
Capability Releases have variable delivery dates for the capabilities - Cadence Releases have fixed delivery dates for the Capabilities
What's the Schedule For Getting the Products in the Product Release Plan?
Customers have a fiduciary obligation to have some sense of when the work they are paying for will be completed, how much it will cost and some assurance that what they are paying for will deliver the needed capabilities in exchange for that investment.
This is the basis of managerial finance and decision making in the presence of uncertainty - Microeconomics of Decision Making.
In both the Cadence and Capabilities Release Plan, the Product Roadmap speaks to what is planned to be released. The Release Plan is built during the Release Management process which plans, manages, and governs release of products resulting from the development effort. The owners of this governance process has the decision rights to determine what gets released.
The Capabilities are laid out Cadence Releases in the chart below. The Sprints containing the Stories that implement the Features that produce the Capabilities that occur on regular periods of performance.
The Product Roadmap that is connected to the Cadence Release Plan above, shows what Capabilities are produced in what order for the business to meet its goals
With the Product Backlog, the Product Roadmap, and the Cadence or Capabilities release plan, we've got all we need to define what Done looks like.
By Done it means what Capabilities are needed to fulfill the business case or accomplish the mission delivered by the project. It doesn't mean requirements, it doesn't mean tasks, it doesn't mean the details of the work. But if you don't know what Done looks like in units of measure meaningful to the decision makers the only other measure is we ran out of time and money. This has been shown through extensive research to be in the Top 5 of Root Causes of Project failure. The other 4 include Bad Estimates for the cost and schedule to reach Done.
And by the way, the term Done is NOT the Definition of Done in Scrum. That's a term used to state what processes have been applied to the work - a list of criteria which must be met before a product increment . It's a developers definition of Done. A critical activity for sure, but still far removed from the Mission Accomplished Definition of Done. Both are needed, both are Critical Success Factors, but at the business management level, developers DOD, is just the start of recognizing that the project has fulfilled the business case or accomplished the mission.
Done Done and Contrastive Reduplication
While the VP of Program Management at a nuclear weapons cleanup program, one of the Project Managers working for me introduced an idea. When we talked about being Done he chimed in and said, no Glen that's not the question. We need to know when we are Done Done. The use of the term Done Done Contrastive focus reduplication and is very useful in the Agile world, where there the notion of Definition of Done that is NOT based on a formal technical specification, but on customer approval that the results will deliver the needed Capabilities.