Posts Tagged ‘agile’

Effectief beheersen van transities door onzekerheid om te vormen tot kracht

1 July, 2017

Als ik om mij heen kijk, zie ik vele agile initiatieven. Iedereen in een agile transitie verkeert op enig moment in extase (ziet een mogelijke toekomst), verwachting (van een direct resultaat), of (veelel grote mate van) onzekerheid (“waar zijn wij/zij in hemelsnaam aan begonnen!”).

De transitie teams zijn zeer wel in staat om extase en verwachtingen te managen. Het omgaan en effectief gebruiken van onzekerheid is iets wat de meeste transitie teams (nog) niet beheersen.

In deze blog ga ik in op welke manier je onzekerheid tot kracht kunt omvormen.

Onzekerheid
Onzekerheid komt in vele gedaanten. Het is ook een belangrijke oorzaak waarom transities in meer of mindere mate falen. Het kost energie en tijd. Denk bv aan al die momenten waarop mensen met elkaar in gesprek gaan over de transitie en hun perceptie ervan. Deze gesprekken en eruit volgende ideeën en mentale modellen, frustreren en zorgen voor onrust en tegenwerking. De energie loopt bijna letterlijk weg.

De frustratie komt onder andere voort uit het feit dat (het lijkt) dat het transitie team de gevoelde impact van de transitie en de mentale gevolgen hiervan, niet lijkt te zien, niet lijkt te willen zien, of (mogelijk nog frustrerender) er niets aan te willen doen.

Het transitie team heeft ook veel onzekerheid. Immers, zij hebben een complexe organisatie, die zij op een juiste manier, anders willen gaan laten werken.

Er bestaan voor deze transities geen best practices. Voor iedere organisatie wordt succes bepaald door andere factoren. Geen organisatie is hetzelfde, heeft dezelfde processen en veeeeeel belangrijker, geen organisatie bestaat uit dezelfde mensen!

Dit heeft tot gevolg dat het transitie team wel verschillende mogelijke manieren van aanpak heeft, maar het niet in staat is op voorhand te bepalen, welke aanpak tot welk resultaat zal leiden.

Dus misschien ligt de grootste onzekerheid wel bij het transitie team. Simpel en alleen omdat iedereen wel verwacht dat wat zij doen, het (enige) juiste is.

Alhoewel het transitie team feitelijk zou moeten zeggen,

wij weten het ook niet, wij hopen met deze aanpak het beste resultaat te bereiken, maar zeker zijn we er niet van”, 

zeggen zij

Wij hebben goed nagedacht. Onze aanpak is de enige juiste. Als jullie je best doen en precies doen wat wij zeggen, komt alles goed”

Over onzekerheid gesproken!  Hopelijk lezen zij deze blog ook ….

Onderliggende problemen
Onduidelijk doel
In agile transities is het doel nogal vaag. Meer flow, meer responsiveness, De business gaat ook ‘scrummen’ zijn niet bepaald termen wat voor een ieder helder is wat dit in de praktijk betekent.

Geen vertrouwen in de transitie het het transitie team
Door het ontbreken van vertrouwen zal er weinig feedback zijn mbt de ingezette transitie. Hierdoor heeft het transitie team geen of onvoldoende mogelijkheid de ingezette transitie aan te passen en genomen besluiten zodanig te vormen naar de zich veranderende werkelijkheid op de ‘transitie-werkvloer’. Er dreigt dus een (gapend) gat tussen de transitie leidinggevenden en de mensen op de werkvloer.

Mentale modellen
Veelal werkt de organisatie die de verandering in gang zet al jaren op een min of meer succesvolle waterval aanpak. De hele organisatie is ingericht de falende aspecten van de waterval aanpak (veel her-werk; silo-vorming, zware governance teams, etc) voortvarend te lijf te gaan. Deze groepen worden met Agile aanpak deels overbodig, of gaan in de teams/projecten op. Ongeloof, onzekerheid en tegenwerking borrelt langzaam maar zeker op.

Heb ik nog een baan straks?
Doordat agile manier van werken vaak betekent dat er minder afdelingen en mensen nodig zijn voor betere kwaliteit en meer opleveringen, ontstaat vanzelf onrust. Heb ik straks nog een baan? en zo ja, hoe ziet mijn nieuwe rol er dan uit? Ga ik minder verdienen? Moet ik meer uren maken? Hoe en waar ga ik dan op worden afgerekend? Ben ik voldoende opgeleid?

