How to create flow.

Flow is the new buzz. Each of us knows exactly what flow is. And how it feels. It feels great! You probably have even experienced it yourself. Great!

But flow in relation with work?  That is something else. It needs planning,  and changing work habits.

But we can create flow in our work environment. We are able to let work items or information flow through our work processes. Just look at the car manufactures. Their assembly lines are a perfect example of flow. But it took them many years and hard work.

The good news is that we can also implement flow in creative work places. Whether we create fancy apps or provide services. In HR departments, DevOps teams, back office, marketing teams, they all are able to create flow in their delivery process

Below I explain how you can start to implement flow.

Visualize your system to identify your bottleneck

1. 1. Identify Bottlenecks/constraints.
      • Draw a value stream map (VSM) to  visualize your system.
      • The VSM creates a common language to engage your stakeholders in your endeavor.
      • The value stream shows you the constraints. Probably you already knew the constrain (or had a good guess). But it is like handling risks, once they have been documented, they become somehow more real. This is also true for constraints.
        • Also good to realize is that you handle constraints with care. Even with more care then porcelain. It involves people. and the tricky thing is that people who are part of the constraint, became the constraint due to the system. Not of what they did or did not do!

2. Eliminate constraints (not the people!)
   1. Exploit the constraint.
      • Let the constraint only work on the flow-impeding work.
      • Reduce the amount of incoming work using WIP limits to the level that the constraint is able to chew.
   2. Increase the constraint capacity.
   3. Find the next constraint.
3. Ability to manage stakeholders that impact the constraint.
   1. The demand of work is defined outside your responsibility level. So in order to balance the demand with the available capacity, takes some diplomacy and persistence.
   2. Further downstream stakeholders are in need of your work items. They will claim your capacity is not fully used.
   3. Invite your stakeholders to some flow experience
      • Involving your stakeholders in a short Flow simulation workshop, combined with theoretical explanation on queuing theory may just do the trick to at least allow you to do an experiment with manage the work through WIP limts and other queuing theory techniques. (The Okaloa Flowlab simulations offer a range of different simulations that address all aspects of flow).

Some additional advice.

Start with flow simulations with some key stakeholders. They first need to understand the basic concepts of flow, queuing theory and WIP limits. This also let them experience the impact of WIP limits on the speed and reliability of their delivery requests.

On team level  create a stable input of work. Ensure that the teams grow into a stable delivery cadence. Use the team simulations to allow the team to experiment and experience flow in their own environment. You can use the actual work environment of a sprint to experiment with reducing WIP and allow the team to  become more stable and predictable in their  deliveries.

Next step is to let multiple teams that work to create flow of their combined teams. Run the cross team simulation as a start to have teams and product management experience and experiment addressing aligning capacity differences to a smooth delivery cadence.

Upstream, product management  (program or value stream level) implements a Kanban system that adheres to the same principles of flow as on team level. But here is one additional focus point.

Internal product management use WIP limits to effectively deliver a constant flow of work requests for the downstream teams.

From the perspective of the downstream teams product management takes care they have at all times sufficient work requests (options) available. This ensures that product management is never overstressed in producing sufficient work for the downstream delivery teams (quality, instable workloads up- and downstream). For the downstream  teams this means they have at all times sufficient work on their incoming backlog.  They are able to maintain a stable cadence.

For more information on  simulations  look at the available workshops in Europe on Okaloa. On May 19^th we offer a public workshop  on the Okaloa Flowlab simulations in which we  specifically address implementing Flow or Kanban systems in SAFe environments and other scaling approaches.

1-PO: Taking care of Scrum foundations; enabling successful scaling

to implement Scrum should be simple and straightforward. A small set of simple rules. It should be as easy as brushing your teeth. Unfortunately reality shows that most Agile implementations deviate from the basic rule set.

Deviation of the basic set of rules may lead to less effective scrum teams, frustrated management and misunderstood PO’s. IT also significantly hinders scaling Agile initiatives.

Initially I planned to write one blog on this topic. However, I soon realized there is (unfortunately) sufficient material for several blogs. So it became a series of blogs.

I considered using <she> in stead of <he>. But as I focus on topics that are not well implemented, I decided to use the <he> format.

