PMBOK, RUP, XP, SCRUM, Kanban or Do Whatever/Nothing

Firstly, this writing is a result of Kevin Thompson's LinkedIn Discussion on "Kanban versus Scrum". He advised me to do a blog so I added it as a topic. Maybe we can have a Cafe Conversation on this. It stems from a comment I posted inspired from Henrik Kniberg's brilliant document on http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf

I particularly liked Henrik's diagram showing the RUP, XP, SCRUM, Kanban and Do Whatever from "Prescriptive" to "Adaptive" comparing the steps involved in each approach in terms of software development and project process perspective. So I added the Project Management Body of Knowledge (PMBOK) framework from the Project Management Institute (PMI) as a reference. It consists of a matrix of 5 process groups and 12 knowledge areas in which there are 59 processes (as of 2004, now in its 4th edition with changes).

I've put my comment (as posted) into a table format below comparing PMBOK, RUP, XP, SCRUM and Kanban ...

Program/Project Management Intensive	PMBOK and specifically portfolio management	for multiple projects in a program spanning business units and operations such as radical business process changes over a period of time.
Software Architecture Intensive	RUP, controlled iteration	for projects over a longer period, establishing new platforms and assets in a complex or hybrid environment such as EA and SOA initiatives.
Software Engineering Intensive	XP, Values, Principles, Practice for SE Teams	for products that are software engineering and test intensive with lots of interdependencies, example object orientated software components as libraries or engines used to deliver and support functional work.
Product Management Intensive	SCRUM, Time-box, functional/feature focus	for establishing, evolving and maturing assets with good platform foundations and tools where focus is on the functional product, for example web 2.0 technologies with mature back end infrastructure.
Workflow Intensive	Kanban, Workflows, application maintenance and configuration management	for higher levels of automation, administration and managed change for configurable processes.

It is not simply about waterfall versus iterative life cycles. Also not just about prescriptive versus adaptive as this can be associated with the way the enterprise and teams approach trade-off decisions. It has to do with the nature of the project, organization, scope and scale. Bureaucracy versus agile is also a factor in terms of center of control, hence the balance also between central, federated and autonomous controls.

More About Nothing or Do Whatever

Indulge me for a moment as I explore the "Nothing" option. It does not necessarily mean "nothing" or a less interventionist approach. One thing about making a strategic, political, business or technical decision involving a trade-off is to visualize a series of events and to first contemplate what would happen if you simply did nothing (let nature take its course). Is there a "natural" process of software development? Just as everything has an architecture whether or not it is explicitly defined, there must be a pattern for a social or human organizational endeavor or pre-occupation - which is what software development is ultimately about. Software development processes can be automated but ultimately it is about people. And people have a natural way of working - a natural enterprise process.

In comparing software architecture with building architecture history, I've noticed a pattern in the story of building architecture that demonstrates a pattern of natural social pre-occupation. Over a period of a few thousand years of civilization, our social pre-occupation has evolved in a way that can be articulated across 4 phases.

We initiated architecture by building naturally and organically, using patterns from nature or our environment and surrounds. Nature was our first reference or model of quality - "what is beautiful" or "what is good". Through the classical period which I think of as a more advanced learning period, we started to discover qualities of raw materials. This coincided with urbanization and in dealing with limited space, we turned to mathematics and geometry. Over time our sense of quality, standards, aesthetics or beauty became defined through symmetry. A study of artifacts and in particular the contrast between African art and crafts with other parts of the world and western civilization over the years demonstrates the difference in systems thinking.

The industrial and post industrial period was an intensive period focused on the production process of construction and manufacturing. This heralded the era of machines and modernism was born from the social impact of trying to balance life between man and machine. But over the last century, we have become aware of the dangers and impact to our natural environment. We have reviewed our own social belief systems in the western world and how we have based our beliefs on science from absolute morality and Newton's law to relativism and Einstein's theory of relativity. Postmodernism is an era of openness and transformation.

Interestingly, this process that has taken thousands or years with phases spanning hundreds of years is similar to the Rational Unified Process (RUP) 4 phases of Initiation, Elaboration, Construction and Transformation. In software development projects, you may see this pattern happening in a matter of months and over weeks. A small team initiates a project and develops organically, learning from the business environment. As they decompose the system, they develop a better understanding of the layers and sub systems of the architecture and design. But as the timelines loom towards the quarter or half way mark, management concerns begin and the process seems chaotic and unmanaged. More intensive construction and processes are put in place. More resources and a factory is carved out of the initial design work. If all goes well, there is a transition towards realization and to produce the production release.

While I believe that smaller iterations and agile approaches such as agile and SCRUM can influence the sub phases and iterative cycles, it seems more natural that overall a software intensive system takes a period of time to mature irrespective of the approach. There may be many ways to abstract this period and to make it more successful dependent on whether the meaning of "success" is based on financial/budgetary constraints, quality, time or other indicators and metrics. But there does seem to be a "natural" process that takes place.

It will take more research but I would also like to explore this association with natural patterns. Specifically, I am thinking of fractals which you can find extensive material on as well as on the topic of Chaos Theory. A Fractal is "a rough or fragmented geometric shape that can be split into parts, each of which is (at least approximately) a reduced-size copy of the whole," from the "The Fractal Geometry of Nature" (Mandelbrot, 1982). Also consider "Fractals: The Patterns of Chaos" by John Briggs, 1994.