agile – Agitma

Category Archives: Agile

05 Apr 2020

How can Management benefit from the Scrum values?

This blog is the first in a miniseries related to Agile management topics; all featuring Duck & Birdie as teaser. Today’s topic is the managerial attitude in an Agile environment matched against the Scrum values. Many development teams nowadays use the Scrum values as an important mindset in their daily routine. It makes sense to apply these values also to the organization level above the teams, still the domain of managers. By doing so, I hope to trigger reflection for managers, or anyone involved in steering agile teams, without smoking management out ?

Where does the need for an agile management attitude derive from? In many organizations Agile adoption was a bottom-up movement. A few teams started experimenting with Scrum or XP and soon the Agile oil stain was spreading throughout the organization. Currently, complete organizations are transformed into Agile driven structures from top to bottom and back up again. These organizations, but especially the teams, require a different management style. This is where an agile attitude towards managing teams becomes indispensable. The behaviour I encourage managers to show is on the one hand vision and leadership (including being able to make the necessary ‘judgement calls’). And on the other hand, the ability to create the right climate for teams to self-organize and solve problems. In my experience it is hard for (senior) managers to find a good balance between servant leadership – acting according the Scrum values – and having a more direct / autocratic leadership style. Especially when things get tense and the stakes are high.

Let’s illustrate the difference between servant and direct leadership in an example. If, when and how you intervene as manager – in case a commercially important deadline is under threat of non-delivery – is distinctive. Probably one would say: “It depends”. Yet, it is striking to see how many managers will fall back into ‘old school’ habits of completely taking over, bringing in the well-known-go-to guys (heroes) and demanding daily updates from a team lead. Although there might still be cases where this is the best temporary approach, it comes with a risk. If you don’t coach teams to determine root causes or fail to make sure they learn and come out of these situations in a better shape, a lot of organizational value is unfulfilled. In fact, the exact opposite behaviour is encouraged. The go-to-guys remain the organizational heroes and no one is stimulated to really change something because top down interventions remain the norm.

Applying the Scrum values to the managerial level
Now we take the Scrum values into account. In the said example, Respect and Openness – or the lack thereof – immediately come to mind. Respect towards the teams and professionals (including their agreed upon way of working) and Openness to existing challenges but also to possible solutions. Courage is found in placing your trust in the people to do the right things and to help them to improve. Root causes – in aforementioned case a commercial disaster – are often founded in unrealistic goals from the start or vague promises that were made before the teams were even aware. So, it may take Courage and Commitment to address these as a manager in your own organization. Following the Scrum values may prevent you to fallback into old behavioural ‘steering patterns. Let’s briefly explore three key focus areas of managers.

1. Leading by example. An important managerial aspect is leading by example; show your teams that a promise means something. That the suggestion of you willing to help them is not an empty one. Even better, go the extra mile for your people and teams. Being an example also resonates with being involved. Know what is going on and why. You are aware of the biggest impediments the teams are facing, you also know what the plan is to fix them and what your role is in it. You know this not from a bi-weekly status update from a team lead. No. You know this because you were at the Review, possibly the Retrospective and you got the latest at this morning’s Stand ups. You show Respect for the Scrum framework, Focus on team goals and the Commitment to help and serve them.

2. Defining organizational structure. Defining the actual structure of the organization is a classic management responsibility, including establishing the rules on the development playground. In every organization there are boundaries and contexts that determine the observed self-control or freedom that teams have. It is important to have a clear common understanding on these boundaries and levels of freedom. (See Jurgen Appelo’s delegation poker in Managing for Happiness as a tool to discuss ideas with your teams and establish shared understanding.) This includes making sure the teams have capacity available to improve, to experiment and to work on a learning organization. Openness and Respect of the rules and the process of getting the rules in place, Courage to leave room in packed backlogs and keeping Commitment when situations are tense.
Delegation poker

3. Caring for (managing) people. Show people they matter and that they are the company’s major asset instead of just resources. This means making time for them, enough time. Instead of being always late for personal appointments or worse, cancelling them more than having them. In other words: having Respect and Commitment for the well-being of your colleagues. Sometimes urging people to go home instead of stressing a deadline. It would be great if the leaders of the future coach their teams to act with these values in mind and at the same time allow them to make mistakes. Courage also means to be able to have the ‘difficult talks’ with people and on the other side being transparent about your own mistakes or short comings.

These are just three of the important trades managers need to employ. When you keep the Scrum Values in mind an Agile attitude feels like a natural thing to do. Luckily, I have witnessed a few excellent managerial examples. People that have a genuine interest in people, are a little geeky on technology and have fundamental organizational antennas. Don’t make the mistake to think these men and women were soft. They were honest and clear. Did they make mistakes? Yes, and they were the first to acknowledge this. And that is great Courage!

Duck & Birdie and more comics.

These comics are originally called “Fokke & Sukke” and created by the Dutch team: illustrator Jean-Marc van Tol and writers John Reid and Bastiaan Geleijnse. See: Fokke & Sukke for more information.

If you are looking for more comics on Agile you can check out: Dilbert still struggles working Agile & Dilbert saves the Agile day and see how Dilbert is overcoming it all.

[1] http://www.foksuk.nl/ & https://nl.wikipedia.org/wiki/Fokke_%26_Sukke
[2] https://guntherverheyen.com/2013/05/03/theres-value-in-the-scrum-values/
[3] https://www.scrum.org/resources/scrum-values-poster
[4] https://management30.com/practice/delegation-poker/
[5] https://www.agitma.nl/managing-for-happiness-jurgen-appelo

Download blog as PDF

This blog is available here:

Filled Under: agile,Geen categorie,scrum,software development Posted on: 5 April 2020

01 Apr 2020

Agile Transformeren (Van Solingen ea.)

Wat is Agile transformeren en hoe pak ik dit binnen mijn organisatie aan? Met deze vragen zijn de vier auteurs Bas van Lieshout, Hendrik-Jan van der Waal, Astrid Karsten en Rini van Sollingen aan de slag gegaan. Niet zonder resultaat. Agile transformeren geeft een degelijke beschrijving van een stappenplan en aandachtsgebieden voor een Agile transformatie. Hiermee is het een goed naslagwerk of discussiestarter voor iedereen die zich bezighoudt met Agile transformaties.

Van de vier auteurs is Rini van Sollingen waarschijnlijk het meest bekend onder het grote publiek. Dat kan zijn van een van zijn eerdere boeken zoals De Bijenherder of Agile, als spreker op Agile events, deeltijdhoogleraar of als adviseur bij vaak grotere adviestrajecten. Dat neemt niet weg dat alle auteurs duidelijk hun achtergrond en ervaringen mee hebben gegeven aan hun gezamenlijke werk Agile Transformeren. Een mooie mix van coaching, Scrum, SAFe en HR-achtergronden naast jaren ervaring in het veld zorgen voor een keur aan inzichten en praktijkvoorbeelden.