The problems, and added advice how to overcome the problems, are based on the Agile values: Openness, Courage, Respect, Commitment and Focus.

In the blogs Scrum roles, ceremonies and artifacts will be addressed. The first 3 focuses on the Scrum roles. This first blog discusses topics of the Product Owner, the PO.

Typical problems related to the Product Owner:

• The PO is the hierarchical manager of SM and/or DEV team
• Each scrum team has one PO
• The PO is a technical expert on topics that the team works on
• The PO does not understand or values the Lean and Agile principles
• The PO is not ROI responsible of the work he assigns to the team
• The PO is ‘encapsulated’ in a classical Command & Control organization

The PO is the hierarchical manager of SM and/or DEV team
The organization hires team members based on their skills and expertise. They hire them because they believe they will create a winning team. So hiring them shows respect to the person. It takes courage from the organization to let go of old habits and let the group of highly skilled people grow into an awesome and high performance team.
The PO should be the expert in understanding customer needs and market developments. He is able to translate that to demands that the team understands.
When the PO wrongly focuses on team and individual team performance he deviates from his primary role and goal and that is focusing delivering great value to the end customers. Also, the team members will not be able to grow into a great self-organizing team. In stead they will become more and more static, not taking any responsibility and commitment on the work they deliver.

Each scrum team has one PO
If the PO is linked to only one team he typically has ‘too much time’ to deal with technical stuff. Work that the organization hired the team to do. It hinders the PO to focus on his ROI responsibility and reduces the respect he has to have for the team.

The PO is a technical expert on topics that the team works on
The above problem is worsened when the PO (and he typically is) is also the subject matter expert. In this case he will be more involved in the decision-making and development process of the team. He therefore shows little respect. It again limits the learning abilities of the team.

The PO does not understand or values the Lean and Agile principles
A classic problem. A manager was assigned the PO-role, but he does not understand or believes in the Agile way of working. This is equal to entering a formula one race with a regular street car. The Agile transformation dies before it even started.

The PO is not ROI responsible of the work he assigns to the team
When the PO is not able to take decisions on the spot in any meeting, he looses respect. He will not show the courage that is needed for the PO role. The PO will not be able focus on the content and bring openness to the work. IT will lead to additional hand-over (of information) delays in the decision-making process and a unmotivated PO and scrum team. Which leads to a less effective Agile implementation. T

The PO is ‘encapsulated’ in a classical Command & Control organization
Another classic challenge. The success of any Agile transformation initiative is limited by the organizational boundaries it is implemented in. Classic problems: Business remains in their ivory towers, part of the development life cycle is outsourced to other companies, often in other cultures and parts of the world, the Scrum reports (Daily scrum and e.g. burndown chart) are not accepted in the organizational reporting mechanisms.
In short, the organization does not accept the team’s openness using scrum mechanisms, limits team to be courage, does not show respect to the PO and or SM as they have to spend additional time on ‘made-up-report-metrics’, thus not enabling hem to focus on their actual work.

Advice to overcome the challenges mentioned:

1. The PO of a Scrum team preferable does not come from IT management but from e.g. the Business product management. The PO shows respect for the skills and focus of the scrum team. This significantly increases team effectiveness and courage to learn and increase effectiveness. The team then is able to focus on their work in stead of struggling the their PO.
2. The PO, by focusing on the market and ROI aspects, benefits from being the PO for multiple teams as it reduces hand-over and alignment between multiple POs.
3. Ensure that the PO is trained. Preferable provide him for a few sprints with a coach that joins him in day-to-day proceedings. It enables a fast and short learning curve. It also provides the PO to make errors (courage) and using Inspect and Adapt sessions with the coach quickly recover from any mistakes.
   Experiences in multiple companies have shown that the initial costs of an external coach by far is cheaper than the correcting ingrained wrong Agile approach that does not bring the yielded benefits.
4. If the present PO is the SME, consider to make him a team member building competences of the other team members.
5. Let the team earn his respect by focusing on delivering committed work, whilst during the sprint be open on progress and status.
6. The IT Line manager becomes then the servant leader for the team. Ensuring that the individual team members learn to take on personal leadership and grown into a highly focused and respected professional and human being. As IT Line manager he also supports the ScrumMaster creating a technical Agile development environment.
7. As last point. The responsible management team of the Agile transition must work on a strategic plan to spread the Agile transition. The sponsor higher in the organization should be used to trigger other departments. It helps to hire external experts to assist in this process. Eternal help avoid that you set up to departments against each other. The external help comes without emotional history. He also brings in experiences from other companies.
8. Review existing suppliers SLA’s to ensure they align with the goals and values of the Agile work methods.

