Posts Tagged ‘agile’

How to address project complexity

5 April, 2012

In an earlier blog I wrote on complexity in project management and the Cynefin© model.
Target of this blog is to deepen the understanding in applying Cynefin©–based approaches to complex projects.

My appliance of Cynefin© is pragmatic. As I am not a theorist, I might get things wrong, as long as it works for projects.

A problem is either simple, complicated, complex or chaotic. A fifth type is disorder, which stands for such problems of which we can’t tell in what domain the problem belongs. In this blog I don’t address disorder problems.

The figure below is a graphic representation of the Cynefin© model from Wikipedia.

Simple problems are characterized by a known and well established cause-effect. Don’t waste any time, just plan de corrective action as you know it’s outcome.
E.g. if a team member lacks experience in a specific task, you send him to a course or training, or assign an on-the-job coach.

When developing simple software functionality, any development type will do (e.g. waterfall or iterative).

Complicated problems cannot be solved in the same manner as simple problems. For this an expert or team of experts analyze the problem to provide a solution. A typical complicated problem is how to structure known data in a database or set up a project in a stable problem domain. The project knows its stakeholders. Once the set of requirements are defined they are more or less stable. Project, organization and customer are confident in a positive result.

Regarding software functionality, also complicated problems may be addressed by any development type. Although here the risk for change and (upfront) unknown additional problems, might call for a iterative based development. Iterative based development enables emerging functionality, thus reducing late and fundamental changes in design and code.

When projects face complexity as well as many and largely unknown and varying requirements, both customer and organization are faced with a big uncertainty and risk regarding the outcome of the project. The high level work breakdown structure is largely based on expected work to be done. Estimations on effort, resources and needed time to determine project costs is at this point a major guessing game.

Typical for these large projects is that only at the end of the project, both project, customer and organization are able to explain how and why the project evolved as it did. Project outcome emerged from running the project. Prediction up front was not possible.

These projects are typically located in the complex domain with a probe-sense-respond approach.  In practice this means that at project outset, the objective is provided together with the why. Then the project set’s out to identify the major business value and starts working on these.

In order to identify as much needs, wishes and constraints as possible a narrative approach can be applied. In this initial narrative phase the project sets up a website where all stakeholders are invited to share their stories. The stories are provided a title and provided additional meaning (or signifying). Note that up front it is not known how many narratives or requirements are necessary. This is only know in retrospect.

The stories form the basis on which the project defines a detailed set of requirements. Because in these types of projects many requirements emerge only during project execution, these basic set of stories are continuously revisited at regular intervals.

In software development typical iterative approaches with high level of stakeholder involvement is used for these types of projects. It becomes directly very clear that both on the stakeholders side as well as on the organizational side, embracing slow-growing certainty and emerging understanding of project deliverables, is critical for success.

In the complex domain project outcome emerges from project execution. The problem domain is known and understood. Complexity is based on the fact that at the outset, not all needs, wishes and constraints are known. Even stronger, perhaps not all stakeholders are at that point known.

Projects in the chaotic domain are projects in an unknown uncharted domain. There not yet any experts to tell the project what is the best approach. So the defined approached is act-sense-respond. Just start working in any direction, ensure the involved cost, time and risks are limited. At regular intervals the result is evaluated. Positive outcomes are strengthened or continued. Negative results are stopped.
Slow but certain the project learns and builds expertise. Both customer and organization support and learn with the project.

For both the customer and organization, the challenge is how to fund these types of projects. I will get back later in this aspect. I’ll also address the use of narrative in requirements definition in a later blog.

Warning. As in all models it is important not to follow the model but to understand it. Applicability works as long as it works for you.


How to deal with complexity before it kills your project

29 March, 2012

We live in an unpredictable world. Our relationships (family, friends, society), our products and organizational structures are complex. This complexity is ignored by most of us. On every level in our lives we ignore this complexity and act as if all our problems are simple.
On the same playing field we manage most of our projects as if they act in a fixed, stable environment. But every project manager knows that at project start most of the requirements are unclear, our (fixed) budget is wrong. No wonder project members and customers are frustrated and our project managers burned down!
I had my fair share of contribution to this situation. As a CMMI expert I told organizations and project managers how they were expected to run projects. Based on the knowledge of today, I sincerely apologize.

Typical projects deal with dozens, if not hundreds of stakeholders. Each of whom has personal-, team-, organizational targets, (limiting and changing) convictions, (hidden) agenda’s, political agenda’s etc. You’ll get the picture on how growling difficult it is for any project manager to successfully deliver a project.
To worsen things, projects (and organizations) are managed as if people, like machines, are capable of programmable repeatable executing intelligent tasks.
The solution then is to treat projects as complex systems. For this we need language and solutions capable dealing with complex problems.

The solution to handle complexity and uncertainty, is to recognize the solution method  for the problem at hand. For this reason the Cynefin© model is helpful. Cynefin© describes 4 domains to categorize problems: simple, complicated, complex and chaotic. Depending in which domain your problem situates, it provides mechanisms to deal with the problem.
In the simple domain has a clear relationship between cause and effect. The problem is addressed by sensing the problem (I can’t read), categorize (it is dark) and respond (switch on the light)
Problems in the complicated domain require some form of investigation. Typically you would hire or go to an expert to get it fixed. This is done by sensing (my arm hurts) analyze (doctor identifies a broken arm) and response (applies a plaster bandage).
In a complex environment (covering most of the project management problems) the relationship between cause and effect is not known up front. It can only be determined afterwards. Therefore the approach here is to react by means of probe (try a small subset of requirements), sense (let the customer evaluate), response (redo if not ok, else continue with next subset).
The chaotic domain is not a domain where good or best practices work. Here acting is done (stop the traffic) sensing applied (2 cars, 1 truck, 5 injured) followed by response (you call for more support, you do traffic control, you attend to the wounded).

Scrum in its core is essential an approach for complex problems. It is time-framed method in which a team addresses a subset of the total customer requests. At the end of each sprint the customer evaluates the delivered part of the solution. It applies the probe, sense and response approach from the Cynefin© model.
Introduction of scrum on project level only, without appliance of agile principles in other areas (e.g. product management, portfolio management), the positive effects of scrum will soon vaporize.

Software development and project management
Joseph Pelrine explains in his paper “on understanding software agility” 1 that most software development problems are situated in the complicated domain, whereas project management problems are mostly situated in the complex or chaotic domain.
This further supports the above statement that organizations need to apply lean principles on management then only on software development.

deal with complexity
In a next blog I’ll get more practical and discuss methods to support an agile approach in software development.
For more information about applying Cynefin based tools and methods I refer to TOP innosense. TOP innosense is a network partner of Cognitive Edge in The Netherlands.

1) On Understanding Software Agility—A Social Complexity Point Of View E:CO Issue Vol. 13 Nos. 1-2 2011 pp. 26-37