interim management

Category Archives: Interim management

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.

Download blog as PDF

This blog is available here:

Filled Under: agile,interim management,scrum,software development Posted on: 8 February 2019

09 Mar 2018

Lean in de Logistiek – Schuurmans / Plas

In Lean in de logistiek bundelen Esther Schuurmans en Caroline van der Plas hun kennis en ervaring in de wereld van lean implementaties. Hoewel de titel zich specifiek richt op de logistieke branche, leent het werk zich prima voor een bredere kijk op het thema. Met een kleine tijdsinvestering heb je zo een verfrissing van je lean kennis en een voorbeeld implementatietraject gezien.

Esther Schuurmans en Caroline van der Plas hebben veel ervaring in kwaliteitssystemen, lean, en logistieke omgevingen. In dit gezamenlijke handboek Lean in de logistiek bundelen de auteurs hun krachten en geven zij een beknopt overzicht van wat lean organisaties te bieden heeft. Het is een to-the-point beschrijving waarvoor geen specifieke voorkennis of ervaring benodigd is.

Het boek is opgedeeld in drie overzichtelijke delen. Kort gezegd beschrijft deel 1 de uitgangspunten en de belangrijkste onderdelen de je van lean moet weten om de rest van het boek goed te kunnen begrijpen. In deel 2 worden handvatten gegeven voor de implementatie van lean in organisaties. Het laatste deel bespreekt een praktijkcasus op basis van de werkzaamheden van de auteurs bij Docdata.

Deel 1: Wat moet je weten over lean (blz. 17 t/m 62)
Geen boek over lean zonder een korte introductie in de achtergrond en geschiedenis. In vogelvlucht worden de belangrijkste begrippen aangestipt die nuttig en nodig zijn om de rest van het boek op waarde te kunnen schatten. Het is mooi dat de auteurs ook stilstaan bij de drie stakeholders van lean implementaties, zodat duidelijk is dat je een lean implementatie niet alleen doet voor je klanten. Het tegengaan van verspilling is een van de bouwstenen van lean, dit kunnen herkennen en verminderen zijn belangrijke eigenschappen die binnen organisaties ontwikkeld moeten worden. Als laatste wordt het neerzetten en uitbouwen van een lean cultuur besproken.

Deel 2: Hoe implementeer je lean in jouw organisatie (blz. 63 t/m 112)
In dit hoofdstuk delen de auteurs de TROTS-aanpak die zij hebben gedefinieerd. De aanpak staat voor Toewerken naar, Resultaten op, Operationeel, Tactisch en Strategisch niveau. Het aardige aan deze aanpak is dat deze wordt opgehangen aan het lean huis en tevens een de link wordt gelegd met de verschillende niveaus waarop naar organisaties gekeken kan worden. Daarnaast worden verschillende lean tools zoals S5, Value Stream Mapping en bijvoorbeeld A3, qua toepassing en effect in detail besproken.

Deel 3: Praktijk (blz. 113 t/m 151)
De praktijkcase die in het derde en laatste hoofdstuk centraal staat, is gebaseerd op de ervaringen van de auteurs die zij in de periode vanaf 2010 bij Docdata hebben opgedaan. De naam Docdata is voor velen waarschijnlijk een onbekende. Dat verandert waarschijnlijk wanneer je hoort dat zij de grootste dienstverlener in e-commerce was in 2015 en optrad als een belangrijke partner van bijvoorbeeld Bol.com in de logistieke afhandeling van orders. Inmiddels is Docdata een onderdeel geworden van het internationale INGRAM MICRO Inc. De auteurs beschrijven welke lean methoden zij hebben ingezet en welke resultaten deze hebben gebracht om de groei van het bedrijf te ondersteunen. Er is bijvoorbeeld gestart met 5s en het inrichten van teamcorners om informatie zichtbaar te maken voor teams (Visual management). In dit hoofdstuk maken zij een heldere connectie met de theorie en implementatie strategie uit de vorige hoofdstukken. Natuurlijk ontbreken ook de resultaten van het traject niet.