De opbouw van het boek is eenduidig. Deel A beschrijft de noodzaak tot transformeren, deel B beschrijft het plan om de Agile transformatie uit te voeren en in Deel C worden thema’s behandeld die extra borging behoeven tijdens de transformatie. Deel A is niet het meest spannende deel, toch geven de auteurs hier een interessante inkijk in de drijvende kracht achter de enorme aandacht waar Agile zich al jaren op kan verheugen. Zij beargumenteren dat deze drijvende kracht niet ‘Agile-als modeverschijnsel’ is, maar de verregaande digitalisering en verandering van klantverwachtingen. Deze observatie maakt direct duidelijk waarom een Agile transformatie nooit een doel op zich kan zijn maar slechts een middel.

Het stappenplan in deel B waar zij de lezers doorheen voeren is transparant beschreven. Vanaf het begin is helder dat het een aanpak betreft die uitgevoerd wordt met eenzelfde mindset als opgenomen in de titel van het boek. Agile dus. Het stappenplan biedt voldoende houvast en kaders om de route uit te stippelen, maar gedurende het traject zal het plan gegarandeerd bijgestuurd en aangepast moete worden. De stappen zien er als volgt uit:

1. Transformatievisie: bepaal de scope
2. Transformatievisie: onderzoek de (start)situatie
3. Transformatievisie: communiceer de urgentie
4. Transformatie-executie: maak een bouwschets
5. Transformatie-executie: bepaal de veranderstrategie
6. Transformatie-executie: maak een transformatieroadmap
7. Transformatie-executie: implementeer in korte iteraties
8. Transformatie-executie: meet de voortgang

Het verbaast niet dat het stappenplan veel gelijkenis vertoont met de aanpak van andere veranderprogramma’s. Een transformatie is immers een verandertraject. Verwacht bovendien niet dat je met het lezen van dit boek een recept in handen hebt om één op één in je eigen organisatie toe te passen. Zoals de auteurs keurig melden, zul je je eigen plan moeten maken op basis van de kenmerken van jouw organisatie. Het plan geeft met de stappen en aandachtspunten grofweg de ‘Wat’ en een beetje het ‘Hoe’ weer. Echter, het exacte ‘Hoe nu daadwerkelijk in praktijk’ zul je zelf moeten vormgeven. Wel helpen de cases en de hoofdstuk afsluitende ‘Aan de slag’ lijstjes je goed op weg. Kleine kanttekening is dat – hoewel de ‘Aan de slag’ lijstjes goede suggesties en ideeën bevatten – de suggesties en ideeën vaak one-liners zijn waar dikwijls een nieuwe wereld van vragen achter schuil gaat.

Om de kans van slagen van de transformatie te vergroten worden in Deel C een zevental thema’s besproken die naast de transformatie als zodanig extra borging verdienen. Het betreft een mix van harde en zachte criteria en gezamenlijk geven zij een inkijk in zaken die in de praktijk vaak foutlopen. De borgingsthema’s zijn:

1. Talentontwikkeling
2. Leiderschap
3. Strategische besturing
4. Meten en afstemmen
5. Financiën
6. Compliance
7. Technologie

De uitdagingen op het gebied van Financiën, Compliance en Technologie (thema’s 5, 6 en 7) waren voor mijzelf het meest herkenbaar, gevolgd door Leiderschap en Strategische Besturing (thema’s 2 en 3). Deze vijf thema’s zullen in menig traject tot wrijving en hinder hebben geleid. Het is handig dat de auteurs deel C hebben losgekoppeld van het stappenplan. Dat geeft meer structuur en de mogelijkheid om direct naar een borgingsthema te bladeren als je daar extra aandacht aan wil geven.

Eerlijkheidshalve nog het volgende; vooraf was ik terughoudend om het boek te lezen vanwege de line-up van auteurs. Vier, door de wolf geverfde, Agile professionals allen werkzaam bij een en hetzelfde consultancy bedrijf dat leeft van de inzet van deze consultants en adviseurs. Een verkooppitch leek in de maak. Mijn angst bleek ongegrond; de auteurs geven een goede inhoudelijke beschrijving van hun ervaringen, inclusief de zaken waarmee zij worstelden. Persoonlijk had ik het passender gevonden wanneer het voorwoord wel door iemand van buiten het eigen bedrijf was geschreven, maar dat terzijde.

Conclusie

Voor lezers die werkzaam zijn of zijn geweest binnen organisaties in een transitie zal het boek een feest van herkenning zijn. Ik verwacht dat iedereen minimaal 2 of meer cases zo kan projecteren op zijn of haar eigen organisatie. Dat is niet erg, integendeel zelfs. Het laat zien dat – hoewel geen transformatietraject hetzelfde verloopt en plannen altijd worden bijgestuurd – er veel terugkerende patronen en aandachtsgebieden zijn. Dat geeft Agile transformeren zijn waarde voor de lezers. Ondanks de herkenning, zijn er voldoende aandachtsgebieden en handvatten om mee te nemen in ieder transformatieproces.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl.

Cheers,
– Sjors Meekels

Download blog as PDF

This blog is available here:

Filled Under: agile,book review,Geen categorie Posted on: 1 April 2020

29 Feb 2020

Performance management in een Agile werkomgeving

Waarom is het zo moeilijk om goede beoordelingsgesprekken te voeren? En waarom gaat het zo vaak fout? Hoewel organisaties veel tijd besteden aan de uitvoer en de vastlegging, zijn de betrokken managers en medewerkers vaak teleurgesteld in het eindresultaat.

Er moet inmiddels toch een betere aanpak op het gebied van belonen en beoordelen zijn. In het boek Performance management in een agile werkomgeving geven de drie auteurs, Kilian Wawoe, Maud Schaapveld en Rutger Verbeet antwoord op bovenstaande vragen over performance management en doen zij een voorzet voor een nieuw systeem van performance management.

Ben u wel eens een leidinggevende tegengekomen die uitzag naar de eindejaarsperiode? Vrijwel niemand heeft het maken van beoordelingen en voeren van beoordelingsgesprekken als favoriete bezigheid. Hoe komt dit? Een van de problemen is dat het gewoonweg ontzettend moeilijk is om een eerlijke beoordeling op te stellen. Daarnaast is er nog de kunst van het bespreken van deze beoordeling en een medewerker met het juiste gevoel het gesprek laten uitgaan. De drie auteurs, Kilian, Schaapveld en Verbeet schetsen de geschiedenis van performance management en laten zien waarom organisaties dit proces nooit volledig in de vingers hebben gekregen. Hiermee is Performance management in een Agile werkomgeving geschikt voor iedere HR-professional of leidinggevende die een nieuwe kant op wil met performance management.