Mijn management Agile? laat me niet lachen!
In een organisatie die groot is geworden met command en control structuren, en nu een Agile transitie start, is de vraag zeker gerechtvaardigd, of het huidige management de verandering wel aankan. Zijn zij in staat de agile mind te verinnerlijken. Zijn zij in staat verantwoordelijkheid en autoriteit die daarmee gepaard gaat lost te laten en naar lagere niveaus over te laten?

Omgaan met de onderliggende problemen
Door de mensen een kanaal te geven hun ideeën, ervaringen en bezorgdheden te uiten, pakken we hierboven beschreven onderliggende problemen aan. Door deze uitingen serieus te nemen en input te laten zijn voor de transitie aanpak, ontstaat vertrouwen in de transitie. Maar nog veel belangrijker is dat de mensen, zich gehoord voelen en daardoor zichzelf deel gaan laten uitmaken van de transitie.

Dit kanaal noem ik Oneteam.

De aspecten van het omvormen van de organisatie, het loslaten van oude patronen en het inslijten van nieuwe (agile gebaseerde) practices, laat ik in dit blog buiten beschouwing. Kern van het succes is de mensen die de transitie serieus te nemen. Deze mensen ervaren namelijk op dagelijkse basis het (onbedoelde) effect van ieder besluit.

Oneteam
Oneteam verzamelt ervaringen van mensen op een continue basis. Dit maakt dat wanneer je een idee hebt, of ergens last van hebt, je dit direct kunt delen. Het delen gebeurt door het vertellen/opschrijven van korte anekdotes. Wanneer blijkt dat het transitie team deze input, jouw input!, gebruikt om de transitie aan te passen, voel je je zekerder. Er ontstaat vertrouwen naar beide kanten. Er worden méér ervaringen van de werkvloer gedeeld, én de besluiten zijn constant in directe relatie met de feedback van eerdere besluiten. Er ontstaat een versterkende lus.

Door deze symbiose ontstaat een ware agile transitie. Door de constante Inspect & Adapt cycle groeit de organisatie naar constant nieuwe vormen. Iedere nieuwe vorm past net iets beter dan de vorige. De organisatie wordt lerend.

Oneteam opzet en resultaat
Oneteam bestaat in 2 vormen.

Richt je je eenmalig op een team, of een aantal teams, kun je volstaan met workshop(s).

In de workshop deelt het team ervaringen en ideeën. In een aantal vervolgstappen worden de persoonlijke ervaringen geanonimiseerd. Gedurende de stappen ontstaan thema’s waaraan acties worden gekoppeld. De acties worden in de transitie backlog geplaatst. doordat iedereen kan deelnemen is iedereen ook eigenaar van het resultaat en de acties.

Bij grote en langdurige transities is een tool effectiever. via een website en app kan iedereen in de transitie continu zijn of haar ervaringen en ideeën delen.

Zo ontstaat een rijke bron van relevante en continu veranderende beelden uit de transitie.

De feedback wordt óf door een separaat team óf in (grote) workshops geanalyseerd. Beide vormen maken het mogelijk gegevens vanuit verschillende perspectieven van betekenis te voorzien. Hiermee kan het transitie team bv bepalen welke welke impact bepaalde besluiten hebben. Voorbeelden van perspectieven: alle positieve anekdotes na een bepaalde datum door een bepaalde groep betrokkenen, of alle verbeter ideeën vanuit scrum teams. of alle negatieve feedback van externen. Doordat men de achterliggende anekdotes kan lezen, worden de analysis scherp en de vervolg acties pragmatisch en met een directe impact.

Succesvolle transities
Betekent dit dat met Oneteam iedere transitie succesvol wordt? Ik hoop van wel. Maar natuurlijk ligt het succes in de (verander)kracht van de organisatie, en in de competenties, daadkracht van de mensen in de transitie.

Wat Oneteam wel voor een transitie betekent:

  • een continue bron van rijke, relevante en betrouwbare informatie over de gang van zaken op de werkvloer
  • anonieme anekdotes, wat maakt dat mensen vrij zijn te delen wat zij willen. Ervaring leert dat deze anonimiteit nooit misbruikt wordt.
  • transparantie: van werkvloer naar het transitie team, en van transitie team naar de werkvloer
  • de mogelijkheid om mensen in een moeilijke, persoonlijke en onzekere tijd, hun gevoelens, ideeën en ervaringen op een zinnige manier te delen
  • onmisbare ondersteuning voor ieder transitie team
  • het voorkomen van ‘blind’ moeten navigeren tijdens transities
  • het uit kunnen voeren van experimenten; door de snelle en korte feedback lijnen, kan er kort op de bal worden gespeeld

