Here's how we write software for money, on a deadline, with a mandatory set of Capabilities and Features that implement those Capabilities.
This process flow has been applied in a wide range of technical and business domains. From enterprise IT programs to manned space flight avionics systems.
In all these domains, there are some core assumptions:
- We know what Done looks like in some form. Usually with a minimum set of Capabilities needed to accomplish the business and technical mission.
If you don't know what Done looks like in some unit of measure meaningful to the decision makers, you're on a Death March project
- The myth that it's in doing the work we discover the work, is just that a myth
- That only works when your project is de minimis - meaning no one cares if you're late, over budget, or they don't get what they need to run the business when yuo run out of time and money
- The development and even the emergence of Capabilities is held in the Product Roadmap. It's from this Roadmap that Features emerge
- The order of the Capabilities is the basis of the success of Scrum projects since when a Capability is ready for production, you have the choice to actually put it into production
- It may be that you need several Capabilities before going into production. For example, you probably need the capability to order materials and when you have that Capability you need the Capability to pay the invoices for materials. Both are needed for the procurement team to use the system. If you ordered and can't pay, the suppliers aren't going to let you order any more. If you can pay, but can't order, paying is of no value
If you have no needed Capabilities, then you can go live every time you have working software. But that usually means you have a de minimus application, where no one really cares what you are producing as long as it's something
- That Product Roadmap has a Release Plan showing what Capabilities are needed in what order to meet the business needs of those paying for your work.
- This Product Roadmap and Release plan are what drives the development of the software by pulling Features off the Product Backlog work in coming Sprints - if you're using Scrum
- The System Integration and User Acceptance testing are done with Kanban in this paradigm
- This disconnects the work of testing from the work of development
- Testing then does their work and any outcomes that produce re-work and new-work go back into the Product Backlog
- When the Feature and Stories that implement the Feature are ready for User Acceptance testing, they move to the Kanban Queue for UAT
Here are the details of the steps in the first picture
Estimating in this Process
The challenge for all agile development is how to estimate the work when there is a deadline and a budget to stay inside of.
The first step is to have some means for creating a Reference Class that can be used to size the highest level of the work. This usually means have someone or access to someone who has dome the type of work before.
When I hear we've never done this before, so we can't size the work. The answer to that is simple:
- Go find someone who has.
- Go look in databases for similar projects.
- Build a model of the Functions you're asking for and use Function Point Analysis to create a parametric estimate
In our current domain, the estimating process works like this
- The Product Owner makes a Rough Order of Magnitude estimate of the Feature's effort. This is easily done with Tee-Shirt sizes. That Feature is placed in the Product Backlog
- The PO team, along with the Development team, review those Tee-Shirt estimates using past performance to make sure the estimate makes sense
- The technical team then works with the Product Orders to convert those Tee-Shirt estimates into hours by decomposing any larger pieces of the Feature. That information is updated in the Feature.
- Stories are created for the Feature and those are estimated in Hours and placed in the Product Backlog
- When work starts, the Hour estimates for the Stories are updated with a Revised Estimate along with the Actual Work and a plugin for the agile tool keeps all this straight
- With the Revised Estimate and the Actuals to Date, a Phsyical Percent Complete can be generated