Het boek is logisch opgebouwd. In het eerste deel, dat vier hoofdstukken omvat, wordt het klassieke theoretische kader beschreven en komen belangrijke historische stromingen, zoals operante conditionering, de equity -theorie en goalsetting-theorie aan bod. Daarna volgt de ontwikkeling en de toepassing in praktijk van grofweg honderd jaar geleden tot nu. De twee bepalende visies hierbij, de bedrijfskundige- en de mensgerichte visie, worden tegen elkaar afgezet. In het laatste hoofdstuk worden de knelpunten besproken en wordt de noodzaak voor aanpassingen aan het huidige systeem aangetoond.

Deel II van het boek, met drie hoofdstukken, is gericht op een nieuwe invulling van performance management. De auteurs starten met het definiëren van ontwerpcriteria in hoofdstuk 5. Daarna beschrijven zij de taxonomie van het nieuwe systeem dat zij voor ogen hebben. Deze taxonomie bestaat uit 9 deelprocessen en wordt per deelproces afgezet tegen de huidige gangbare werkwijzen. Tot slot wordt in hoofdstuk 7 beknopt een route voorgesteld hoe de invoering van een nieuw systeem eruit kan komen te zien. Het is geen verrassing dat het meest vernieuwende deel van het boek in de hoofdstukken 5 en 6 zit. Een belangrijk inzicht dat de auteurs uitwerken is het splitsen van traditionele rollen die bij één leidinggevende liggen naar het beleggen van deze rollen bij meerdere personen. Hiervoor onderkennen zij 3 rollen (coördinator, coach en rechter) en per rol een drietal processen waarmee het hele performance management afgedekt is. Zodoende trekken zij niet alleen het beoordelen los van belonen maar zorgen zij dat een medewerker:

– gestuurd wordt door reflectie op dagelijks werk (door de rol: coördinator);
– gecoacht wordt op mobiliteit, kennis en vitale (door de rol: coach);
– beoordeeld wordt op zijn werk via onder ander persoonlijke inschaling en benchmarking (door de rol: rechter).

Het onderwerp performance management heeft de afgelopen jaren op veel interesse en aandacht mogen rekenen. Veel organisaties hebben stappen genomen om de eigen systemen aan te passen aan de nieuwe eisen van het Agile werken. Soms met succes, soms met vallen en opstaan, en vaak ook met tegenvallende resultaten. De auteurs hebben voor dit boek een groot aantal professionals van uiteenlopende organisaties gesproken en veel vragen gesteld over de invulling en benadering van performance management en hoe goed deze in de praktijk functioneren. Zij zijn erin geslaagd om ondanks de vele meningen en tegenstrijdige antwoorden, een samenhangend verhaal op te stellen. Een intrigerende observatie is dat met name managers moeite kunnen hebben bij het loslaten van de ‘macht’ van het beoordelen en belonen. Erg interessant, zeker omdat uit alle theorie en ervaringen blijkt dat de huidige systemen voor kenniswerkers echt niet langer voldoen.

Conclusie

In het boek zijn diverse casussen opgenomen waarin verschillende praktijkinitiatieven zijn beschreven. Deze geven de lezer een neutrale inkijk in de benaderingen die organisaties hebben gekozen, zonder dat sprake is van een beoordeling of ‘succesverhaal’ van de auteurs zelf. Voor mijzelf voelde het eerste deel van het boek als een interessant college over de ontwikkeling en opbouw van performance management. De theorieblokken zijn niet te lang en schetsen een goed beeld hoe we zijn uitgekomen op de huidige toegepaste inzichten. Zeker voor (beginnend) leidinggevenden zonder P&O opleiding kan dit deel erg boeiend zijn. Deel II van het boek zal ook HR-professionals inspiratie bieden bij het herijken van de eigen processen. De vraag of de nieuwe taxonomie succesvol zal zijn in de praktijk is nu nog niet te beantwoorden. Wellicht dat de auteurs in een volgend boek hun ervaringen kunnen delen als organisaties met het voorstel aan de slag zijn gegaan. Al met al erg de moeite waard om Performance management in een Agile werkomgeving thuis, zeker nu tijdens de corona-crisis, rustig te lezen en te beoordelen welke onderdelen toepasbaar zijn binnen uw organisatie.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl.

Cheers,
– Sjors Meekels

Download blog as PDF

This blog is available here:

Filled Under: agile,book review Posted on: 29 February 2020

03 Dec 2019

Terminology matters: Agile/Scrum vs CD/CI vs DevOps

Chances are you were triggered by the enumeration of buzz words in this blog’s title. Without effort you could probably squeeze in a few more, like Lean or another flavor of ‘Continuous x’. A lot of managers and teams struggle explaining the company’s meaning regarding these terms. Striking is the absence of a clear and concise understanding of the vocabulary. DevOps is translated into Business involvement, CD/CI is equated to Scrum and Agile is basically a term covering everything. The point is, you need to make sure everyone around you understands what you mean and how the terms relate to your organization’s context. During sessions, I use the diagram above to explain the different angles that Agile / Scrum – Continuous Delivery – DevOps have. In this blog, I will dive in a little deeper and share my thoughts on the terminology and how I explain the nuances and differences.

Agile/Scrum and Continuous Delivery

Agile/Scrum focuses on the ability of teams and organizations to absorb the array of changes that happen while making software. The setup of the Scrum rituals ensures that transparency is present at all times, for the team itself but also for the stakeholders. When functioning well, the Product Owner helps the stakeholders in guiding the product development in the right direction. Adapting change and changing course now and then is part of the normal process. The main aim of Scrum is to deliver as much value as possible working in a sustainable pace [1]. The framework says nothing about how this should be achieved from a technical perspective. Not what tools to use or what platform is appropriate, nor does it mention test automation, infra structure as code or deployment pipelines.

The power of short cycled feedback (highly valued within Scrum) is strengthened enormously when teams can focus on developing the properties of the systems (functional and non-functional) instead of spending time on manual tasks. Manual tasks can include everything from testing code by hand, setting up new environments or executing tedious deployment scripts following a step by step manual. This is the area where Continuous Delivery steps in. Continuous Delivery empowers teams by giving them the tools and methods to automate their process as much as possible and minimize manual labor. Not only does it save time, it also decreases the error rate by eliminating the human factor [2].

