Tag Archives: agilty

Recensie: Formule X – Hoe zorg je voor extreme versnelling in je organisatie?

9789047012924-480x600Jurriaan Kamer en Rini van Solingen hebben met Formule X – Hoe zorg je voor extreme versnelling in je organisatie? een business roman geschreven waaruit duidelijk wordt welke stappen je moet ondernemen om de time-to-market in je eigen organisatie drastisch te versnellen.

In deze business roman volgen we Ronald Verhulst die directeur is van een grote keukenleverancier en geconfronteerd wordt met een reclame-uiting van de grootaandeelhouder waarin beloofd wordt dat keukens vanaf bestelling binnen twee weken geplaatst worden. Duurt het langer dan krijg je de keuken gratis. Klinkt goed ware het niet dat de huidige time-to-market twaalf of meer weken bedraagt. Ga er maar aan staan! Op basis van een aantal adviezen vanuit een Formule I-team weet Ronald deze geleerde lessen te vertalen naar zijn eigen organisatie en deze stap voor stap in te voeren. Enig idee hoe vaak een Formule I-team evalueert hoe ze bezig zijn en hoeveel verbeteringen er tussen twee races worden doorgevoerd?

Maar voordat Ronald daadwerkelijk zelf met deze adviezen aan de gang gaat, gaat hij eerst in zee met de Full Control Consulting Group die Ronald helpen met het invoeren van Total Efficiency Management waarmee meetbaar processen versneld kunnen worden. In lijn met zijn eigen adagio ‘Vertrouwen is goed, controle is beter!’ moet dat dus goed komen. Nee dus, maar dat kost enige tijd om tot dat inzicht te komen en de Consulting Group de laan uit te sturen en zelf met de geleerde lessen van het Formule I-team aan de gang te gaan.

Project XDownloaden: Formule X

Uit het gesprek met de coureur en de teambaas van het Formule I-team weet Ronald een zevental lessen te destilleren (de auteurs noemen dit het theoriemodel dat bestaat uit zeven onderdelen, waarvan de beginletters samen het woord ‘versnel’ vormen):

  • Versimpel – de kunst van het weglaten en vereenvoudigen (Hierbij wordt verwezen naar professor Gary Hamel’s bureaucracy mass index)
  • Eenduidige richting – een helder en inspirerend doel dat werkt als kompas
  • Ritme in uitvoering – organiseren in een cadans van terugkerende interactiemomenten
  • Snel en zelf beslissen – omkeerbare beslissingen en verdeelde autoriteit
  • Natuurkunde toepassen – de eeuwenoude basisprincipes onder snelheid en versnelling
  • Energieke en bevlogen teams – intrinsieke motivatie, autonomie en eigenaarschap
  • Leren en bijsturen – van doen leer je meer dan van nadenken: wie het snelst leert, die wint

In het boek krijgen we van al deze lessen de vertaalslag naar de keukenleverancier en zien we het effect maar ook het geworstel om de organisatie te winnen voor het maken van deze stappen. Bij de start zien we een silo-organisatie waarbij iedere afdeling efficient werkt maar het gaat uiteindelijk om het resultaat van alle stappen. Door aan de hand van de genoemde lessen te leren en op basis daarvan wijzigingen door te voeren wordt de doorlooptijd stap voor stap verbeterd. Uiteindelijk wordt een laatste drastische stap gezet. De muren tussen de afdelingen zoals sales, inmeten, plannen, inkoop, produceren, plaatsen en klantcontact worden afgebroken. Er ontstaan multidisciplinaire teams die van het eerste klantcontact tot de uiteindelijk oplevering van een keuken verantwoordelijk zijn. Het moge duidelijk zijn waar het uiteindelijk toe leidt. Er zijn nu teams die in een vaste cadans heel snel in staat zijn om keukens te plaatsen met heel veel tevreden klanten en een een grootaandeelhouder tot gevolg.

Conclusie: De gekozen insteek waarbij we leren van een Formule I-team en dat toepassen op een keukenleverancier laat zien dat je juist ook buiten IT veel kan (moet) doen om je organisatie wendbaarder te maken en wat dit betekent voor je rol als manager (o.a. loslaten en decentrale besluitvorming). Door het in een romanvorm te gieten leest het makkelijk weg. Persoonlijk vind ik echter de beschrijving van de huidige situatie en ‘verbeteren’ middels controlestappen te lang. Meer dan de helft van het boek gaat daar over en door dat stuk in te korten had het boek aan kracht kunnen winnen. Neemt niet weg dat het boek zeker het lezen meer dan waard is en voldoende stof tot nadenken en uitproberen biedt!