Kleine noot aangaande de eindredactie; de afbeelding op blz. 76 heeft mij even doen twijfelen over bullets 1, 2, en 5. Het blijkt echter dat de verkeerde afbeelding in het boek is terecht gekomen. Geen zorgen, negeer de afbeelding en richt je op de tekstuele uitleg. Wil je per se de juiste afbeelding hebben? Ga dan naar de website van leanindelogistiek.nl/formats om deze, en eventueel ook andere afbeeldingen, te downloaden.

Conclusie

Lean in de logistiek is compact vormgegeven en bevat een aantal kleurrijke foto’s en afbeeldingen met quotes en/of diagrammen. Persoonlijk vond ik de leukste quote: ‘Alleen ga je sneller samen kom je verder’. De quote raakt voor mij echt de kern van het werken in team- of organisatie verband. Ook een lean implementatie zal je nooit alleen kunnen doen. Kort samengevat: het boek is geen zwaar leesvoer en laat zich rustig in een paar uurtjes doorlezen, prima investering!

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl, meer informatie over het boek of de auteurs is te vinden op leanindelogistiek.nl.

Cheers,
– Sjors Meekels

Download blog as PDF

This blog is available here:

Filled Under: book review,interim management,lean Posted on: 9 March 2018

17 Sep 2017

Alles draait om verandering – Edwin Tuin

Redenen voor organisatieveranderingen zijn er genoeg en de gevraagde verandersnelheid moet verder omhoog. Hoe krijg je dit binnen je eigen organisatie voor elkaar? In het boek Alles draait om verandering beschrijft Edwin Tuin zijn model om organisaties te helpen veranderen. Zijn veranderwiel stelt organisaties in staat om met nieuwe ogen naar verandermechanismen te kijken.

Edwin Tuin heeft zijn jarenlange ervaringen in veranderprocessen gebruikt om een eigen kijk op veranderen te creëren. Vormgegeven in zijn veranderwiel, biedt hij managers een concreet verfrissend mechanisme om veranderprocessen te borgen in bestaande organisaties. Alles draait om verandering bouwt verder op bestaande inzichten en legt verbanden met stromingen als Lean en Agile.

Hoofdstuk 1 & 2
In de eerste twee hoofdstukken bereidt de auteur de lezer voor op het nut en de noodzaak van organisaties om te veranderen. In een vlot tempo komen maatschappelijke onderwerpen zoals duurzaamheid en vergrijzing voorbij en is het duidelijk waarom organisaties wendbaarder moeten worden. Dit blijkt geen eenvoudige opgave. Bestaande strategieën passen niet meer en de klassieke organisatiemodellen maken plaats voor alternatieve, meer vloeiende, structuren. Alhoewel veranderen niet eenvoudig is, kan iedereen het leren. Het devies van de auteur is om het vooral veel te doen.

Hoofdstuk 3 t/m 6
In de hoofdstukken drie tot en met zes draait het volledig om het model. Tip: blader door naar de start van hoofdstuk 8 voor het schematische overzicht van het volledige veranderwiel. Hiermee vallen de verschillende onderdelen makkelijker om hun plaats. Na een korte algemene introductie start Tuin bij de binnenband. De vier kerndrivers in de binnenband zijn verlangen, vertrouwen, verantwoordelijkheid en vermogen. Alle vier moeten versterkt worden en haken rechtstreeks in op de strategie en cultuur binnen bedrijven. Herkenbaar uit de praktijk; voor veel organisaties zal met name de kerndriver ‘vermogen’ een belangrijk aandachtspunt zijn. Redenen om te veranderen zijn er helder, vertrouwen is aanwezig en de medewerkers willen verantwoordelijkheid nemen. Echter de daadwerkelijke veranderkracht – het vermogen om te veranderen – ontbreekt.