Simply stated: by combining Scrum and Continuous Delivery, teams can create a new feature, run automated tests and deploy the new software to environments where validation by business can be done. All covered by a framework supporting transparency, inspection and empiricism at all times.

Continuous Delivery and DevOps

Continuous Delivery is largely based on the technology that enables teams to automate as much of the development process as possible. Traditionally, a handover moment between development and operations was in place when software was finished and accepted. The deployment to the production environment and the responsibility for the quality of service once running was in hands of the operation teams. In DevOps, teams become responsible for the entire chain all the way to production [3]. Technically, the tools and actual deployment on production are not so different than those used on other stages. Having the explicit mandates and authorizations marks the distinction, these include access to production monitoring and logging information.

Often the biggest chasm to cross in a journey towards DevOps is organizing the rights and responsibilities for newly formed DevOps-teams (see “DevOps understanding the Evolution” to have a brief chronological overview of DevOps). This becomes more evident when discussing quality of service. Who is allowed to see how a system is running, how to deal with production data and what information has been logged? Especially large organizations with a history of separated departments and teams for operations and development are discussion prone. If you find yourself in a mandate-discussion going in circles, what can help is the next simple question: Who would be responsible if we only had one team? Clearly, it is only logical that this one team should be in the lead. Barricades often dissolve after discussing why it should be different just because you have multiple teams.

A well-aged mantra reads as follows: ‘if you want to have a stable environment, don’t change it’. This contrasts with the nowadays popular one: ‘fail fast and fail often’. The technology now present – based on Continuous Delivery – enables teams to develop and deploy new software with no or hardly any downtime. Combined with DevOps, teams can take ownership for the entire life cycle of the product. Responsibility only ends when a system is decommissioned.

DevOps and Agile/Scrum

While DevOps ensures that teams are able to take technical and organizational ownership for the quality of service of the products they develop and maintain, the term says nothing about the team dynamics that should be in place to support this responsibility. The other way around is also true, Agile/Scrum makes no mention of different environments or how to address major production incidents. Of course, it is possible to have for example Scrum without DevOps. However, this means you will have a delay in your feedback loop and miss valuable information about the production environment. More importantly, teams that have production responsibility have more insights in the behavior – intended or not – of their system.

Naturally, DevOps requires some additional agreements in a team’s Scrum process. How is monitoring approached (not technical but process wise) or how much time can be spent on improving ‘the run’. By discussing the time spend on monitoring and analyzing the software in production, a more in-depth analysis can be made based on value. These Lean influences from DevOps provide the structure to improve operational excellence as well. For example: ownership and code-logging hygiene go quickly hand in hand when a team has to fix its own production problems. Decision making and prioritization by Product Owners is more coherent in DevOps. The total costs of running a system become more transparent and are influenced more directly by the Product Owner’s team. See “Product Owners in DevOps” to read more on backlog prioritization in DevOps.

Combining the flow and value stream ideas from DevOps with the sustainable pace and delivery of Done increments from Scrum is powerful. Feedback from clients or the business on the latest software can continuously be weighted up against other aspects of running the product.

Conclusion

While it is theoretically possible for teams to use exactly one of the ‘buzz terms’ without the others, it is not common. What I usually see in organizations is a mix of all three. That makes sense, the terms and related concepts focus on team responsibility and share the desire for short feedback loops, build-in quality and transparency towards stakeholders and teams internally. They re-enforce each other and offer opportunities to improve specific parts of an organization’s way of working. That is one of the reasons why you should be able to describe in a concise way what you mean when discussing improvements to your development process.

Cheers,
– Sjors Meekels

Disclaimer: the description above is not complete and it surely is not one hundred percent perfect. It is not meant to be. It is a personal simplification to address the consistency of a set of popular tech-buzz words.

References & recommended reading:

[1] SCRUM – a Smart Travel Companion, Gunther Verheyen
[2] Continuous Delivery, Jez Humble & David Farley
[3] The DevOps Handbook, Gene Kim, Jez Humble i.a.
[4] DevOps: understanding the Evolution: https://www.agitma.nl/devops-understanding-the-evolution
[5] Product Owners in DevOps: https://www.agitma.nl/product-owners-in-devops-what-dominates-your-backlog-urgent-or-important-matters
[6] https://www.linkedin.com/pulse/differences-between-continuous-integration-delivery-versteijnen Pieter Versteijnen (last checked 19-11-2019)

Download blog as PDF

This blog is available here:

Filled Under: agile,continuous delivery,devops,kanban,lean,scrum,software development Posted on: 3 December 2019

19 Nov 2019

DevOps in beweging – Heunks

DevOps in beweging van Jan Heunks is een Nederlandstalig verzamelwerk dat DevOps uit de doeken doet. Raakvlakken met onder meer Agile, Lean en Continuous Delivery komen uitgebreid aan de orde. Voor een allround beschouwing van DevOps, inclusief plaatsing in de huidige organisatiestructuren, is dit boek een uitstekend startpunt.

Jan Heunks laat zijn ervaring met Lean en Lean IT terugkomen in zijn boek ‘DevOps in beweging’. Alleen Lean noemen naast natuurlijk DevOps doet het boek te kort. Het is een overzichtswerk waarbij een veelheid aan zowel technische- als managementontwikkelingen beschouwd door een DevOps-bril.

‘DevOps in beweging’ is opgebouwd uit drie delen, met per deel twee hoofdstukken. Ieder hoofdstuk wordt afgesloten met een korte conclusie en de delen als geheel met een aparte samenvatting. Het boek heeft een soft cover en pagina grootte A4, dit maakt het wellicht wat minder geschikt om zo mee te nemen maar wel prettig leesbaar. Het is jammer dat niet alle figuren even scherp in het boek zijn opgenomen, storend is dit echter niet.

In Deel I legt de auteur uit wat de toegevoegde waarde is van DevOps. Onderdeel hiervan is een korte geschiedenis en de belangrijkste invloeden die geleid hebben tot de huidige denkbeelden omtrent DevOps. Natuurlijk komen de invloeden van Agile software development en Continuous Delivery aan bod. Bij het uitdiepen van de waarde voor de keten en organisatie legt hij de verbanden met Lean (IT & Startup) en beheerprocessen zoals ITIL.

Deel II betreft het theoretische kader van DevOps. De auteur borduurt net als in Deel I voort op Lean & Agile en op bekende werken als The DevOps handbook, The Phoenix Project en Continuous Delivery. De hoofdstukken 3 en 4 vormen zo een stevig gecombineerd kader van relevante management aspecten (o.a. Theory of Constraints, IT-servicemanagement) en technologische principes (o.a. Infra structure as code, Simian Army). Sprekend voor de huidige uitdagingen bij het uitleggen en bediscussiëren van DevOps is het ontbreken van één heldere & geaccepteerde definitie. Paragraaf 4.2 illustreert dit door de gegeven voorbeelden en vergelijking.

