The notion of self-directed development teams has a range of applicable domains. Much of the rancor around agile development these days is about how to apply the core principles of agile software development. Do we need estimates? What's the role of business process in the development life cycle? How are capabilities and requirements elicited? Who has what decision rights for what decisions? How can we made these decisions and what information is needed in order to make the decisions?
Guy Strelitz's post has got me thinking about the spectrum of the world called agile. Here's my take on his diagram. Working in a domain where we're spending other people's money, lots of other people's money, the Winging it approach is simply not accepted. The Kanban approach doesn't either because the inter-dependencies between the backlog items it tight, so picking the next thing off the blog log based on business value may not be possible, since some pre-condition may need to be fulfilled before a higher value item can be started. Softwarr development is not production in our domain. Kanban is a production flow management system, no matter how twisted the logic of the Kanban software advocates make it out to be.
Scrum is a powerful approach to emergent requirements. But only when those requirements are anchored to Needed Capabilities. Capabilities that all have to be in place for the system to be called ready for Go Live. Some more formality is needed as governance and regulatory paradigms are encountered.
Finally, we arrive at the Enterprise model of software development. The firm depends on the software system for revenue. PayPal depends on the system for revenue, but not in the way an insurance company does. Or a gas pipeline process control system does.
But at the same time, agile can contribute to not only increasing the probability of project success but also deal with the emerging requirements traceable to the need capabilities.
Process is King
So now to the point. In that agile enterprise paradigm, the mission critical aspects of the software system demand assurance that the released software is not only Fit for Purpose and it is Fit for Use. That is, the software does what it is supposed to do, in a way it is supposed to work.
One of the critically important processes of any enterprise software system is the Change Control (CC) and Release Management (RM) process. The software system is a corporate asset and must be treated as such. This asset is carried on the General Ledger as an asset. A capital investment, governed by the rules of accounting for capital assets. That's essentially the definition of enterprise.
In this enterprise paradigm, the control of these assets starts with CC and RM. Here's a high-level flow of how this corporate asset is managed. In this example, development occurs in the lower left. The CC and RM process is post development. This development business rhythm can be weekly, monthly, possibly even daily. But once the software is ready for release to production, this is a possible process.
The key here is the separation of concerns. The developers of enterprise software our not the approvers of the release of that software, nor are they the involved in the QA, UAT, and Performance Assessment of that software.
So this is the separation from the activities on the left of the top diagram to those on the right. When someone suggests a new idea, or has read a book about a new idea and wants to discuss it - ask where on the spectrum of the top diagram they work, where they think their idea would fit in.
In the End
Without first starting with a domain, context, framing assumptions around governance, established decision rights any suggested process has no home for being tested against reality.
