Posts Tagged ‘agile’

Agile opschalen met Kanban

11 May, 2018

Wanneer één team op een agile manier werkt heeft dit slechts een beperkt effect op de verbetering van de hele waardeketen. Sterker, lokale optimalisatie leidt vaak tot een verslechtering van de hele waardeketen en daardoor tot frustratie van de teams.

Wat zie je als een team agile werkt: Dit is een team dat nauw samenwerkt en zich continu de vraag stelt hoe het slimmer en beter kan. Zij nemen verantwoordelijkheid en starten experimenten om te zien welke aanpassingen voor hen werken. Het is een team dat metrieken gebruikt om inzicht te krijgen in de eigen capaciteit en om deze te verbeteren. Zij begrijpen hun rol in de volledige waardeketen en betrekken anderen indien nodig.

Een agile team krijgt vanuit management de ruimte en het vertrouwen om zich continu te verbeteren. Zo worden zij ondersteund om proactief met anderen in de waardeketen zelf verbeteringen te initiëren. Natuurlijk komt er meer bij kijken, maar wanneer deze aspecten niet aanwezig zijn, moet het team en het management zich de vraag stellen of zij werkelijk agile willen werken.

Wil je dus dat de hele waardeketen meer en sneller oplevert dan moet je naar de hele waardeketen kijken en het agile werken opschalen.

Opschalen van agile is simpelweg teams uit de waardeketen op een agile manier laten samenwerken. Dit gebeurt in 2 richtingen: verticaal tussen teams op verschillende organisatie niveaus en horizontaal tussen verschillende waarde toevoegende teams of personen.

Agile samenwerken betekent dat teams gezamenlijk bekijken op welke manier werk eenvoudig en effectief door de waardeketen kan stromen. Mogelijke vragen:

  • Zijn de werkzaamheden in de verschillende stappen juist op elkaar afgestemd?
  • Waar bevinden zich (mogelijke) bottlenecks?
  • Beschikken teams op het juiste moment over de juiste informatie?
  • Welke (waardeketen externe) afhankelijkheden zijn er en wat is het effect van de afhankelijkheden op de waardeketen?
  • Onderschrijven alle teams hetzelfde doel en visie?
  • Worden er continu (kleine safe-2-fail) experimenten gestart om de waardeketen continue te versimpelen en verbeteren?

Ook voor agile samenwerken geldt, dat er veel meer voor nodig is dan alleen het bovenstaande. Maar deze mentale houding levert de benodigde omgeving waarin alle teams zich kunnen ontplooien.

Er bestaat niet één model of framework dat 1-op-1 op een organisatie past. Agile samenwerken wordt pas succesvol als je de eigen organisatie en cultuur als uitgangspunt neemt. Het werkt niet als je een model kiest en probeert te implementeren omdat een concurrent dit (succesvol) doet.

De waardeketen teken je uit dmv alle belangrijke waarde toevoegende stappen achter elkaar te tekenen. Simpelweg ziet dit er zo uit:Slide1

Daaraan voeg je dan de invoer, uitvoer, bestaande feedbackloops, werk- en wachttijden en belangrijke afhankelijkheden in de waardeketen.

De ervaring is dat alleen dit visualiseren en verder duiden van bestaande kenmerken van de keten, al direct eerste verbeterpunten oplevert.

Raar maar waar, blijkt een eerste visualisatie vaak niet te kloppen! Als je vanuit verschillende perspectieven (rollen, bestaande verantwoordelijkheden) naar de eerste versie kijkt, blijken er verschillende ‘versies’ van de waardeketen te zijn. Dit inzicht, dat er verschillende interpretaties mogelijk zijn, is een belangrijk beginpunt voor een dialoog. Het laat zien dat in de loop van de tijd een situatie is ontstaan die maakt dat werk (en informatie) niet meer ‘als vanzelf vloeit’, maar dosis-gewijs wordt gestuurd.

Het actief sturen gebeurd onbewust en (vrijwel altijd) vanuit een goede intentie. Daarom is een goede dialoog over welke van de verschillende versies, de kern van de waardeketen is, van vitaal belang, en vaak een eerste stap in het opschalen van een agile manier van werken.

Kanban is een methode die perfect is toegesneden om de agile transitie te realiseren. Immers Kanban gaat uit van het visualiseren van de waardeketen en beoogt Flow van werkitems te verbeteren.  Opschalen is het schakelen van meerdere kanban systemen.

Over Kanban: Kanbanis een visueel signaal (kaart, boord). Een Kanban systeemis een manier om werk op basis van (virtuele of fysieke) kanbans, de flow van werk items te beheersen. De Kanban methodeten slotte, is het definiëren en verbeteren van kanban systemen. Een complete Kanban uitleg vindt je hier.

Je stemt Kanban systemen op elkaar af door de flow van werk en informatie te analyseren. Hiervoor gebruik je metrieken die de flow kwantificeren. Je zoekt naar de onbalans tussen bijvoorbeeld de hoeveelheid werk die een systeem inkomt en weer verlaat. Als je de invoer van een kanban systeem aanpast op de capaciteit ervan, zal het systeem snellere opleveren (de doorlooptijd neemt af), en de hoeveelheid werk en kwaliteit toenemen.

Okaloa Flowlab crossteamsimulaties vormen een perfecte start voor het afstemmen van kanban systemen over meerdere teams. De simulatie staat het toe de werkelijkheid van elk type werk te simuleren. Teams ervaren wat het effect is van een systeem dat niet in balans is en hoe systemen op elkaar af te stemmen. Overigens maakt het in dit geval niet uit of een team wel of niet Kanban gebruikt. Ook teams die volgens een Scrum methode werken kunnen de werkzaamheden in een ‘Flow’ krijgen.

Hieruit volgt ook direct het inzicht, dat het afstemmen van werk tussen 2 teams in een waardeketen met bv 10 teams, een gevaarlijke deeloplossing is.

Bedenk namelijk dat deze 2 teams meer werk leveren en aankunnen. Het effect is dat én het volgend team plotseling meer werk ontvangt (dan ze aankunnen) én dat het voorgaande team in de waardeketen, plots meer werk moeten leveren dan zij kunnen. Er ontstaat onbalans in het systeem.

Kortom, wanneer je naar een methode zoekt om de agile manier van werken op te schalen, overweeg dan de kanban methode eens. Bijkomend voordeel is dat Kanban uitermate geschikt is om verschillende type van werkzaamheden of werkproducten, in één systeem te integreren.

Arno Korpershoek,
Co-chi
Rotterdam,
mei 2018

Advertisements

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.