Enjoy reading, more to follow in the following week(s)

Arno

Complex project management

The core of complex project management is the unpredictable part of the work. Each project manager understands that part of the success depends on aspects on which he or she has no control or influence on. In this blog I show how unpredictable project outcomes can be managed successfully.

Types of work
All project work can be decomposed into 2 types or domains: ordered or dis-ordered domain.

Work in the ordered domain is either evident or complicated. Complicated work needs prior analysis (by an expert). This leads to a solution approach which can be estimated, assigned and implemented. Independent on which expert the approach more or less is the same, as is the outcome. Examples are a broken leg or a car that does not want to start.
Evident work needs no prior analysis and can be directly estimated and planned. Examples are out-of-paper signal on a printer, or a flooding bath.

Note there are no strict boundaries between work types. Further decomposing work in smaller parts, the smaller parts may fall into other domains. Also, what one considers an evident task, may be complicated for someone else.

For ordered work the project manager uses classical project management methods and tools.

Dis-order domains
Chaotic and complex work belong to the dis-order domain. The difference with the ordered domain is based on causality. For evident work, the relationship between cause and effect is evident for all to see. An expert is needed to determine the (fixed) and existing causality between cause and effect.

Dave Snowden: ‘If the system is chaotic/random then agent behavior is deterministic, which means I can use statistical instruments. If it’s constrained, then the constraint structure allows predictability/repeatability. Strong constraints produce linear causality; weaker constraints provide repeatability that may be non-linear. However the moment you get the phase shift into a coevolutionary relationship between agents and system then there is no repeatability except by accident. In that context there is no meaningful causality, and any causality is only retrospectively coherent.’

Complex work
Complex tasks do not have a prior causal relationship between cause and result. Causality can only be determined on hindsight. This means that for these tasks, pre-analysis and estimates are of little use. The project manager defines some possible alternatives, selects one (using gut feeling, experience, of just a wild guess) and implements these step by step, watching the effect of the implementation carefully. When the result is positive, the approach is further strengthened. When the result is negative the approach is stopped and it’s effects reduced or undone. Based on the new situation an other (new) alternative approach is chosen.

Important aspects in this process is managing expectations and creating an agile environment that support managing and steering multiple alternative solutions.

The question is how the project manager manages complex work and how this fits in the regular planning and communication activities.

Planning in an unpredictable environment
So how then do you actually plan complex work? The answer is using an agile approach. Planning thoroughly and with close monitoring of the actual results.

Planning complex activities means first of all understanding that the outcome can not be predicted using prior analysis. Some investigation will be done of course, but this is to investigate and plan for possible objectives and outcomes. Based on that, alternative approaches are defined. Each approach is defined in terms of actual activity, estimation and assignment, described positive output, described negative output and aligned actions to strengthen (on a positive result) of dampen (on a negative output).
In the case of a negative output a new analysis of the present state is conducted and an alternative approach is chosen. This is a continuous process that clearly has an agile nature.

It is clear that in complex project management communication and expectation management are key for success. All stakeholders must be aware of the complex and uncertain character of the work: they need to embrace uncertainty.

Complex project management terminology
Focus in complex project management, is even more then for regular project management, on establishing the work implemented and the result achieved is good or bad. This is a continuous focus as the environment (agents) the project works in is coevolved by the project and it’s surroundings. So each complex tasks creates a (unpredictable) possible change of the system

Weak signals
When an approach is chosen, up front it is not known whether this will bring the results that is planned for. Weak signals help to detect any success or failure as early in the process as possible. Effective weak signal detection is based on a wide and cooperative stakeholder network and automation.

Wisdom of the crowd
As mentioned under weak signals complex project management uses the knowledge and experiences of their complete stakeholder network. This provides the decision making process a solid basis.