Van onzekerheid tot kracht
Deze experimenten zijn in feite de kern en de manier waarop het transitie team onzekerheid omvormt tot kracht.

Agile betekent het onzekere omarmen en door middel van een aantal (liefst parallelle) experimenten, de organisatie snel te laten leren.

Flow in an Agile environment.

30 March, 2017

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.

In my previous blog I started with the above paragraph. It triggered questions on what Flow is? Trying to answer this question took too many words for a small reply. So I made a blog in which I describe what I mean with Flow.

Being in “the Flow” means that what I do in that moment of Flow goes ”effortless”, “smoothly” and in a continuous cadence.

When I talk about Flow in a team setting, there are two views:

  • The team is in a mood in which it “effortless” and “smoothly” produces results;
  • The work items run smoothly from left (input queue or Product backlog) to the right (output queue). There are no inventories that block the flow of work, and work does not flow backwards (upwards).

The view on work that flows upstream makes people realize the unnatural aspect of it. Work, like water, always flows downstream. If not, then the (natural) flow is ‘broken’ and waste is created: “effort to bring the water of work upstream”.

So flow in our work environment is the continuous movement of work items in the direction of the customer. Never moving away from the customer. In each step value is added to the work items. We only add value that makes the customer happy. If not we pollute the water, add baggage to the work items that makes the customer not happy, the maintenance more difficult and the change of defects greater.

Flow as well means that the effort for the workers is evenly distributed and not ‘batch-like’. The work steps are in balance. No step is overloaded and no step is starving.

Flow in a kanban system aims to reduce work staying in inventories, as this creates waterfalls. With a real danger of dam busts.

Inventory typically occurs when we hit a bottleneck or constraint. Opposite it means that we avoid waterfalls and inventory by taking away constraints.

the team becomes more stable and predictable in their  deliveries.

So, from whatever view you look at Flow, it is a powerful weapon making your team more fun and more resultful.

Giving customers their legitimate place in software development.

26 August, 2013

Being really lean means that only that functionality customers use (and are willing to pay for) is developed and released. That means being so agile, that trends and patterns in customer needs/wishes and problems are continuously understood and drive service/product development and delivery.

For this the ‘voice of the customer’ needs to be continuously monitored. The result of the listening is to be analyzed and integrated in the development life cycle (e.g. product backlogs).

As not all new functionality or innovations originate from customers, also the ‘voice of the internal-experts needs to be continuously monitored. This knowledge, experiences and ideas is integrated in the development life cycle as well.

In earlier blogs I wrote in Customer Sensor Networks. Being the same subject, it lacks the natural place in the present developments in agile software development methods. By lack of a better word I use in this blog the term CusDevCus which stands for Customer-Development-Customer. With Development I mean the complete development lifecycle including Marketing, Sales, Product Management, Development, Release and Operations, ect. I am open for any better term.

Core elements of CusDevCus are:

  1. Integrated customer feedback (or external expert feedback) into the development life cycle loop to create integrated feedback,. Integrated feedback
    1. is unlimited in size, the larger the amount of participants, the more effective the next release,
    2. gains insight in trends and weak signals for present and future functionality,
    3. is generated in the form of testing developed functionality as well as new (unrelated) ideas.
  2. Integrated employee (as internal experts) feedback with the same aspects explained under the integrated customer feedback and
    1. open to all employees, continuously…
  3. The feedback combines both quantitative and qualitative information.
  4. Each feedback is signified by the feedback provider. This provides navigation through large amount of feedback.
  5. The Product Owner analyses the feedback-patterns. The combined quantitative and qualitative information enables both a deep understanding of the explicit functionality-feedback and the high level patterns.
  6. Because the feedback is integrated in agile development methods (like Scrum, Kanban, OpenUP, ..) experimentation of new functionality is possible in a semi-real environment using real customers.  This seriously reduces R&D and Sales and Marketing effort and optimizes organizational learning.
  7. CusDevCus fully builds on devOps, BusDevOps lean startup and other agile evolutions.
  8. CusDevCus is based on open feedback in the form of narratives. That means there are no preformatted testforms or questionnaires for feedback.
  9. Of course the open format feedback does not eliminate the need for professional testing!

10. CusDevCus focuses on different user groups. Different user groups have different needs. They reveal different uses (or no use) of functionality.

In my view the above described next step in agile (software) development is a natural one. The main question is whether companies are able to make the mental shift to integrate the customer as described in the software development lifecycle.

Human Sensor Networks

13 March, 2013

