I'll Really Wish the Agile Thought Leaders Wouldn't Talk Like This

Got an invitation to a Webinar today on scaling Agile to larger teams. This is a very important topic in our domain, since we work software intensive programs that are distributed around the campus and across the country.

Here's the introduction...

Why do the Agile thought leader say this crap. There is no project on the planet that can define all the requirements up front. It's actually prohibited in the DoD 5000.02 procurement life cycle. Detailing everything to be done is utter nonsense. Design the complete architecture, are you f!@#'in nuts. No credible architect would do this. Parcel out work to component teams based on architecture and specification. Does this speaker actually work on complex integrated systems, say manned space flight, or ERP integration.

The bio says Howard worked in aerospace, he should know better than to talk this way. The 5000.02 and IMP/IMS paradigms have been in place long enough to stop saying waterfall. I know some commercial places do this, but they are out of touch with reality. This red herring approach is not only annoying, it does a disservice to those working on complex software systems.

Doctor, doctor, it hurts when I do this, than stop doing that you idiot

Ok enough, how about some rational concepts about scaling. What Howard describes in his paper is similar to the iterative and incremental procurement life cycle of DoD systems.We always start with capabilties, not requirements, no details, not architecture. The agile thought leaders might be well served to take a look at this Capabilities Based Planning paradigm.

• The capabilities of the resulting system are defined in Measures of Effectiveness (MoE) from the users point of view. What accomplishments are needed for the system? These capabilities are immutable unless the customer makes a change. For example the capability of processing claims transactions at $0.07 each instead of the current $0.11 each would be a Measure of Effectiveness.
  
• The Capabilities then need some assessment before we start. Since I assume we are spending other peoples money, these people probably want to know what DONE looks like when we arrive there in terms that are meaningful to them.
  
  • Define Capabilities as Operational Concepts
    • Partition system capabilities into classes of service within operational scenarios.
    • Connect the capabilities to system requirements using some visual modeling notation.
    • Define Measures of Effectiveness (MoE) and Measures of Performance (MoP).
    • Define the delivery schedule for each measure of performance and effectiveness.
  • Define Capabilities with Scenarios or Use Cases
    • Define scenarios for each system capability.
    • Connect these scenarios to a Value Stream Map of the increasing maturity of the program.
    • Assess value flow through the map for each needed capability.
    • Identify capability mismatches and make corrections to improve overall value flow.
  • Assess Needs, Costs, and Risks of the Capability Simultaneously
    • Assign costs to each system element using a value flow model.
    • Assure risk, probabilistic cost and benefit performance attributes are defined.
    • Use cost, schedule and technical performance probabilistic models to forecast potential risks to program performance.
  • Define Explicit, Balanced, & Feasible Alternatives
    • Make tradeoffs that connect cost, schedule, and technical performance in a single location that compares the tradeoffs and their impacts.
    • Use Measures of Effectiveness (MoE) and Measures of Performance (MoP) for these alternative tradeoffs.

The level of detail and commitment for these process varies depending on the domain. It may be some of these are not appropriate for the problem at hand. But you do need to ask if this is the case, before discarding them.

With these capabilties defined to some level of fidelity, the development teams can start to apply good agile processes.

• What do the releasse cycles look like? What in them
• If we have Epics what do they contain?
• What's our estimate for our capacity for work? Meaning what can we produce as a function of time and money for the customerto fulfill the needed capabilities?

These questions get answered in a Value Stream Map that describes how the software system is going to evolve over time, what capabilities the customer is going to receive as a function and time and then the customer can assign the Business Value to that capability.

Here's a picture of a real project doing that.

With this Program Architecure the system architecture, the teams allocated to producing the capabilities, and the defined Business Value can all be used to start developing the Use Cases, Stories, Operational Concepts and any other things youthink you need to execute a Scrum process.

In exactly the way Howard describes it in the picture titled Think Feature Partitions, not Components.

But notice the process step above in the first Bullet Define Capabilities as Operational Concepts and then the bullet Partion system capabilities into classes of service within operational scanarios. Well that's standard DoDS 5000.02 Systems Engineering.

What Howard is describing - and hopefully not taking credit as an orginal idea - is mandated DoD Systems Engineering. It's just good program management practice.

Once you get into the article good stuff starts to flow, but those Red Herrings in the tag line a turn off for us in the world of complex systems development and intergation of software intensive products and services.

But there are some Gaps in Howard's Picture

• Perform Integration - really. What are the protocols for this integration. Where was it defined what the built to specification is these disparate parts that will now be integrated. This is called architecture. In the space business it's call Interface Control Documents (ICD) and that is the role of the Systems Engineer
• All that joint sprint retrospective is nice stuff, but where is the corrective actions needed to avoid all the fixes. In complex integration projects we work, there is another team - a parallel team - who's only job is to facilitate all the integration planning and test - this is called Integrated Test and Evaluation. They focus on making sure all those initegrated parts meet the needed capabilities before we get too far down the road.

The critical understanding here - or missing understanding - is that Software development in large complex projects is NOT the repalcement for Program Management and Systems Engineering.

If all your participants are sitting in the same room with the customer, then those processes are implicit in the air. Once you move away from the single face-to-face team you muust have wrapper processes to keep everyone moving in the same direction.

If you look at the Winston Royce Waterfall Paper, circa 1973, you'll see feedback loops for all the process steps. The Red Herring of waterfall is based on a false understanding.

H. L. Mencken: “For every complex problem there is a solution that is simple, neat and wrong.”