Het laatste deel richt zich op de integratie van DevOps binnen organisaties. Helder is dat investeringen gedaan in bestaande processen en structuren vooral niet direct overboord gegooid moeten worden. Nee, DevOps kan prima een logisch opvolgende evolutie zijn van de huidige organisatiestructuur. Wat niet ontbreekt bij het beschrijven van de aanpak binnen organisaties is een DevOps niveau-indeling voor teams (hfd 6). Dergelijke formats, vaak maturity models genoemd, zijn al gemeengoed bij veel organisaties die certificering hebben of gestructureerd verbeteringen willen doorvoeren.

Het is indrukwekkend om te zien hoeveel bestaande vakliteratuur, modellen en theorieën zijn meegenomen in de beschrijving van DevOps. Het geeft hiermee lezers aanknopingspunten vanuit bekende referentiekaders en achtergronden. Dit helpt bij het vaststellen wat DevOps toevoegt aan de eigen organisatie en waar huidige knelpunten kunnen zitten. De veelheid kan echter ook overweldigend zijn, zeker wanneer je alle figuren en tabellen wilt begrijpen of onderling verbinden. Met name de verschillen tussen de theorieën en figuren kunnen het lastig maken, termen worden anders geïnterpreteerd of uitgelegd en het is onmogelijk om alles in één overkoepelend raamwerk te plaatsen. Dat laatste is echter ook geen doel van de schrijver.

Conclusie

Al met al, is het een stevig boekwerk wat een goed beeld neerzet van DevOps. Het is volledig Nederlands, op het Engelse vakjargon na natuurlijk, wat voor sommige lezers de drempel net zal verlagen. Een goede combinatie van management aspecten en technologische invloeden maken dit boek tot een prima startpunt voor het uitdiepen van DevOps voor de eigen organisatie.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl.

Cheers,
– Sjors Meekels

Download blog as PDF

This blog is available here:

Filled Under: agile,book review,devops,lean,software development Posted on: 19 November 2019

24 Oct 2019

Agile zoals het bedoeld is – Christine Karman

Ben je de positieve verhalen en claims over het werken met Agile beu? In Agile zoals het bedoeld is laat Christine Karman een ander geluid horen ten aanzien van Agile werken en met name Scrum. Voor iedereen die Agile werkt kan dit boek een spiegel zijn om kritisch naar de eigen organisatie en Agile invulling te kijken.

Het is goed mogelijk dat de naam Christine Karman bij menigeen een belletje doet rinkelen. In de jaren negentig en zero’s maakte ze nationale bekendheid met de door haar opgerichte bedrijven Tryllian, gespecialiseerd in mobile agents en Izecom, gericht op secure email. Helaas voor Karman waren beide bedrijven geen lang leven geschonken. Met haar boek Agile zoals het bedoeld is is zij terug aan het IT-front en deelt ze haar ervaringen en kijk op het Agile werken.

Het handzame boekje is opgedeeld in 11 korte hoofstukken met een zestal intermezzo’s er tussendoor geplaatst. De intermezzo’s beschrijven persoonlijke ervaringen van de auteur tijdens opdrachten bij klanten of in haar eigen bedrijven. Met 125 bladzijden lees je dit boek in één avond rustig uit. Ieder hoofdstuk richt zich voornamelijk op één concreet onderwerp. Het boek start met de geschiedenis van Agile, het ontstaan van Scrum en zoomt in de hoofdstukken daaropvolgend steeds meer in op het Agile werken zelf en wat hiervoor nodig is.

In veel organisaties lijkt de implementatie van Scrum meer een doel te zijn geworden dan een middel om slagvaardiger software te kunnen realiseren. Hierin heeft de auteur zeker een punt. Niet alle projecten of software ontwikkeltrajecten zijn hetzelfde en niet alle Agile frameworks zijn even passend. Een van de pijnpunten die Karman meerdere keren benoemt, is het gewillig volgen van opgelegde patronen (bijvoorbeeld de Scrum rituelen, kortom: de vergaderingen) zonder de achterliggende waarde hiervan te benutten. De vraagt die rijst: ligt dit aan de organisatie, de implementatie van Scrum of aan Scrum zelf? Karman lijkt de oorzaak voornamelijk bij Scrum zelf te plaatsen.

Op de vier principes die Karman noemt voor effectief Agile werken, is niet veel af te dingen. Het betreft: (i) stop met vergaderen, (ii) werk met multidisciplinaire teams, (iii) kies voor continuous delivery en (iv) maak het team de baas. Echter, in de praktijk zijn deze principes niet eenvoudig te realiseren. Dit wordt in het boek alleen niet nader uitgediept. Het hoofdstuk dat mij het meest aansprak, was hoofdstuk 8. Hierin beschrijft de auteur een verfrissend voorbeeld van een projectstart – efficiënt en met het team direct in de lead. Begin je project met een eendaagse startup hackathon! Alle betrokkenen van het project doen mee en aan het einde van de dag wordt het resultaat gedeeld en besproken. Een ludieke werkvorm om iedereen te laten kennismaken en de eerste ideeën uit te wisselen. Bovendien geeft het een enorme energieboost voor de deelnemers.

Mijn persoonlijke kanttekening bij de stellingen en voorbeelden is de ervaring dat in praktijk niet alles vanzelf goed gaat als teams en mensen worden vrijgelaten. Met name in grote organisaties is niet iedereen beschikbaar, niet iedereen even goed (of zelfs goed genoeg) en werkt niet iedereen goed samen. Bovendien, hoe groter teams of projecten worden hoe meer behoefte er is aan een helder minimaal proces dat voor iedereen bekend is. Dit doet niets af aan het willen streven naar een zo simpel mogelijk ontwikkelproces zoals de auteur voor ogen heeft. Echter in mijn ervaring kom je met alleen ‘ongeplande koffie overlegjes’ niet tot het gewenste resultaat. Sturing, coaching en soms zelfs vergaderen, is noodzakelijk.

Conclusie

Door de stevige uitspraken die de auteur doet is Agile zoals het bedoeld is een prikkelend boek. Met name ‘Scrum puristen’ zullen het niet altijd eens zijn met de uitspraken. Toch kan juist voor deze groep het boek stimulerend zijn omdat je wordt gedwongen na te gaan waarom je het niet eens bent met de auteur. Is dit afhankelijk van de context of ben je het fundamenteel oneens? De auteur dwingt je om je eigen Agile fundament opnieuw kritisch te beschouwen.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl.

