|
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.
Back to Topics
|
