Valuation of ideas (eng)

Geplaatst op door erik

Most organisations struggle with the way to choose and prioritise ideas for software development. Effective communication, sharing of convictions and a strong focus on learning will help to be innovative without loosing control. Most software development organisations have an agile process in place. To improve effectiveness they should invest in design thinking.

Questions asked frequently to me and my colleagues are: how do I determine a feature has value? How do you determine something has value to the business? How do you measure it? The reason for asking most of the time is a personal wish to improve something.

In many agile handbooks they say the product owner should decide. To support the decision making a lot of rule sets and formulas are available which try to objectify business value. But I think the answer isn’t that trivial.

What I notice is that the more effort one puts in grabbing the value the harder it gets to grab it.

I think the main reason for this is the role of uncertainty. Checklists, rules and formulas typically don’t take into account that not all is clear, that you don’t know all the parameters or not everyone agrees on the parameter values. It is easy to say “if this then that”, but if you don’t know if ‘this’ applies you still don’t know what to do or decide. The only way out is to act on estimates, convictions or believes.

For a startup this is easy.  You have a great idea and are you are convinced people are waiting for this. You are prepared to work night-and-day to prove you are right. You have a vision and are totally committed to realizing it. Finally you either come to the conclusion it doesn’t work, you run out of money or you end up as CEO of a highly valued company:-)

The problem with large organizations is that in order to be effective not only a lot of persons have to share the convictions and believes but they also have to commit themselves to proving them as well. Complicating factor is they have a responsibility to a large number of shareholders regarding the going concern as well.

This brings me back to the questions asked.

In virtual all cases the real problem is they don’t know, understand or share the convictions or believes. They perceive the organization as indecisive or even fickle. This obviously has impact on the commitment of the ones involved as well. Who wants to work night-and-day for realising ideas they don’t really believe in?

So what to do?

The essence is: you have to invest in understanding your clients as well as each other, generate ideas and select and commit to ideas. These ideas are based on assumptions that represent risks for the company. Managing these risks requires an approach concentrated on validation of assumptions in economically the best order.

The solution is twofold. Use the design thinking concept for creating shared believes in order to focus and create commitment. Then, use your agile development proces as it is meant: fail fast, learn fast. For me the conclusion is that there are good practices to determine the value of ideas but from a development perspective the nr. 1 criterium should be: what is now the most important thing to learn.

I like to elaborate on this aspects in future blogs. Please feel free to react with opinions and ideas to support this process.

LEAN wordt agile

Geplaatst op door erik

Een van het meest voorkomende en begrijpelijke misverstand is dat lean alleen geschikt is voor fabricage of routine situaties, met een zich steeds herhalende procedure en een sterke nadruk op de reductie van variatie ofwel verspilling. Volgens mij kan dit misverstand goeddeels opgelost worden door lean in de context te plaatsen van wat organisaties nu bezig houdt, speciaal gelet op de risico’s die ze lopen.

Altijd als ik betrokken ben bij lean implementaties in de afgelopen jaren is de meest opvallende en vaak te horen opmerking dat lean is bedoeld voor herhaalde, sterk gestandaardiseerde processen en daarom niet geschikt is voor ontwikkeling of projecten. Een van de argumenten is dat alle bekende en uitgewerkte voorbeelden uit fabricage omgevingen komen, te beginnen met Toyota. Een ander argument is de sterke focus op reductie van verspilling in procedures. Een derde argument is dat lean slechts een toolbox is voor management om variatie en dus kosten te reduceren.

Inderdaad, de lean filosofie is ontwikkeld in massa productie omgevingen als antwoord op de vraag hoe de kwaliteit, zijnde fitness-for-use, te borgen in een situatie dat de concurrentie positie werd bepaald door de mate van efficiency: het realiseren van economies-of-scale door grote markten te bedienen met goede producten tegen lage kosten.

Essentieel voor het borgen van kwaliteit in die situatie was het begrijpen van de klant, het product en het proces volgens welke dat product tot stand komt. Gezien het belang van efficiency is het niet vreemd dat de nadruk ligt op reductie van variatie in de processen. En variatie is het resultaat van risico’s die men loopt: gebeurtenissen waarvan niet duidelijk of en wanneer ze optreden. Dus iedereen zoekt naar de mogelijkheden om deze risico’s te elimineren. Dat kan gaan over risico’s met de kwaliteit van input materialen, de risico’s van slecht geëquipeerde medewerkers, de risico’s van onbekende procedures of de risico’s van geen begrip van ‘de klant’. De eerder genoemde argumenten waarom lean niet geschikt is komen door deze associatie met efficiency.

Nu leven we in een tijd dat het leveren van hoge kwaliteit op een voorspelbare manier gewoon is. Gelet op concurrentie positie staat vandaag de dag de relatie met de klant, gebruikers en allerlei andere stakeholders centraal. Om concurrerend te zijn moeten organisaties niet alleen focussen op het steeds sneller vernieuwen van hun producten maar tevens op het herdefiniëren van haar producten en services. Dit betekent onder meer het nauw betrekken van gebruikers bij de ontwikkeling en het volop ruimte geven aan creativiteit. Met deze eisen worden de bronnen variatie midden in het development proces, het kritieke pad, geplaatst. En de grote vraag is weer hoe kwaliteit, tijdigheid en kosten in bedwang te houden.