Cheers,
– Sjors Meekels

Download blog as PDF

This blog is available here:

Filled Under: agile,book review,scrum,software development Posted on: 24 October 2019

07 Jun 2019

DevOps: understanding the evolution

Many organizations find themselves somehow confronted with the need to change the way their teams are organized and operating. Echoing in the hallways is this idea of DevOps. It sounds promising and has a lot of common ground with Scrum, which organizations are already familiar with. Moreover, it is drenched in Agile thinking. This blog is the first of a few concerning DevOps. In this blog I’ll describe an organizational evolution which frequently ‘’happens” to IT organizations in their journey towards DevOps. Which phase is your organization in and what is there to gain and overcome?

Definitions

Before jumping into the evolutionary path, let’s spend a minute chewing on three DevOps definitions.

DASA: “DevOps is a cultural and operational model that fosters collaboration to enable high performance IT to achieve business goals.” [1]

Humble: “a cross-disciplinary community of practice dedicated to the study of building, evolving and operating rapidly-changing resilient systems at scale.” [2]

Len Bass et al. “a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production, while ensuring high quality” [3]

As you can see, the definitions have some overlap but aim their focus differently. The term DevOps has not one clear and uniform definition that is shared in the community. Therefore, it is a good practice to find some common ground before starting any discussion on DevOps in your own organization. For now, it is good enough to have a feeling of what a definition could look like.

1. Pre-DevOps: Scrum teams

Scrum is still the most widely applied framework which is used to organize software development teams. There is no need to differentiate in level of maturity or quality by teams using this framework. In this phase, teams just focus on getting their next Increment of Done software ready and possible even release it. In the team all capabilities to get the software Done should be present, for example designing, programming, testing & even appropriate documenting. However, these are all capabilities and not roles and they are preferably not tight to only one person. All members are simply called developers and there is a chasm between teams and production environment.

COMMON CHALLENGES: managing external dependencies, including limiting waiting times and hand-overs to other departments for deployments.

2. Pre-DevOps: CD/CI

Since the Continuous Delivery (& Integration) revolution was ignited by Jez and Farley in 2010, a lot more attention is paid to automate and integrate, test execution, deployments on pipelines and feedback loops. The availability of tools that could execute and monitor these activities via – more or less – user friendly interfaces helped getting momentum. In this phase teams are able to deploy much faster and more reliable to different stages. The long-winded deployment manuals become something of a quickly forgotten past, instead the teams are empowered with new tools.

COMMON CHALLENGES: setting up reliable pipelines, changing existing software with CD in mind, depending on the team that supports the pipeline tooling and operator who execute the deployments to production.

3. DevOps round I: Functional Operations

Coming from the previous phases, teams have a rhythm of delivering working software. They should start to live by the mantra “You build it, you run it”. Teams become more interested in the health and status of the production environment. That is an excellent reason for reaching out to Functional Operations to obtain this – more business – side of the software. New questions arise. How is the software used? Which features are the most valuable ones? What is the logging or monitoring of the production environment telling us? The usual approach to enable this organizational need is by extending the existing delivery teams with people who have this Operational role. Often these people come from a more centrally organized department. In doing so, the teams receive more responsibility in the shape of team members who are authorized to see certain data on production and who have in-depth knowledge of how the software is being used. This Functional Ops-role is embodied by an Ops-Engineer who joins the teams.

COMMON CHALLENGES: embedding the Functional Operators in the team (and not creating a split team), getting the required rights available for more team members, getting all the information from production to the team e.g. logging and monitoring information.

4. DevOps round II: Technical Operations

Once organizations have more than a few development teams, there are usually also some supporting teams around. The latter teams are usually specialized in the infrastructural layers of the software solutions: development machines, testing environments, disk management and operating systems are all good candidates. If such a central team or department is in place, this team is often responsible for the deployments of new software into production. But, the newly empowered teams in phase 2 or 3 have no such need anymore. More importantly, the teams themselves have the technological means to get their new Increment deployed on any stage or server that is required. The next question usually follows very soon: “Who is now allowed to perform the deployment to the production environment?”. This task had been one of the most eminent examples of the segregation between Dev & Ops, but is in this phase integrated into one.

COMMON CHALLENGES: again, embedding new people in the team, especially when mindset between Dev & Ops are colliding.

5. Post-DevOps: BizPerfSecDevOps?

In order to make teams more and more self-supporting, they need other capabilities, either technical or more business oriented. Depending on the nature of the business and – again – the size of the organization, any of the following experts’ roles could be eligible for the team: DB-admin, security expert, platform engineer, performance engineer, UI/Interaction designer, SEO specialist, business expert.

COMMON CHALLENGES: which extra responsibilities are helping teams to create more value versus which capabilities should remain separate?

Conclusion: How to evolve?

From an organization view point any of the phases described above is just one of the almost infinite amounts of possibilities to get organized. Take a step back and see how your organization is just a collection of people, with skills, tools, tasks, responsibilities and mandates organized in a particular way. We aim to come up with the exact organization that is able to create the most value. In the evolution above there is an ongoing shift in roles and responsibilities to and from teams. The context of the team is very much leading in getting the optimum setup. Longstanding organizational setups and existing boundaries are often hard to get by.

One way of thinking more out of the box is by raising the question: “What if we only had two teams?” or even better “What if we only had one?” This forces you to elaborate on who is allowed to do what and why. This question is applicable in all phases, yet becomes paramount in the last one. Last but not least: don’t get stonewalled by the existing organizational structures and boundaries.

In the next blog – “Terminology matters: Agile/Scrum vs CD/CI vs DevOps” – I will focus on the above used terminology in depth.

Cheers,
– Sjors Meekels

Notes:
1. The aforementioned common challenges are by no means complete.
2. Furthermore, being in a next phase does not exempt you from keeping attention to practices of previous phases (e.g. Scrum).

References & recommended reading:

[1] DASA: DevOps Fundamentals_Glossary_English
[2] https://theagileadmin.com/what-is-devops/
[3] Bass, Len; Weber, Ingo; Zhu, Liming (2015). DevOps: A Software Architect’s Perspective.
[4] Scrum a Pocked Guide, Gunther Verheyen
[5] Continuous Delivery, Jez Humble, David Farley
[6] The DevOps Handbook, Jez Humble, Patrick Debois a.o
[7] DevOps for Developers, Michael Hüttermann
[8] The Phoenix project, Gene Kim, Kevin Behr a.o.

Download blog as PDF

This blog is available here:

Filled Under: agile,devops,scrum,software development Posted on: 7 June 2019