Vanuit de binnenband komen de ideeën – projecten – naar boven die nodig zijn om veranderingen in te zeten. Vervolgens bespreekt de auteur de zogenaamde loops die vanuit de as van regie en roadmap de verbinding vormen tussen de binnen- en de buitenband. Deze loops dienen om de nieuwe ideeën te toetsen en te verbeteren. Passen deze ideeën bij lopende initiatieven en zijn alle voorwaarden aanwezig om tot een succes te komen? Om dit proces handen en voeten te geven is een Verander Assessment Groep nodig die als werkgroep verantwoordelijk is voor de borging en aansluiting van de ideeën op de kerndrivers. Daarnaast schets het boek een Verander Monitor Board die zorgt voor de uitlijning van andere bestaande programma’s of lopende projecten en voldoende managementsupport.

De directe aansluiting van de nieuwe ideeën op de dagelijkse praktijk is voorzien in de buitenband. Hier komen de vraagstukken bij elkaar en wordt helder welke implicaties er voor de organisatie zijn. Het model als geheel heeft een dynamische opzet waardoor een vaste volgordelijkheid geen vereiste is. Zo kan het nuttig zijn om één loop meerdere keren achter elkaar te doorlopen of om een stap terug te zetten naar een vorige loop. De volgordelijkheid zal per organisatie en situatie verschillen. Voor de invoering van het veranderwiel gebruikt de auteur in hoofdstuk zeven een aantal scenario’s waarmee organisaties zich snel kunnen identificeren. Dit zijn bruikbare strategieën om concreet met een invoer aan de slag te gaan.

De auteur hanteert een actieve schrijfstijl waarin zijn gedachten, tips en voorbeelden elkaar snel opvolgen. De rode draad blijft het veranderwiel en de nadere uitleg van het veranderproces in de elkaar opvolgende hoofdstukken. Het is aan de lezer om de inzichten te plaatsen in zijn eigen kader en de meest nuttige en toepasbare hieruit te destilleren. Het is praktisch onmogelijk om het met alle uitspraken van de auteur eens te zijn. Maar dat is ook zeker geen voorwaarde. Juist de stelligheid van enkele uitspraken geven de lezer de kans zich te spiegelen en na te denken over alternatieven en eigen inzichten.

Conclusie

Het boek is toegankelijk geschreven en bevat diverse verwijzingen naar bekende namen uit de literatuur zoals Sinek en Semler. Of je het veranderwiel nu als mechanisme gaat invoeren of het als gedachtenexperiment gebruikt, er zitten genoeg handvatten in om met een frisse blik naar het veranderproces in de eigen organisatie te kijken. Hiermee is Alles draait om verandering een prima praktische start voor iedereen die zijn organisatie wil veranderen of het veranderproces wil veranderen. De quote op de kaft om het boek tevens alomvattend te noemen, is wellicht een stap te ver.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl, meer informatie over het boek of de auteurs is te vinden op victalis.nl.

Download blog as PDF

This blog is available here:

Filled Under: book review,interim management Posted on: 17 September 2017

14 Nov 2016

Must I Do This Now? In an Agile context

Over the years, I have worked with many teams within organizations moving from left to right in constant change. People from all places are targeting Engineers and other team members with ad-hoc questions or small assignments. Of course, in Agile environments Product Owners and Scrum Masters should be there to shield part or most of these interruptions. Yet, that is not always possible. The result is people who get distracted and are not confident about priorities. This is only a ‘big’ problem when there is more work to do than is possible timewise. So that is pretty much anywhere. Hence, we have to prioritize to keep ourselves and our teams focused. The mnemonic ‘Must I do this now’ can help you redefine your priorities.

Must I do this now?

There is a lot of power stored in this little sentence constructed out of 5 words. Let’s play a game and change the emphasis 5 times in a scenario where someone asks you to do something right now. See what happens to the meaning of the question and how it can help you redefine your priorities. In each case I’ll reflect on the way the question should be answered in an Agile context.

1. [MUST] I do this now?

Is the chore or question really necessary? People working in projects are used to MoSCoW [1]. I reuse that idea: if it is not a Must you probably should not do it. Often you immediately know if something is that important or just a nice thing to have.

