Archive for the ‘project management’ Category

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.


Lean development: from safe-fail design to safe-fail experiment

24 April, 2012

Safe-fail design is tricky and almost impossible. Safe-fail experiments using the Cynefin-model and SenseMaker®-tool suite provide a much better solution.

Safe-fail-design is nearly impossible because the design-team takes early decisions which are only much later delivered to customers. When decisions are made early in the development life cycle, not all aspects, related to that decision are known. It is more then likely that issues pop up much later. Correction of faulty early design decisions becomes a costly, frustrating and sometimes technically tricky issue.

Safe-fail experiments work best in complex environments. Complex environments have many stakeholders, of which many have different backgrounds and therefore different needs, wishes and constraints. All these have to be incorporated somehow in the total set of requirements.
In this fast moving world, stakeholder needs, wishes and constraints, never stay the same for a long period of time. The designer(s) have to take this into account. But how?

As earlier mentioned, the Cynefin-model provides a solution placing design-problems in the complex domain. The linked solution of complex problems is to experiment on a small scale with different possible solutions. Those that work are continued and strengthened. Experiments that does not work are simply ended. Lean Development incorporates experimentation.
Using lean development, the complete development team designs, builds, tests and delivers a small (set of) functionality within 2 or 3 weeks. This way an environment for experimentation is created for the development team to find out if they actually do have a correct common understanding on the meaning of the needs, constraints and wishes of the stakeholders. This enables safe-fail experimentation.

This solves the first part of the problem. The team is able to deliver to the stakeholder that functionality that the team believes is exactly what the stakeholder needs. If it is not, the team has learned a valuable lesson against low cost. The stakeholder is content that the development team listens to his needs and that they take him seriously.

Now to the aspect of the huge amount of stakeholders and their variation. Additionally stakeholders may not be located near the development team, and they might speak different languages.
Also typically stakeholders do not know what they actually want to have. They do not know what is possible. And if they know all the aforementioned, they often lack the words to bring across exactly what they need to the design-team.

Story telling is a proven way to share information on a complex problem. By letting stakeholders tell their (vision and user)-stories, they focus on what is important and critical for them. Stakeholders add additional meaning to their requirement specs (through SenseMaking). This eanables the development team to identify and evaluate patterns that are present in the metadata to understand the requirements in the stories and priotize them. The software and the characterization process supports different languages.

Combined, the 2 approaches provide a solution for organizations to handle many critical stakeholders who move with their views and opinions in this fast emerging world.
Safe-fail experiments support functionality to emerge during development.

In a later blog I’ll describe how to get from a vision-level of user stories to a user story which a development/sprint team can deliver in one sprint.

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.

Nut van gedocumenteerde processen en afspraken; op het werk en thuis.

2 April, 2012

1 zelfstandige heeft weinig reden om (veel) processen te documenteren. Redenen die ik kan bedenken zijn checklijstjes en de stappen voor weinig voorkomende werkzaamheden. Bij het laatste voorbeeld voorkomt het opschrijven wat je moet doen, dat je het later mogelijk opnieuw moet uitzoeken wat nu ook alweer precies de stappen waren en waar je informatie de vorige keer hebt bewaard.

Een alleenstaande kan doen en laten wat hij wil. Eten wat hij wil, muziek luisteren enz. Het is wel handig als hij bankafschriften bij elkaar bewaard. Het invullen van de belastingaangifte gaat ook gemakkelijker als de informatie hiervoor op bekende plekken te vinden is.

2 mensen in een team moeten al veel afstemmen. Waar staat welke informatie, begrijp ik jouw informatie, op welke manier informeren wij elkaar en kunnen wij afgaan op wat eerder is afgesproken? Hier geldt dat je of iedere dag met elkaar overlegt over alles wat van belang is. Zo niet, dan werkt het gemakkelijk als jij weet waar je collega zijn informatie bewaard. Ook is het fijn als hij dit altijd op dezelfde manier doet.

Een koppel moet meer afstemmen dan een alleenstaande. Wat wil jij? Waar ben jij hoe laat? Wat gaan we eten? Doe jij boodschappen? Waar heb je die brief gelegd?
Het is duidelijke. Wil je geen ruzies en frustraties dan is het handig dat er afspraken worden gemaakt en nagekomen.

3 of veel mensen in een organisatie moeten overeenstemming bereiken op welke manier zij samenwerken. Frustratie over dingen die niet (juist/tijdig) gedaan worden liggen op de loer. Afspraken moeten continu worden herijkt om te zien of zij nog wel doelmatig zijn.

Een gezin met kinderen is een groot deel van de tijd bezig werk en andere betrokkenen (ouders, vriendjes, school/kinderopvang, werk) met elkaar af te stemmen. Afspraken zijn hier nog belangrijker omdat de verschillende stakeholders niet te verenigen zijn. En dan wordt nog één ding duidelijk. Het maken alles afdekkende afspraken en deze vastleggen, blijkt ineens niet voldoende te zijn.
Kinderen veranderen, regels die gisteren nog (of juist nog niet) nodig waren, blijken vandaag niet meer nodig te zijn. Ook de omgeving blijkt ineens onvoorspelbaar te zijn. Het vastleggen van afspraken is ineens een complexe aangelegenheid. Vaak blijkt alleen achteraf wat de manier van aanpak was geweest.

Zo kom ik op 2 conclusies:

1, alles afdekkende regels maken niet noodzakelijkerwijs een ‘werkend’ en gelukkig gezin. Binnen de grenzen van wat mogelijk is geniet je van de vrijheden en veiligheid die door de afspraken worden gecreëerd.
Dit geldt ook binnen een professionele omgeving. Mensen en de omgeving bepalen welke (typen) regels en afspraken nodig zijn. Dit kun je niet 1-op-1 aan een model ophangen.

2, is bij een gezin complexiteit te managen door liefde, vergevingsgezindheid en improviseren, in een professionele omgeving is dit (veelal) niet mogelijk. Hier zijn technieken voor het omgaan met complexiteit nodig. Deze technieken geven inzicht in de mate van complexiteit en passende manier van aanpak.

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