27 Mar 2019

Scrum a Smart Travel Companion – Verheyen

In the last 20 years Scrum has proven itself to be the market standard framework for organizations working Agile. Despite this tremendous success many organizations still find themselves in the middle of an Agile transition. The Scrum beginner and professional both have an ongoing need for a short descriptive overview of the framework. For both target audiences the book “SCRUM a pocket guide – A Smart Travel Companion” is a useful tool in the world of Scrum.

The first version of this book appeared in 2013. Now, six years later the second edition has arrived. It has been polished a little bit and the cover also has had a makeover. The overall appearance is a bit larger in the second edition, but this makes the reading easier and holding the book handier. Verheyen is still affiliated with scrum.org and very active in the Scrum field. He is a well-known trainer, author and consultant.In roughly 90 pages he directs the reader in four distinct chapters from the root of scrum to the rules of the game itself, followed by the application of the latter. The book concludes with a short consideration on the future state of scrum.

Chapters:
1. The Agile paradigm
2. Scrum
3. Tactics for a purpose
4. The future state of Scrum

The need of leaving behind the old way of working is combined with the start of Agile thinking in chapter one. Without rambling Verheyen paints a clear picture of the biggest challenges and problems when transitioning into an Agile way of working. Especially the firm statements on Agility not being an end-state are refreshing.

In chapter 2 the author positions Scrum as a game with the intent to maintain control over the software delivery process in complex environments. As with other games, ground rules are in place to be followed by all participants. Whilst the rules aren’t many, it requires a great deal of discipline of the players to adhere to them. The reward of the rules and discipline is an unleashed flow of motivation, self-steering and problem-solving capabilities within Scrum teams.

Practical – and for many readers possible an eyeopener – are the examples in chapter 3 covering mandatory rules versus possible usage of good practices. The team’s freedom to choose and experiment with these practices provides insights in the power and adaptability of Scrum. Even the more seasoned Scrum professionals sometimes assumes that certain topics are prescribed and must be followed. Just because they have seen these in other teams or organizations. Verheyen meticulously explains the placement of the boundaries of the rules next to the fields of options and practices in the game.

At the end of chapter 3 a few paragraphs are dedicated to the scaling of Scrum in larger setups, like for multiple teams or products. Surprisingly common scaling frameworks like DAD, SAFe and LeSS are absent. Even Nexus Scrum.org’s own initiative to join the scaling frameworks is still not mentioned. Although the ideas and patterns described are almost identical to that of Nexus. Perhaps this was a conscious decision. A choice that does keep the focus solely on Scrum.

In the final chapter he provides a short perspective on the evolution of Scrum in organizations in the – near – future. Upstream, as he describes, Scrum has the potential to rise above development teams and come in use within management, product development and eventually in entire organizations.

Conclusion

The book is a swift read and on occasion touches other Agile frameworks. The true value of the book is its strong focus on the rules of Scrum. Due to the concise writing it is very suited for both the beginning Scrum enthusiast as well as the more experienced professional or manager who is looking to refresh the knowledge at his fingertips. The book has been around a few years already, yet it is still one of the first books I would recommend for people diving into Scrum! You can finish it easily on a slow night and provides enough thoughts to bring to the job the next day.

Cheers,
– Sjors Meekels

Download blog as PDF

This blog is available here:

Filled Under: agile,book review,scrum,software development Posted on: 27 March 2019

12 Feb 2019

Het SCRUM Modellenboek

‘Het SCRUM modellenboek’ levert datgene wat de titel uitdraagt. Een verzameling modellen die goed toepasbaar zijn in omgevingen waarin Scrum gebruikt wordt. Rik van der Wardt heeft 41 meer en minder bekende modellen verzameld, beschreven en gebundeld in deze uitgave. Zijn doelgroep bestaat naast Scrum Masters in principe uit iedereen die met Scrum of een andere Agile organisatievorm in aanraking komt, zowel binnen als buiten de IT.

In “Het SCRUM Modellenboek” schotelt auteur Rik van der Wardt de lezer een bord vol nuttige modellen voor die gebruikt kunnen worden bij het werken in Agile teams. Laat je niet misleiden door de titel die wellicht het zwaartepunt legt op Scrum. Verreweg de meeste van de modellen zijn in algemeenheid geschikt voor het werken met teams en zeker in een Agile omgeving. De auteur komt zelf overigens niet direct uit de IT maar is werkzaam voor met name niet-IT-organisaties.
Waarom is dit boek handig? De theoretische basis van Scrum, gecodificeerd in de 19 pagina’s tellende Scrum guide, is zeer beperkt. Dit kan de indruk wekken dat het toepassen van Scrum eenvoudig is. Niets is minder waar. Juist het invullen van de ruimte die dit framework biedt is een van de meest uitdagende zaken bij het inzetten van Scrum. Bij het tackelen van die uitdaging kan dit werk gebruikt worden. Of het nu de rituelen, het teamspel of de interactie met management betreft, er is een model voor handen om je te helpen.

Dan de indeling van het boek. In de korte inleiding wijdt de auteur een aantal alinea’s aan de oorsprong en kracht van Scrum. Hierna volgt een schematische weergave van de modellen op Scrum-rollen en -rituelen zodat de lezer gericht op onderwerp of interesse door kan bladeren naar een bepaald hoofdstuk. De opbouw van de hoofdstukken en dus modellen volgt een vast patroon. Eerst wordt het doel van het model geformuleerd gevolgd door gebruiksvoorbeelden. Deze gebruiksvoorbeelden zijn geschreven in het format: Als een Wil ik Zodat ik . Een leuke knipoog naar de wijze waarop User Stories vaak worden opgesteld. Hierna wordt het model in meer detail toegelicht, in totaal trekt de auteur 4 pagina’s uit per model. Dit maakt dat je als lezer snel een idee hebt over de toepassing en inzetbaarheid. Wil je meer weten dan word je op weg geholpen door een aantal referenties ter afsluiting.
Een persoonlijke greep uit de modellen om een indruk te geven. Voor alle Scrum rituelen is er in ieder geval één model beschikbaar in de vorm van een checklist. Zo zijn de meest voorkomende valkuilen afgedekt en de mechaniek van de rituelen geborgd. Natuurlijk zijn bekende teammodellen aanwezig zoals: de teamrollen volgens Belbin, het Johari-venster van Ingman & Lyft en de pyramide van Lencioni. Erg handig als je op zoek bent naar invalshoeken om de samenwerking in teamverband te versterken.