In Agile: In using Scrum or Kanban, you can check the current Sprint Backlog or Work in Progress and verify that nothing in there is less important than the new chore at hand. In case you are doubting, the Product Owner should be there to help you decide. Do not hesitate to ask for clarity or advice.

2. Must [I] do this now?

During your day you might receive a lot of questions. For some people asking something is even second nature to them. Often easier than thinking or solving a problem by themselves. Well, your time is valuable as well. The next step is to rethink if you are indeed the best person – or the only person – that is capable of handling this request. Perhaps the requester or another colleague is equally equipped.

In Agile: Teams should be able to handle all the tasks and preferably all skills are shared and well distributed among the team members. At least there should be someone else – besides you – capable of responding to the request. If someone else is looking to pick up something new and he or she is capable you don’t need to interrupt your current task. This will help you to stay more focused.

3. Must I [DO] this now?

Before rushing into solving mode or chasing a problem, check out what the best modus operandi would be. What would solve the request? Sometimes no action is required at all. If the answer is the latter, there is no need to use the other questions. It is for this reason that this question is sometimes promoted to the top. In this blog, I stick to the order of the words for simplicity.

In Agile: In Scrum all user stories that are part of a Sprint must be ready and crystal clear. That means that the outcome itself and the way to achieve the outcome are also clear. If the “Do” part of a chore is not clear than the first step would be to get that clarified by the Product Owner or other stakeholders before adding it to sprint. Scrum Masters should learn teams to make stories as clear as possible and should check the clarity of the “Do” part regularly during refinements or planning sessions.

4. Must I do [THIS] now?

Then there is the actual “this”. Is the “this” the most appropriate and feasible action? Do you know what is driving the enquirer? The key element is not to rush into action mode just because someone has come up with an idea.

In Agile: Scrum and Kanban both push teams to get these aspects out of the way before they start working on something. Refinement sessions are used to clarify all stories and make sure we can actually do all the “thisses”. These tactics can also be used for random questions that come up during a sprint. Bottom line: If they are not clear, just don’t start working on them right away.

5. Must I do this [NOW]?

Last but not least is the “now” part. Now implies urgency. The urgency, however, is perceived by whoever raised the question. Often an action can wait, maybe for you to finish what you are working on, or maybe even longer like a week or more.

In Agile: Again, the Product Owner is the first go-to person to support you in assessing the urgency of the new request. If the assessment is made that the urgency can wait for a week, most times it can be planned and picked up in the next sprint. When organizations are in the midst of the transition to an Agile mindset you often see this ad-hoc pattern recurring. Team members receive requests directly from various stakeholders within the company and not via the Product Owner and Backlog. This indicates that more energy has to be put in the organization of these request flows to fully support the sprint rhythm.

Agile & Common sense

Of course common sense should always prevail and will hopefully be your first advisor. When an important production system is down, there is no time to waste. DevOps Teams often use practices like reserving time for production support or unexpected work to protect their Sprint Goals. A relevant quote from the Scrum guide in the Sprint section: “No changes are made that would endanger the Sprint Goal.” [2]. That is a firm statement. Yet, it also provides guidance to teams to judge whether there is room left in the sprint to help others or to stay focused to the current goal. So, for me these 5 words help me in the coaching of Agile teams to get their priorities straight out in no time. As mentioned in the intro, this approach is not only applicable to Agile teams but useful for everyone with more to do than time available. For another approach you could explore the usage of the Eisenhower Decision Matrix [3].

Side note

Firstly, I don’t take credits for the mnemonic as I did not invent it. A former colleague showed it to me a few years ago. I was not able to find it original roots [4][5]. Secondly, the sentence is a translation from the Dutch “Moet ik dit nu doen?”, which means literary the same – word by word – only in a different order. Since it is an external obligation in the question, the usage of “to have to” in stead of “must“ would improve the sentence’s grammar [6]. I guess the meaning as-is is still solid enough and in this way the original esthetics of the sentence remain intact, instead of “Do I have to do this now?”.

Cheers,
– Sjors Meekels