Tijdens het schrijven van deze recensie kwamen ze mijn CV ketel vervangen. Een team van 2 monteurs kwam om 08.00 uur. Rond 12.00 uur waren ze klaar. Klein probleempje: op de digitale thermostaat stond een foutboodschap. Geen verbinding met de CV ketel en dus nog geen verwarming! Het lukte ze niet om het op te lossen. Een connector tussen CV en thermostaat bleek kapot te zijn. Dat overkwam ze wel vaker bij het vervangen van een CV ketel. Deze energieleverancier had daar echter een apart team voor. Na een half uurtje bellen wisten ze me te vertellen dat ik binnen een half uur zou worden teruggebeld door de centrale. Dat gebeurde inderdaad en het team zou die middag komen ergens tussen 1300 en 1700 uur. Om ca 1600 uur kwam er een andere monteur met een nieuwe connector. Binnen vijf minuten gepiept. Stel dat deze energieleverancier dit boek gelezen had, dan hadden ze waarschijnlijk dit thermostaat-team, na evaluatie van dit soort problemen, geïntegreerd met de CV installateurs. Had vele telefoontjes, een extra rit, en de doorlooptijd bij mij met 50% versneld en bij de leverancier de kosten naar beneden gebracht!

Een week later krijg ik een brief voor een onderhoudsbeurt aan mijn CV ketel. Dit betrof nog onderhoud aan mijn oude ketel. Na een aantal telefoontjes werd duidelijk dat de backoffice de wijzigingen nog niet had doorgevoerd. nog een voorbeeld van verschillende teams/silo’s. Ondertussen heb ik nog drie brieven over het inplannen van regulier onderhoud mogen ontvangen. Ik zal dus nog maar eens gaan bellen en dit boek onder de aandacht brengen.

Bestellen (managementboek): Formule X – Hoe zorg je voor extreme versnelling in je organisatie?

Bestellen (Bol.com): Formule X – hoe zorg je voor extreme versnelling in je organisatie

Ondertussen werken Rini en Jurriaan ook aan een aantal vlogs.

Review HBR May-June 2018, Agile at scale

HBRIn this interesting article Agile at scale – How to go from a few teams to hundreds the authors Darell K. Rigby, Jeff Sutherland, and Andy Noble give insights in their study of scaling up of agile at hundreds of companies.

Some key take aways:

  • Leading agile by being agile, don’t use top-down plans and directives to scale up
  • Create a taxonomy of teams. Break the taxonomy into three components – customer experience teams, business process teams, and technology teams – and then integrate them (see picture)

HBR Agile at scale

  • Get agile rolling. Launch an initial wave of agile teams, gather data on the value those teams create and the constraints they face, and then decide whether, when, and how to take the next step (test and learn cycle)
  • Sequence the transition. Don’t make the mistake of going for easy wins. You have to create a learning environment or organizational changes necessary to scale dozens or hundreds of teams
  • Big bang transitions are hard. Require total leadership commitment, a receptive culture, enough talented and experienced agile practitioners to staff hundreds of teams without depleting other capabilities, and highly descriptive instruction manuals to align everyone’s approach, a high tolerance of risk along with contingency plans to deal with unexpected breakdowns. It’s often better to roll out agile in sequenced steps, with each unit matching the implementation of opportunities to its capabilities
  • No agile team should be launched unless and until it is ready to begin. The team is:
    • Focused on a major business opportunity with a lot at stake
    • Responsible for specific outcomes
    • Trusted to work autonomously – guided by clear decision rights, properly resourced, and staffed with a small group of multidisciplinary experts who are passionate about the opportunity
    • Committed to apply agile values, principles, and practices
    • Empowered to collaborate closely with customers
    • Able to create rapid prototypes and fast feedback loops
    • Supported by senior executives who will address impediments and drive adoption of the team’s work
  • Master large-scale agile initiatives with teams (of teams) of teams
  • Building agility across the business
    • Not every function needs to be organized into agile teams, but ensure that the functions that don’t operate as agile teams support the ones that do
    • Push for greater change in four areas: agile values and principles (agile and traditional teams), operating architectures (modular approach), talent acquisition and motivation (you need expertise combined with enthusiasm for work on a collaborative team, coaching, public recognition, team reward, …), and annual planning and budgeting cycles (annual cycles constrain innovation and adaptation, view decisions as opportunities to purchase options for further discovery, …).

Scrum or Kanban

In one of my previous blogs I wrote about ‘Agility by delivering changes as ‘business as usual’

In that article I showed a picture with different agile methods and frameworks. On the team level I mentioned Scrum, Kanban and DevOps. I came across a blog post from Roman Pichler titled ‘Is Scrum right for your product?’. A nice article explaining when to use Scrum and when to use Kanban, by following a product life cycle from launch via product market fit till the end of life. I added DevOps to his approach in the same product life cycle and will use this to expand my own article. See the animated PowerPoint too.

During the first part of a product life cycle the uncertainty is high and the focus is on goal driven iterations for the first product launch and market fit product. During this part of the life cycle Scrum is a great fit to cope with uncertainty and product iterations developed by the whole team. During the rest of the product life cycle the amount of uncertainty and change gradually declines. Here Kanban is a good fit. User Stories will be realized in a continuous flow by one or more of the individual team members.

When a major product upgrade has to be delivered by the whole team Scrum could be a better choice for that goal oriented iteration, otherwise Kanban stays a good fit.

To avoid the error prone handover and to shorten the time to market the Development and Operations teams can be integrated. Kanban is a good fit for the DevOps team. When to start with DevOps varies.

See: Is Scrum right for your product?