Bias
One of the major threats in complex project management is bias. On the input side it can be the decision to communicate a signal yes or not or in what form. At the output the decision maker will also be biased and referring to prior experiences and convictions. For this we use methods which eliminate bias as much as possible. This focus on the generation of the signals as on the decision making process. Methods and tools support the possibility to challenge bias and incorporate alternative viewpoints.

Disintermediation
Continued on the bias, decision makers need to be able to base their decision on the raw meta data rather then on the (biased) information they receive in reports.

Safe-2-fail approaches
Each approach may lead to success or failure. In complex project management we need to experiment or probe continuous to see what works and what not. We want approaches to fail as we can learn from them what the impact is in our environment we co-create with our environment. Therefore we aim for safe-to-fail approaches rather than fail-safe approaches.

Parallel safe-2-fail approaches
To speed up the learning curve (for a positive or negative outcome) it is best if the project is able to implement parallel approaches.

In this blog I described how to perform solid complex project management. From my point of view complex project management lacks attention and acceptance in management community. At it’s core, unpredictability is something that is an integral part of our world not only in our private life but foremost in our professional life.

Arno Korpershoek
+31 650 828 718

Scaling Agile meets complexity

Scaling Agile meets complexity

In conversations with customers one item related to Scrum and SAFe regularly pops up: How do we scale up our Scrum initiative?

Their questions focuss on:

• communication between horizontal teams and vertical disciplines and responsibilities
• how to align horizontal teams
• how to integrate multiple aspects in complex feature development
• how to increase time to market, increase quality and agility to market responses, how to achieve the promised gains of Agile development.

Predictable & resilient programs

Too many efforts get lost in complexity or frustration.

“I wish we had known before, what we know now; we never would have started this project”

“Why don’t they listen to us?” asked the project manager himself about management

Many programs keep their focus regardless changes in the system around them

We live in a world that is dynamic and always in motion. That’s a fact. So, how can we know today, what will be the challenge of tomorrow? The answer is simple: we do not know, unless…

Starting a program is to achieve some goal that was defined yesterday. How do you manage a program that aims to achieve something that may or may not be changed while you do your utmost best to get there? How can you early recognize a changing goal that you targeted?

Organizations need to be able to apply a kind of rocket that is guided to it’s moving target by means of laser. Listen2Change offers this management guidance. We provide the laser beam that the decision maker transfers into an adjusted focus, based on new knowledge of the target and the system.

A program in a system influences the system and is impacted by unpredictable agents in that system and events outside that system.

We visualize the influences and resulting changes on regular basis (daily, weekly, ..). It enables weak signal detection to identify risks or opportunities.

For this we use short anecdotes from all stakeholders in the system. Each anacdote-teller adds predefined ‘tags’ or signifying data to their anecdote. The signification provides navigation through the hundreds of anecdotes. it unleashes understanding detailed changes and impact from the perspective of each participant.

The underlying assumption is that people exchange information via stories. The stories are triggered by open questions and gathered independent from each other.  The complete set of stories provide a true reflection of the  reality. As it is continuous it truly provides your laser beam towards a moving target.

The method provides any program or mission the means to start without a clear understanding of the final result. This result will emerge from the running program and its impact in the system.

Customer Sensor Networks

Agile software development has 2 major positive attributes: the short release cycle and the possibility to integrate release-feedback rapidly in the product backlog. In this blog Customer Sensor Networks (CSN) are explained as a mechanism to integrate the Agile software development life cycle with customer feedback effectively.

CSN enables insight in what functionally is needed or wanted. To understand customer needs can be a challenge. In many cases customers do not have any idea what is possible in terms of functionality.

What is possible is in the heads of the developers, architects., analysts or product managers. But what is technically possible is not always wanted or needed by the customers.

The short feedback loop with a short time to market, enables product management to ‘test’ how features are accepted by (parts of) the customer-base. Implementing CSN lets the organization understand effort- and cost-effectively what functionality customers are willing to pay for. It is a good idea to involve the marketing strategy in the development life cycle.

Which customers to select is based on their expertise or area of interest. A variety of customer-types increases the variety of feedback. Innovators will appreciate other aspects then customers in the early or late majority groups. Which profiles you select, will be based on the business and business objectives.

Figure 1: Customer Sensor Network implementation.

The CSN explained here is based on Sense Maker® software ofCognitive Edge.