Michael Cheveldave from Cognitive Edge wrote a blog on human sensor networks. It is excellent reading material. This blog contains the highlights of Michael’s explanation, with references to Agile IT development and DevOps.

By changing human sensor networks into customer sensor networks, I merely focus on the application of CSN in IT Agile development life cycles. You may easily argue to keep human sensor networks, as also own employees or other relevant stakeholders provide feedback using the CSN system.

Michael explains the role SenseMaker® plays in delivering organizations the value of human sensor networks.

… by engaging a large number of people in the process of making sense of their everyday experiences and observations, and allowing meaning to be effectively layered on such experiences we stimulate a network of agents in the systems to make sense of the system themselves.

By integrating different customer groups in functionality definition we will

  • easier and sooner understand real customer needs
  • build a fruitful relationship with the customer-base
  • create pro-active sponsors at the customers of the product
  • enable the customer-base to better understand their needs, and innovative possibilities that the organization can provide
  • better understand which private betas to be tested by which user group type
  • better understand collected quantitative data by means of this qualitative data

… think about how traditional approaches often emphasise the value of external experts or selectively privilege a small team within the company on such strategic decisions.

The decision making process which functionality to build and release

  • focusses more quickly to that functionality actually needed by customers
  • enables, together with feature flags, different features to be released to different customers types (based on their needs)

Sales and marketing collect valuable information on their targeted customer groups. Information is achieved cheaper, faster and more reliable then based on traditional marketing research.

The approach (a human sensor network AK) allows for the executive team to tap into the distributed cognition, intelligence, scanning, and knowledge of a broader network in a way that effectively informs key strategic decisions.

Reading experiences, ideas and frustrations from actual users, exposes product management, marketing managers and developers to the impact of their initial ideas on what functionality is needed. When well guided, the team will quickly and easily understand existing patterns and needs. Future releases are more effective and efficient.

The ultimate result is a learning organization. People from different organizational silo’s co-interpret and co-decide based on both trends and contextual information. This leads to an organizational wide understanding of and believe in the business goals and opportunities.

Customer Sensor Networks

12 March, 2013

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.

Customer Sensor Network

Figure 1: Customer Sensor Network implementation.

The CSN explained here is based on Sense Maker® software of Cognitive 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 SenseMaker® in scrum projects

2 July, 2012

In earlier blogs I showed how SenseMaking software ecology and the Cynefin model support Agile development. In this blog I’ll explain how to SenseMaker® supports gathering large amounts of user stories or feedback. These stories are input for the product back log and the product vision.

SenseMaker® enables software developing organizations to involve large groups of users or customers in both the requirements gathering phase and the maintenance phase. This gives them an advantage over their competitors. The input and feedback ensure that the new functions are adequate and fulfill a concrete demand.

Story tellers enter their stories on website. After entering their stories they are asked to provide additional meaning to their stories. This provides for valuable additional information. This is called signification and forms the core of the requirements gathering process. The signification framework is tailor-made. It structures the hundreds or thousands of stories in such a way that the development team is able to analyze them effectively.

In a next step the development team(s) analyze the entered stories. During the analysis the team transfers the raw user stories into a product back log. The backlog reflects the concrete demand of the users and customers. As the categorization incorporates a prioritization the development teams knows which functionality is to transferred to the sprint team first.

Emerging functionality
Once the sprint teams deliver their first functionality to the users, SenseMaker enable real-time feedback. This mechanism allows end-users to evaluate and try out new functionality and provide instant feedback. Because of the automated and real-time feedback mechanism the development is able to deliver only functionality for which is a real demand. It is also possible to try out new stuff end-users have not seen before.

The above described mechanisms provides a great advantage for the organization. First it doesn’t waste valuable development capacity on irrelevant functionality. Second, both first–end-users and developers feel appreciated as their ideas and thoughts are directly used. Thirdly because the organization is able to produce new functionality in a lean and flexible manner, the organization gains the recognition being innovative and customer-centric.

Cynefin-agile requirements development using SenseMaker®

6 June, 2012

In a previous blog I wrote on Lean and Agile software development with Sensemaker.
In this blog I’ll further explore the actual use of Sensemaker for initial development of requirements for software projects. I also explain the process of distilling high level requirements into detailed user stories.

In standard fail-safe software development environment, requirements development is a steps-wise process from high level business- or user requests into smart allocated product component requirements.  This is a process which intertwines with constructing a Work Breakdown Structure. This breaking down enables the project to determine a high level overview on the work to be done. It is the vision of what the end product is about, without yet knowing the functionality in detail.

