Design Thinking

Geplaatst op door erik

Onder dit thema leveren we services gericht op het ontsluiten van creativiteit en effectieve innovatie van producten en processen. Door de focus op kortcyclisch DOEN en LEREN in combinatie met aandacht voor VERBINDING met alle stakeholders, sluit design thinking erg goed aan bij AGILE ontwikkeling van de organisatie.

Het concept Design Thinking

Design thinking heeft een sterke link met “wijsheid van de menigte” en het gedachtegoed “Jobs-to-be-done” van prof. Clayton Christensen. Het gedachtengoed is gericht op toegevoegde waarde maximaliseren. In de eerste plaats door de focus op verbinding met de stakeholders op zowel rationele maar vooral emotionele gronden. In de tweede plaats door snel LEREN en innoveren op basis van feiten door middel van DOEN!

De aanpak richt zich op de volgende punten:

  • Empathie: waardering en respect voor elkaars kennis, expertise, opinies en meningen.
  • Probleemdefinitie: een door iedereen gedragen beeld van het probleem waarvoor een oplossing gezocht wordt.
  • Creativiteit: ruimte creëren om ideeën te genereren, af te wegen en te toetsen
  • Kiezen: als groep gedragen keuzes maken van wat opgepakt wordt.
  • Leren: prototypes maken, testen en daarvan leren.

Training design thinking

In een doorlooptijd van drie dagen worden leiders en coaches getraind in het implementeren van design thinking in hun organisatie.

Workshop design thinking

Gericht op een specifiek project ondersteunen van project team in het komen tot een goed uitgangspunt.

Coaching

Ondersteuning van teams in het implementeren en toepassen van design thinking.

De architect rol in digital transformation

Geplaatst op door erik

Digitale transformatie en innovatie vereisen veranderingen van zowat alle aspecten van een organisatie. De relatie met klanten en de product keten waarvan ze onderdeel zijn verandert, de noodzakelijke competenties moeten geherwaardeerd worden en men moet de manier van samenwerken opnieuw ontdekken. Enterprise en business architecten dienen in deze dynamische context een centrale rol te spelen.

De meeste organisaties hebben inmiddels ingezet op een agile manier van werken als basis voor de vereiste transformatie. En dat is een goede zaak!. De precieze rol van met name enterprise en business architecten in dit agile proces en de transformatie blijkt echter nog de nodige vragen op te roepen bij zowel het management als de architecten zelf. In de zoektocht naar antwoorden hierop is het goed eerst een gedeeld beeld te creëren van het soort problemen waarover architecten zich buigen, wat unieke architect competenties zijn en hun positie in de organisatie.

Ten eerste het soort problemen waarop architecten zich focussen. Om die te bepalen is onderstaande matrix behulpzaam. Hierin zijn de helderheid van het probleem afgezet tegen de mogelijke oplossingen.

In de praktijk zie ik architecten focussen op een of meer kwadranten. Echter, als de oplossing of het probleem helder is hebben ze hooguit een ondersteunende rol. Specialisten in een bepaalde oplossing of probleemdomein, zoals data analisten, ontwerpers of verandermanagers hebben in de praktijk de leiding. Architecten nemen in dit soort situaties vaak een kwaliteitszorg rol. Hun focus is vaak de zorg dat de uiteindelijke oplossing in lijn is met ieders belangen.

Echter, als het probleem en de mogelijke oplossingen niet helder of zelfs vaag zijn, komen de architecten goed tot hun recht. Deze situatie vereist zowel een hoge mate van conceptueel denken als begrip van IT en business en het hebben van adviesvaardigheden. Eigenschappen die meestal toegekend worden aan architecten.

Gelet op competenties zie ik veel aandacht voor modelering en bijbehorende tools. Dit is zeker een noodzakelijk aspect maar volgens mij niet de sleutel tot succes. Een grondige analyse, gedeelde toekomstbeelden creëren en zorgen voor door alle stakeholders gedragen besluiten wel. Wederzijds begrip en vertrouwen zijn randvoorwaardelijk om een rol te hebben in dit spel. Business zowel als IT kennis zijn noodzakelijk om als volwaardig partner te kunnen acteren. De belangrijkste competentie is echter design thinking zoals gedefinieerd door D.school: Institute of Design at Stanford.

Empathize, define en ideate zijn de eerste drie stappen van design thinking en hebben tot doel op basis van gedeeld begrip tot hanteerbare probleemstellingen te komen en ideeën voor oplossingen te genereren. De benodigde vaardigheden op deze gebieden zijn het ontwikkelen van relaties, het leiden van een denk- en besluitvormingsproces om problemen te verduidelijken en om een gezamenlijk beeld te creëren van oplossingen met een grote groep van diverse stakeholders.

Inherent aan de aard van het hierboven geschetste probleemdomein is een leerproces. De organisatie ontwikkelt een beter begrip van de problematiek. De architect ontwikkelt een beter begrip van de oplossingsruimte. Een korte feedback cyclus is daarbij essentieel om controle te houden over de ontwikkelingen en de daarbij horende kosten. De design thinking stappen die hierop focussen zijn prototype, test en rol uit.

Het belang van dit leerproces en de rol zoals geschetst pleiten ervoor de architecten de verantwoordelijkheid te geven voor zowel de architectuurkeuzes als de realisatie ervan. Daarmee wordt geborgd dat de feedback terugkomt bij degene die de keuzes maakt.  Nog belangrijker is dat de architect ten opzicht van het management in een juiste positie komt om eisen te stellen. Er is op deze manier geen vrijblijvendheid. Management en architecten zullen er samen uit moeten komen om de digitale transformatie een succes te maken.

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.

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.