Releases and Deadlines in Agile

I 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 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 five people sitting around the Table with the customer building a?warehouse management application for our privately helped gadget-making company. We work on large-scale, mission-critical systems - critical to the Enterprise or the sovereign funding an Enterprise application, building a weapon, or accomplishing something you'll read about in the paper. This is not to say those five developers sitting around the Table with the Product Owner and the Scrum Master are not working on vitally important code. However, Agile at Scale has a paradigm different from 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. The Cadence Release paradigm is a?flow-based?approach. A predictive rhythm defines Releasee release will be?released. The variability of the development work is minimized through the?planned cadence. What is variable is what is thReleasee Release. Focusing on meeting the customer's or market's needs is critical 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. The success of the Cadence approach relies on the schedule margin, which is needed to protect the deliverables. The wait time to receive the deliverables is predictable - fixed. Small batch sizes for work help control variances of the work that?fits inside the cadence.
• Capabilities Release is a collection?of needed business capabilities that are ready to go when they are complete. This approach starts with a customer agreement that specifies what the product Capabilities must do in the context of the release plan. When those capabilities are?ready, they are released. The timinReleasee 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—the 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 releases the release of products resulting from the development effort. The owners of this?governance process have the right to decide what gets released.?

The Capabilities are laid out in Cadence Releases in the chart below. The Sprints contain the Stories that implement the Features that produce the Capabilities during regular performance periods.

The Product Roadmap connected to the Cadence Release Plan above shows what Capabilities are produced in order for the business to meet its goals.

With the Product Backlog, the Product Roadmap, and the Cadence or Capabilities release plan, we have everything 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 that must be met before a product increment.?It's a developer's definition of Done. It was a critical activity but must be removed from the Mission Accomplished Definition of Done. Both are necessary for success, 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 and Contrastive Reduplication

While I was 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 said,?"No, Glen, that's not the question. We need to?know when we are done." The term?"Done Done" is a Contrastive focus reduplication?that is beneficial in the Agile world, where the Definition of done is NOT based on a formal technical specification but on customer approval that the results will deliver?the needed Capabilities.