Er is ook plaats voor Nederlandse inbreng in het boek, met name op het snijvlak met management. Zo is model 3 gewijd aan het Scrummen van je Strategie. Hierbij zet de auteur de feedback loop in van Sjors van Leeuwen om management in staat te stellen een wendbare strategie voor het bedrijf op te stellen. In model 19 wordt Management 3.0 van Jurgen Appelo, ingezet om een toepasselijke managementstijl te ontwikkelen. Hierbij worden tevens dwarsverbanden gelegd met andere modellen in het boek.
Een tweetal modellen die voor mijzelf nieuw waren zijn GROW-coaching (model 13) en SOAR (model 32). De eerstgenoemde kan ingezet worden voor doelgerichte coachinggesprekken op individuele- of teambasis. Wanneer je het acroniem uitschrijft krijg je zicht op de verschillende stappen en zie je direct de focus op het behalen van een resultaat (Goal, Reality, Options, Way forward). Het heeft vooral naamsbekendheid gekregen door het boek van Whitmore in 1992 Coaching for Performance. Ook SOAR betreft een acroniem, Strenghts, Opportunities, Aspirations en Results. Dit model is prima geschikt als kapstok voor een retrospective. De nadruk wordt gelegd op de sterke punten van een team en het uitbouwen van deze punten door ze te koppelen aan concrete acties.

Conclusie

Het Modellenboek leent zich prima als inspiratie voor de beginnende Scrum enthousiasteling. Maar ook voor de ervaren Scrum-professional zullen er voldoende interessante modellen inzitten die direct toepasbaar zijn in het dagelijkse werk. Natuurlijk zijn niet alle modellen nieuw en toegegeven, sommige modellen (checklists) zijn wellicht wat ‘licht’ om echt als model geclassificeerd te worden. De kracht en toegevoegde waarde van het boek zit hem echter in deze enigszins bonte verzameling en het feit dat de meeste modellen breder kunnen worden toegepast dan alleen bij Scrum!

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl.

Cheers,
– Sjors Meekels

Download blog as PDF

This blog is available here:

Filled Under: agile,book review,scrum,software development Posted on: 12 February 2019

08 Feb 2019

Dilbert still struggles working Agile

In my previous blog featuring Dilbert in 2016 – Dilbert saves the Agile day – we elaborated on a few of the challenges he encountered. Now 2,5 years later, new ones have arrived. That is why I have made a short selection of observations I had in the area of Agile team management. Let’s continue our journey and see how DevOps and Agile are working out for our friends…

‘One Dilbert still says more than a thousand words.’

1. Not my job

Two of the pillars in the Agile universe are autonomy and ownership of teams. With great power comes great responsibility. So, when you are part of a DevOps team and you have the responsibility for a production environment, you should know its health. Good teams will take the necessary steps to get the information needed and act upon it. However, this philosophy is not only applicable for teams. It is also true for Scrum Masters, Product Owners, Team Manager or any other role. For example:
– Scrum Masters should know when the team is feeling down or is experiencing difficulties in its delivery process.
– Product Owners should know, which features are being used and how the accumulated technical debt will impact future development.
– Team Managers should know the top three impediments their teams are facing and where they need help.
The fact that sometimes you simply don’t know, is not bad in itself. As long as you perceive this as an indication to get informed. “I did not know” is not an excuse, it is your job to know.

2. Who actually need good engineers?

Although the percentages are perhaps steep, bottom line is that I have seen this a few times in practice. It requires strong leadership and vision on skill and people development to keep your employees in shape. This responsibility works both ways. In my opinion, employees should be equally accountable for their personal development. As part of a good feedback cycle from peers and managers, people should develop a fair insight in their own capabilities. Companies and departments are in trouble when management attention is lacking or is too weak. In that case you are at risk of employing workers with deteriorating skill sets that have less and less value. Developing a continuous learning culture is vital in software companies who are rapidly moving from Scrum to DevOps and beyond. I would like to see teams, Scrum Masters and managers team up for this challenge!

3. That’s just not Agile

At times you find yourself being part of a discussion that doesn’t seem to make sense while the people surrounding you seem to think otherwise. A topic I find particularly intriguing is the popular phrase “That is not Agile”. It is like you can silence all questions or discussions with that one line. I am a strong believer in the Agile way of working. However, at times you need to understand that change – especially cultural change – does not happen overnight but requires small steps. It is not a terrible thing if some stuff does not feel a 100% Agile, yet. For example, it can be very fruitful to have that extra check or coordination in place when lots of teams are involved in releasing a new software version. I favor the idea of experimenting and enlarging team’s autonomy. Especially when team basics are in place and embedded in the right organizational conditions (that last part is not meant as rigid as it may sound). Remember, being Agile is not a goal in itself, it remains a means to an end.

4. Please don’t use that language here

“My manager has absolutely no idea what I am doing all day” it is not the first time that I have heard that sentence. It is part of a recurring discussion I have with Scrum Masters, engineers and my fellow managers. How much knowledge, insight and hands-on experience does a manager need in order to lead a group of well-trained engineers? I don’t dare to think that there is only one truth, as always it probably depends. Without speaking too much to the choir, I can only elaborate on my own experiences as a manager and Scrum Master. It has helped me a great deal that I have a technical background. On the other side I have seen some talented colleagues without any technical background, working outstanding without any problems. Technical background or not, teams have their own responsibility in transparent communication; they have to be able to explain what they are doing and why it is important. And not only in bits, bites and flurm but also in a comprehensive manner so Product Owners, customers, users, business colleagues and managers are well informed.

5. Agile strategy in place, check

As all companies seem to be going Agile it is normal that employees need information on the actual changes in their company. Whether you are introducing Scrum or trying to move to DevOps, people will want to know what the impact is going to be. What does it mean for my role, my team or my career path? The people – or team – in charge of the change should be able to explain the new expectations towards the teams and individuals. What are the responsibilities, tasks and accompanying authorizations? Even more interesting, how is the balancing act envisioned of team freedom & mandates on one hand and organizational governance on the other. The expressed desire to make teams more autonomous often contrasts with un underlying basic lack of trust. As a result, in practice teams are not being allowed to act autonomously. It all comes down to breaking free from previously existing structures and organizational boundaries. A major shift has to be made in the managerial aspects of leading teams and delegating decision making to teams.

Many companies are well under way in their Agile journey. At times it proves to be difficult and challenging. Thank God Dilbert is here to make us laugh along the way…

Cheers,
– Sjors Meekels

Copyright:
[1] DILBERT © 2019 Scott Adams. Used By permission of ANDREWS MCMEEL SYNDICATION. All rights reserved.
[2] DILBERT © 2018 Scott Adams. Used By permission of ANDREWS MCMEEL SYNDICATION. All rights reserved.