Valuation of ideas in an agile context (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.

About using models (eng)

Geplaatst op door erik

During my career I have seen come and go a lot of models aimed at improving the performance of IT. CMMi, Prince2, Scrum, SAFe, to name a few. What strikes me more and more is the huge differences in effect these models have, even between teams of the same organisation. Some teams are enlightened and show a huge boost in performance, while other teams successfully adopt new terminology and rituals but don’t show any real improvement.

Looking at all the cases I identified some aspects of models and the implementation of changes in general that influence the rate of adoption.

First the models. I think it is important to realise that models are not inventions, laws or recipes for improvement. They also don’t describe things that weren’t there before. Models are a visualisation of best practices, experiences and visions of a community: good ideas get a name. They provide a language to share this, regardless of organisation or country borders. One should realise that in general there is no scientific or statistical evidence. To speak with Edward Deming: “all models are wrong! Some are useful”.

All models are abstractions. This means aspects of reality are left out of the visualisation with the assumption they are stable or are irrelevant for the purpose of the model: a certain improvement. Question is whether this is true. In my experience a lot more aspects play a role, then visualised in the model.

Besides that, models have a number of assumptions. Adherence to these underlying assumptions determines whether the model is used effectively. So lets elaborate on these assumptions.

The first assumption is that anyone fully understands the model, mostly after a training. Just looking at the eternal discussions on the definition of requirements, makes this a weird one. Terminology and abstractions get meaning by using them. Sharing thoughts with each other is the most effective way to create this meaning. By definition, this makes it team, tribe or organisation specific.

Another assumption is that level of maturity of all involved has no influence on the ability to change processes using the model. This is a strange one too. I think this can be explained best by relating this to the third assumption.

The third and most striking assumption is that implementing a new way of working changes behaviour, which will finally lead to changing believes: the prerequisite for effective change. Changing of believes however is a slow process and depends on more then what is defined in the models. I already mentioned the abstractions and the level of maturity.

A beautiful illustration of the importance of believes is the agile manifesto. In a number of statements it makes clear what the believes should be. I think they are very appealing. However, there aren’t much organisations who make these beliefs the cornerstone of change, for example while implementing a scrum way of working. Discussing beliefs I think would be a beneficial shortcut to improvements.

Improving performance includes many factors which makes it complex. Consultants and managers alike, endorse the statement that it is all about people, their believes, their culture. Given what I stated above I suggest to give the improvement process back to these people. Don’t tell them we are gone use this model or framework. Ask them how using the model can help improve their performance. It creates more empathy, better communication, room for experimentation and prototyping. Leadership required!

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.

Wat innovatie afremt

Geplaatst op door erik

Veel managers die ik spreek zitten met de vraag hoe innovatie van organisatie en product vorm te geven met een steeds kleiner budget. Mijn standaard vraag is: Wat vinden je medewerkers of collega’s ervan? Het antwoord varieert van “Hoezo?”, “Ik weet het niet” of zelfs (en vaker)  “Zij snappen er niks van!”.

Onze collega’s zijn net zo hoog opgeleid als wij, vol energie, staan midden in het leven en zijn beter geïnformeerd over wat er in de wereld gebeurt dan ooit! Hoe bestaat het dat mensen zoals wij niet zouden begrijpen wat het probleem is en hoe ze kunnen helpen?

Mijn beeld? Omdat we gewend zijn aan principes die maken dat we niets anders kunnen bedenken dan ze gevangen te houden in een command&control structuur die allang niet meer past bij de huidige situatie en de aanwezige competenties.

Laat me een voorbeeld geven hoe twee teams het verschil maakten door ze meer vrijheid te geven  zelf hun omgeving en onderlinge afspraken vorm te geven.

Gedurende een aantal evaluaties kwam steeds hetzelfde problem boven water: twee teams werkten niet effectief samen met als consequentie achterblijvende kwaliteit van het gerealiseerde services en de noodzaak over te werken om deadlines te halen. Elke evaluatie gaf de verantwoordelijke manager aan de situatie op te zullen lossen. Niets leek echter te werken.

Tot de manager besloot eens met de teams om tafel te gaan en hen te vragen wat er nou precies aan de hand was. Binnen 10 minuten was duidelijk dat het probleem was dat een van de teams beschikte over de resources die ook het andere team nodig heeft. Het team dat de resources niet had, kreeg het niet voor elkaar tijdig resources ter beschikking te krijgen om hun werk goed te doen. Op verschillende manieren was dit al aangegeven maar het management herkende het niet als de grondoorzaak van het probleem. Eerder genomen maatregelen lagen op het vlak van meer rigoureuze planning en rapportages.

De discussie spitste zich vervolgens toe op twee mogelijke oplossingen. Of het eigenaarschap van de resources werd verdeeld of het team met de resources kreeg ook de verantwoordelijkheid voor het halen van de planning van het andere team. Gekozen werd voor het laatste: het team met de resources kreeg de verantwoordelijkheid voor het halen van de planning van het andere team.

Het effect? Het samenwerkingsprobleem was opgelost en na zes maanden bleek dat naast goede kwaliteit er een grote efficiency verbetering gerealiseerd was.

Ik heb een interessante oefening om je eigen rol in dit soort zaken te illustreren, die ik iedereen kan aanbevelen.

We weten allemaal dat in een auto je gas moet geven om sneller te gaan. We weten ook dat om ongelukken te voorkomen (stoppen voor rood) of om in control te blijven (niet te snel door een scherpe bocht) we moeten remmen.

De oefening is: schrijf een aantal specifieke maatregelen op die je genomen of ervaren hebt en stel je collega’s of medewerkers de volgende vraag: is dit gas geven of remmen? versnelt de maatregel of dient hij om in control te blijven?

Ik ben ervan overtuigd dat de meeste maatregelen betrekking hebben op in control blijven of risicovolle situaties te beheersen. Ik weet dat het lastig is, maar het is waardevol de ‘rem-‘acties te bespreken met je collega’s en medewerkers om te kijken hoe deze om te vormen in ‘gas-‘maatregelen. Ik kan je vertellen dat dit veel meer oplevert dan een book lezen over de volgende management-hype of beheersmodel.

Begrip van agile

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.