The CSN uses an online collector website which pre-processed the information for the product owner and the DevOps teams. Pre-processing is done by the CSN and based on the information provided by the customers.

The Feedback analysis consists of functional evaluation and an emotional aspect. The functional aspects cover things like how features are used or what is missing. The emotional aspect lets product owner en DevOps team members understand what (missing) functionality does with customers. The emotional evaluation is important to understand and support marketing aspects of the product.

Techniques like private beta’s or feature flags enable teams to manipulate releases to different test- or customer groups.

Figure 1 also shows typical takt times in a CSN system. Takt time and wait time lets the DevOps team and product owner optimize flow and adjust overall throughput time with the expectations of the different test groups. This example shows a sprint of 3 weeks. The test period is set for 1 week. Then the feedback is evaluated 2 weeks after the DevOps team finished work. Depending on the expectations of the customer test groups, the waiting time for the customer groups to learn what the effect of their testing has been, might be too long.

Using customers in the development life cycle presents some challenges to the organization. Aspects to take into consideration are incentives and how they (in)formally integrate in the communication plans. Incentives may differ per customer type. For example, for innovator’s their name can be listed on the product website as contributors, or they are invited on some regular basis to the development site to discuss with the DevOps teams and product owners. The early and late majority groups can be given a free license of the product.

CSN provides an effective organizational and team learning mechanism. New idea’s can be tested rapidly and (cost-)effectively. CSN triggers a business approach to Agile development. Developers, maintenance people, product management and marketing all learn as a team what it is that makes their customers happy or dissatisfied.

Applying customer sensor networks (CSN) in Lean Startup and DevOp teams

The Lean Startup movement addresses the issue to match product functionality to market demand. For this a contextual external customer feedback loop needs to be implemented. A customer sensor network using SenseMaker® provides online, real-time and continuous contextual feedback, closing the feedback loop.

SenseMaker uses an online collector website that lets customers provide feedback by means of narratives. Each narrative gets a title. The customers also provide additional meaning to their narrative. The system categorizes feedback based on the meaning given by the customers. This avoids overhead during analysis for the organization. The SenseMaker analysis software supports the evaluation of the feedback. Enabling effective and short evaluation time. This feedback mechanism enables evaluation of large amounts of feedback from different customer or user groups.

The analysis software provides both quantitative and qualitative evaluation. The quantitative aspects provide insight if functionality acceptance level. The qualitative aspects provide deeper insight in innovation opportunities. For example alternative or unforeseen use of the functionality. On the other side of the same scale, the feedback points to a risk or threat. For example that the new functionality is not well accepted by early innovators.

Customer sensor networks integrate with Lean Startup pilot experiments and DevOps private beta’s. It also provides for DevOps implementation the needed internal and external feedback for development. The internal feedback from operations to development is useful in case when the DevOps consists of multiple team in different locations.

CSN makes it possible that for some types of development, product management joins DevOps teams to form ProDevOps. This really reduces overhead and transition costs. It enables a whole new approach to app development in a true Agile manner.

 

SenseMaker is a Cognitive Edge product linking micro-narratives with human sense-making to create advanced decision support, research and monitoring capability in both large and small organisations.

Cynefin en Kanban == niet planbaar met optimaal resultaat ==

Meer en meer worden Cynefin en Kanban met elkaar in verband gebracht. En dat is niet zo gek. Immers, beiden zijn een manier om organisaties effectiever te maken en om complexiteit in een ontwikkelomgeving te beheersen. In deze blog ga ik in op de gecombineerde kracht van beide. Gecombineerd geven zij een organisatie een niet-planbaar-optimaal resultaat.

De kern van Kanban is het inzicht krijgen in de capaciteit van waarde leveren aan de klant. De hele keten wordt hierbij betrokken. Door de deel-performantie van de verschillende stappen op elkaar af te stemmen, ontstaat een optimale doorstroming op organisatie niveau.

Dit inzicht en manier van werken vormt vervolgens het uitgangspunt voor continue verbeteringen en aanpassingen. Het (gevisualiseerde) inzicht bij alle betrokkenen geeft het continue verbeterproces een natuurlijk karakter.

