Mary Poppendieck has a post about lean software development describing a typical software development process - at least from her experience.
I'd like to describe how software is developed in domain I work.Mary's post, while informative is one of those domain and context free posts. What domain is being spoken of? SAP roll outs, avionics, process control, personnel management systems, procurement, real-time control in cars, aircraft, ships, refining, pulp and paper. Our 6 guys in the same room with their customer?
Our domain is embedded flight systems, the ground systems and support systems providing functional capabilities to support the "flying machine," and other mission critical applications and the business systems that go around them, because if you can't order parts, receive those parts pay subcontractors, and report to the government, building "flying machines" is not a viable business.
But more importantly, our domain is guided by several processes that direct address the issues spoken to in the post, WITHOUT having to install another process. In fact the many of the principle of Agile are embedded in a process that provides the Systems Engineering principles of complex integration of emerging requirements. The Emergent Design post has an example of this.
So Mary says...
Looking in from the outside...
- Our release cycle is usually six to nine months for a set of capabilities that can be applied to the problem at hand. The program is usually 2 to 5 years long for a full up set of capabilities. These capabilities can be things like "flying to Mars and landing safely," or "integrating new functionality into a combat helicopter for new weapons and navigation systems."
- Up front planning takes place during the proposal. The participants in the proposal are the engineering and technical staff for the technical section. Management, program controls, cost, schedule, and risk for their sections. Safety and Mission assurance for their sections.
- Estimates are built from the Statement of Objectives, Program Work Statement, or Concept of Operations. A flow down of the needed capabilities to deliverables provides visibility into what Done looks like for the program.
- But this Done is defined in incremental steps as well. This Integrated Master Plan / Integrated Master Schedule (IMP/IMS) method is mandated on government procurements. This paradigm defines the increasing maturity of the deliverables in terms of Significant Accomplishments, their Accomplishment Criteria, and the maturity assessment Program Events.
- Managers don't commit, engineers do. Managers don't write code, engineers do.
Here's the obvious errors in the approach described by Mary.
- All basis of estimate (BOE) are built bottom up, from past performance, statistical assessment of risk, and best engineering judgement.
- If you're on a project where the managers commit to the estimates, then it's simply BAD management, you get what you deserve.
- This approach is not credible, it's fails the test for all FAR procurement systems of having an External Independent Review (EIR) or Independent Cost Evaluation (ICE).
- It doesn't pass the smell test.
- The assumption that coding takes place without continuous integration and test also doesn't pass the smell test.
The solution is simple - Don't do this. You don't need a new process, just don't do stupid things on purpose.
Then the post says ...
Again from our domain of mission critical systems... Yes, code needs to be frozen. Other components, systems and subsystems are dependent on this code. Changing code base drives these external systems over the edge and thrashes the entire process of "systems engineering." In the System of Systems world - any non trivial project - management of the code base stability is a critical success factor. Domain and context are important here.
Now the next Red Herring. Continuous integration and test is part of every embedded system paradigm. It's part of CMMI Dev V1.3, it's part of DO-178B, it's part of any credible software development lifecycle. You don't have continuous integration and test, then you're project is in trouble.
No doing continuous integration and test is another prime example of doing stupid things on purpose.I know projects don't, but they're not credible. Yes say no to this practice. You don't neede agile to know this. It's just good project management. Constructors don't do this, landscapers don't do this, house painters don't do this (well, while building out house, they swapped the body and the trim colors without checking the first wall and they had to do the entire house all over again), and certainty anyone building software that controls things like money, fuel feeds, landing controls, has continuous integration and test.
On our NASA manned space flight programs estimates to complete are provided every two weeks. Working software on the full fidelity emulator of the space craft ae dropped every 6 to 12 weeks. This duration is dependent on hardware development.
The rest of the post has good things around feature management and regular Lean management. But why can't thought leaders look outside those teams doing really stupid things to see that all this discovery of how to build software has been done since the late 70's (1978 TRW Redondo Beach development cycle for TDRSS) for embedded control systems, the ground systems, and the launch control systems, and the supporting business systems?
For anyone looking to see how to manage complex emergent systems in the absence of all the agile hype, look to the work of Eberhardt Rechtin. Once you take out the anti-management rhetoric of some recent books and the personalization of the processes that is popular in the small independent team approaches, Rechtin's description of building systems provides credible guidance in many domains - iterative, incremental, emergent, reuse, refactoring, and embedded customers are common in mission critical defense and space systems.
I don't care if they take credit for what was done in 1978. But why repeat Bad Management processes as the starting point? So I've asked Mary what domain and context does 6 months to 1 year releases and does it on purpose?