At this point the project decides on the approach to develop the functionality (e.g. scrum, waterfall, etc.) and how this is delivered to the customer. Typically if the environment is both complex in terms of number of requirements, the number of stakeholders involved and the frequency that requirements change, a Cynefin-agile approach is recommended.
If the set of requirements is limited and clear from the outset, just use the waterfall method or, if you can’t resists, apply agile-scrum.

In order to apply the cynefin-agile approach the use of signifying large quantities of requirements in SenseMaker is recommended. Using SenseMaker involves signifying the requirements or user-stories. Signifying can be done by the providers of the user stories, or by SenseMaker. It reduces the overhead of handling large amount of stakeholder input significantly.

Signifying provides a structure that enables the development team to view large amount of entered stories from different viewpoints. (during maintenance of the delivered product this method provides strong innovation opportunities).
Analyzing the signified set of requirements/user stories provides the product backlog.

Another element of cynefin-agile are the so-called experiments. In early stages of new development, neither the stakeholders, nor the development team have a clear picture of what is to build. So in stead of the standard fail-safe approach an Safe-Fail approach is opted.

Safe-fail provides an development environment based on learning. Only by learning the development team and other stakeholders are able to gain an understanding of the capabilities and opportunities to be developed. Experiments are started on some selected user stories from the product backlog. Mark that failures of some experiments are expected! This failure provides the must needed learning. Learning provides valuable insight in the risks and innovation possibilities.

The functionality delivered after each sprint or increment is evaluated by the team and stakeholders. Experiments are either stopped or enforced. In such way, all parts of the vision can be addressed.
The delivered functionality is co-created by the development team and all stakeholders.

Using Sensemaker® enables development teams to apply the cynefin-agile approach of safe-fail software or product development.

a winner approach to innovation using early adopters in your customer-base

5 June, 2012

Many organizations fail to integrate the mass user community in their innovation programs. SenseMaker® is a tool which enables you to do just that. Use technology early adopters to co-drive your innovation program to impress the big-mass of regular users.

Early adopters are proud people. They love to prove to pragmatists and conservatives the use and fanciness of gadgets and new technology. They also have continuous new idea’s for even fancier and more hi-tech gadgets and functionality.

SenseMaker enables you to continuously interact with these early adopters to extract all their combined ideas and innovation opportunities into the Sensemaker database. When this innovation-gathering process is integrated with an agile development environment you are able to bring those idea’s to the early adopters within a few weeks.

This very simple mechanism generates 2 major marketing opportunities for your organization. First it gives you a close connection to the early adopters as you prove over and over again you listen and deliver. Your organization can be trusted.

The other major advantage is that for the pragmatists and conservatives under your customers, you become this innovative company which is again and again able to surprise the market.

A simple and therefore highly effective marketing mechanism. SenseMaker at the heart of your innovation program using the power of your customer-base.

Why software projects needs Sensemaker®

22 May, 2012

Agile software development enables software developing organizations to deliver functionality at regular and small intervals. In order to do this effectively the organization needs to understand the needs or problems of the customer. But what if the customer does not know exactly what he needs/wants or if there are (too) many customers to be satisfied? In this blog I’ll explain how Sensemaker® provides a solution to the afore mentioned challenges.

In Software projects input (requirements) is not generally generated from the public. Intern experts (architects, domain experts, business analysts, ..) provide input to designers and programmers. In many areas this methods is working fine.
However, there are domains (e.g. civll society market) in which the domain experts need input from customer representatives to provide them insight in what functionality needs to be build. If this is input not provided, the delivered software is not successful with unsatisfied customer(s).

Sensemaker enables large scale and fine tuned listening. No matter how many customers, where on the globe they reside and what language they speak, you can easily collect their user stories (fragments in Sensemaker terminology) or feedback.
Sensemaking method provides means for the customer to add value to their stories. This added value is part of the core functionality. Without interference of your local domain experts, you get the knowledge directly from the fragment-providers. The added value is used to structure the gathered fragments. This way it provides input to you local functionality builders.

The Agile-software-development and Sensemaker combination enable large scale feedback loops. The input-build-deliver-feedback loop can be as short as 3 weeks. The loop-size is determined by the sprint-size. Sensemaker provides realtime feedback.

Because Sensemaker provides multiple views on the collected fragments it becomes possible to release functionality per location or customer-type.

In short, Sensemaker provide software development organizations the power to listen continuous and real time to hundreds of thousands of customers. Listening also enables feedback on delivered functionality (after each iteration or sprint). The organization effectively knows exactly the needs, wishes and constraints of each and groups of customers.

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.