In standaard procedures wil je risico’s vermijden of elimineren. In een ontwikkelomgeving moet je deze risico’s echter omarmen. No guts, no glory, klinkt dat in goed Engels. De vervolgvraag is dan ook hoe de gevolgen van risico’s tijdens ontwikkeling of projecten te minimaliseren. Dat betekent onder meer het verbeteren van de identificatie en kwalificatie van risico’s, het schatten van de impact, het bepalen hoeveel risico je kunt nemen en het definiëren van een ontwikkelproces op zo’n manier dat de grootste risico’s met de meest impact als eerste getackeld worden en risico’s in hun algemeenheid zo snel mogelijk geëlimineerd worden. Het spel is nu beheersen van risico’s, niet het voorkomen ervan.

Voor software ontwikkeling zijn diverse agile raamwerken beschikbaar om dit te tackelen. Verrassend genoeg zijn deze gebaseerd op lean gedachtengoed. Ik ben ervan overtuigd dat er geen fundamentele reden is dat lean niet werkt in een ontwikkel- of projectomgeving. Haar schaalbaarheid over disciplines en zelfs over organisatiegrenzen zijn zelfs grote pluspunten. Het betekent wel dat de toepassing afgestemd moet worden op de huidige focus en risico attitude. Daarover is nog veel te leren. Laten we starten met het verzamelen van verhalen in deze context.

Begrip van agility

Geplaatst op door erik

Ik heb inmiddels een behoorlijk aantal verandertrajecten om een agile informatievoorziening te realiseren gezien en ondersteund. Tijd om de op de ervaringen gebaseerde visie te delen dat agile worden hard werken is voor. …management.

Geheel in agile stijl is het volgens my belangrijk te beginnen met wat agile werken op zou moeten leveren. In het algemeen zijn de doelen van de agile transformatie:

  • meer creativiteit: effectiever gebruik maken van de beschikbare denkkracht, intelligentie en ideeën;
  • meer flexibiliteit: in staat zijn snel in te spelen op externe omstandigheden en veelbelovende nieuwe ideeën;
  • meer controle: in staat zijn te voorspellen, beter begrip van onzekerheden etc.

Het is van belang je hierbij te realiseren dat dit geen zero-sum game is. De vraag is dus niet hoeveel creativiteit offeren we op voor meer controle. De vraag is hoe verbeteren we en de controle en de creativiteit en de beheersbaarheid!

Gebaseerd op de hierboven genoemde doelen en het bewustzijn dat het geen zero-sum game kan zijn bij implementatie van frameworks als scrum, devops of het scaled agile framework zie ik een aantal steeds terugkerende thema’s. Veel voorkomende vraagstukken zijn: hoe houden we zicht op de lange termijn doelen? Hoe decomponeren we producten en houden zicht op de waarde die elk onderdeel creëert? Wanneer zijn specificaties voldoende om mee te starten? Hoe schatten en plannen we?

Voor de meeste vragen bestaan goede instrumenten en processen die ook daadwerkelijk gebruikt worden. Concepten als ‘Definitions of ready’ en ‘done’ (DoR, DoD), backlog management of het sprint-proces zijn goed ingeburgerd. De instrumenten zijn eenvoudig toe te passen. De uitdaging is echter hoe van gebruik van deze instrumenten te komen tot realisatie van de gestelde doelen. Dat kan alleen door de instrumenten te gebruiken en ervan te leren. Leren hoe in de specifieke situatie, met de marktdynamiek en de eigen propositie de instrumenten het best gebruikt kunnen worden.  In feite betekent de implementatie van een agile framework de introductie van een aantal gebieden waarop de organisatie begint te leren.

Complicerende factoren zijn echter dat de leergebieden met elkaar verbonden zijn en dat per leergebied meerdere disciplines te leren hebben. Bijvoorbeeld, leren schatten is lastig als er geen DoD of DoR is en zal met het team, IT management en business opgepakt dienen te worden. Een retrospective als er geen goede DoD is leidt al snel tot generieke opmerkingen die in de praktijk niet opgepakt worden. Als er geen door alle disciplines gedeeld beeld is van waarde beperkt dit de effectiviteit van backlog management.

Dus, een effectieve implementatie van agile vereist vooral aandacht voor hoe de organisatie leert op meerdere gebieden tegelijkertijd. En op een manier dat èn de creativiteit, èn de flexibiliteit èn de controle toeneemt! In een specifiek operating model dat de organisatie heeft of wil hebben.

Dit is al met al een lastig vraagstuk dat niet zomaar te vangen is in wat algemene hints, een model of framework. Dit maakt een transformatie naar agile werken een maatwerk traject waarbij de genoemde instrumenten zeker helpen om kader te geven. Het blijft echter in hoge mate maatwerk waarbij succes afhangt van een gedragen visie en hoe het leren gefaciliteerd wordt door de governance structuur, het leiderschapsmodel, het gedrag en attitude van alle betrokkenen, de aanwezige competenties en de beschikbare technologie. En aangezien wijsheid geen standaardsituatie is zal op deze vlakken ook genoeg te leren vallen: double loops learning volgens Argyris. Kortom betekent het veel werk en creativiteit van het management om een vruchtbare bodem te creëren voor de transformatie.