Cynefin is een model dat 5 probleem domeinen definieert: simpel, gecompliceerd, complex, chaotisch en disorder. Ik verwijs naarhttp://en.wikipedia.org/wiki/Cynefin voor een meer gedetailleerde uitleg. (in de week van 3 februari is er een Cynefin/SenseMaking training in Amsterdam).

Proces verbeterprogramma’s of de implementatie van Lean/Kanban in een organisatie zijn beide typische voorbeelden van complexe problemen. Complex betekent dat er geen directe relatie bestaat tussen oorzaak-gevolg. Het resultaat is niet planbaar en is alleen terugkijkend verklaarbaar. Dit in tegenstelling tot een probleem in een gesloten systeem (gecompliceerd en simpel). Daar zijn oorzaak en gevolg door analyse of categorisering te voorspellen.

De Cynefin aanpak voor complexe problemen is door gebruik van de gecombineerde kennis van experts, inzicht te krijgen in mogelijke oplosrichtingen. Deze vormen de basis voor de volgende stap: safe-fail (niet fail-safe) probes. Door een continue en real-time feedback loop wordt de impact van elke probe zichtbaar. Succesvolle probes worden versterkt en uitgebreid. De niet succesvolle probes worden gestopt. In een zich ontvouwende werkelijkheid wordt een (niet gepland) optimaal resultaat bereikt.

De gecombineerde kracht zit in de opbouw van kennis over de capaciteit van de organisatie en het begrip van de mate van complexiteit van de taken (zowel in bouw als management). Het leiderschapsteam kan op basis van deze kennis en begrip de organisatie stimuleren tot continu leren en verbeteren. Het vormt de basis voor de strategie en de continue aanscherping van deze strategie.

How to avoid the Lean/Agile introduction blues

Introducing a new way of working fails dramatically in most cases. Why? Because we fail to understand that what works in one open system, does not automatically work in another open system.

We all remember moments when we started working in new company or department. We start to work the way we were used to, but learn quick that we need to adapt. We do this naturally and without thinking. In 2 weeks time our new way of working feels natural.

Perhaps a more ‘natural’ approach in an organizational environment works as effective in our personal environment. Unfortunately, our traditional introduction approach is still widely applied. This leads to the ’introduction-blues’.

 

When I visit companies introducing Lean/Agile techniques, I recognize the same ‘introduction-blues’ as when I supported companies introducing CMMI practices.

When introducing CMMI practices, the most common failure was the way in which the different practices were introduced without understanding the why of the practice, the impact of the practice into existing way of working and the connectivity of the practices with other ‘CMMI-practices’. Because of this, other existing processes were not aligned with the CMMI-related process improvements or CMMI-related process improvements on the same subject were introduced at several locations in different flavors, leaving users in distress.

Introducing CMMI-with-your-eyes-shut is not a successful strategy. The same holds for introduction of Lean/Agile/Scrum or any other new methodology in that manner.

To apply our personal approach into an organizational approach we use a continuous safe-2-fail approach in which we take small steps, learn and then take another step. The successful steps are enlarged, those that fail are changed or stopped.

But how do you now what works and what not? Which are the first steps? These safe-2-fail probes are supported using SenseMaker®. A busy MT is not able to listen continuously to all stakeholders in the system. Building an effective SenseMaker system is crucial. With this tool all stakeholders provide their feedback and signify their feedback. The feedback is generated by short narratives.

The tool provides for effective categorization of the feedback and visualization tools to create a helicopter overview on trends and theme’s. On the same time it enables the decision makers direct access to the narratives, giving them the necessary context to take appropriate measures.

The process steps: 1) bring stakeholders together in a workshop 2) use a SenseMaking method to analyze the present and identify possible next steps 3) construct a SenseMaker system 4) take the first steps and trigger feedback 5) collect & analyze feedback 6) define following next steps.

Using this system, any organization can effectively introduce any new methodology in a step-by-step, cost-effective manner, while keeping all stakeholders involved, happy and more willing to adapt.

How to deal with complexity before it kills your project

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 and can be solved by applying best or even good practices.

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 out!

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.

Projects
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 repeatably execute intelligent tasks.
The solution then is to treat projects as complex systems. For this we need language and solutions capable dealing with complex problems.

Cynefin©
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
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” 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 Listen2Change. Listen2Change is an affiliate partner of Cognitive Edge in The Netherlands.