kanban – Agitma

Category Archives: Kanban

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

12 Sep 2019

De Lean Strategie – Daniel Jones ea.

‘De Lean Strategie’ is de Nederlandse vertaling van een inspirerend Engels werk over de kracht van Lean om grote bedrijven te veranderen. De vier auteurs: Michael Balle, Daniel Jones, Jacque Chaize en Orest Fiume nemen de lezer mee tijdens de zoektocht van enkele bestuurders die met behulp van Lean de enorme uitdagingen binnen hun bedrijf te lijf zijn gegaan.

Het is niet zomaar een kwartet auteurs wat dit boek geschreven heeft. Het betreft de coauteur van onder het Lean standaardwerk: “The Machine That Changed the World”, een ervaren leiderschapscoach met meerdere Lean boeken op zijn naam en een tweetal zeer ervaren bestuurders van grote bedrijven. De vier combineren hun inzichten in dit boek en beschrijven de praktijk op basis van hun ervaringen. “De Lean Strategie’ is hierdoor geschikt voor iedereen die Lean wil inzetten om de eigen organisatie duurzaam te verbeteren door te zien, te leren en te innoveren.
Inhoudsopgave

Inleiding
Hfd 1. Dingen beter maken
Hfd 2. Anders denken
Hfd 3. Leiden van onderaf
Hfd 4. Een kader voor leren
Hfd 5. Organiseren voor leren
Hfd 6. Een nieuwe formule voor groei
Hfd 7. Herbruikbaar leren om doorlopend meer waarde te creëren
Hfd 8. Versneld vooruitgang boeken
Hfd 9. Van Kaizen naar innovatie
Hfd 10. Een mentale omschakeling
Conclusie

De auteurs nemen de lezer in 10 hoofdstukken mee in de inzichten en ervaringen in het bijsturen van grote organisaties. Een van de belangrijkste leerpunten die zij benadrukken is de kracht van de Gemba. Maar al te vaak bestaan in de top van bedrijven diepgewortelde misvattingen over de uitvoering van het werk. Wil je als bestuurder weten wat er fout gaat in je bedrijf? Ga dan echt kijken. Echt kijken wil zeggen dat je de tijd neemt om op de werkvloer te ervaren welke uitdagingen zich in de operatie voordoen. Alleen zo kom je los van financiële rapportages of dashboards waarmee bedrijven vaak op afstand worden gerund.

Er zijn diverse voorbeelden opgenomen waarin bestuurders verrast werden door de wijze waarop organisaties zichzelf onbedoeld tegenwerkten. Illustratief zijn de verschillende afdelingen die zo zijn gecompartimenteerd dat men elkaars problemen niet kent en de organisatie als geheel niet in staat is het fundamentele onderliggende probleem op te lossen. Juist door de onderliggende problemen zichtbaar te maken voor iedereen, lukt het om de root causes te zien. Dit doorbreekt een reactie die we vaak in organisaties zien; het compenseren van datgene wat fout gaat in de één afdeling in plaats van het structureel oplossen van het probleem voor de gehele organisatie.

De opgedane inzichten van de vier auteurs onderschrijven de noodzaak om de wijze van leiding geven te herzien. In plaats van klassiek top-down te leiden moet er volgens hen meer worden geleid van onderaf. De kennis en kunde van de mensen op de werkvloer moet worden ingezet om de fundamentele problemen van de organisatie aan te pakken. Vaak begint dit met kleine – ogenschijnlijk – triviale verbeteringen. Onderschat hierbij niet dat ook verbeteren op zich een leercurve heeft. Mensen en organisaties moeten leren verbeteren; ze moeten leren kijken naar de situaties om zich heen en inschatten hoe deze kunnen worden verbeterd. Het is de taak van het management om de omstandigheden te creëren en te cultiveren waarin leren mag, kan en zelfs moet. Bij deze cultivatie spelen de lean tools een belangrijke rol. Deze worden niet ingezet om ad-hoc problemen te tackelen. Nee, ze worden zo ingezet (en in het boek beschreven) dat ze helpen de organisatie continu te verbeteren. Kleine verbeterexperimenten leiden op die manier tot innovaties (toegelicht in hoofdstuk 9).

Vanzelfsprekend wordt het succes van de toepassing van Lean niet alleen gemeten in de wijze van leidinggeven of verbetertrajecten. Uiteindelijk moeten aanpassingen ook bij Lean resulteren in strategische voordelen ten opzichte van concurrenten. Kosten, klanttevredenheid en andere harde financiële graadmeters blijven meewegen. Gelukkig sluiten de inzichten van de auteurs en Lean aan bij de huidige tijdsgeest waarin onderwerpen zoals duurzaamheid & medewerker tevredenheid steeds belangrijkere worden, ook in de boardroom.

Conclusie

Waarom dit boek lezen? Vanuit mijn eigen Agile achtergrond ben ik Lean gaan waarderen op een aantal punten die goed in dit boek aan bod komen. Het daadwerkelijk borgen van verbeteringen zit diep verankerd in Lean en het inzetten van Visueel Management wordt veel breder ingezet dan ‘slechts’ de Scrum borden die veel Agile teams hanteren. De inzichten in dit boek vormen een mooie verbreding ten opzichte van organisaties die voornamelijk werken vanuit een Agile mindset.
Lees dit boek niet omdat je snel bij wilt zijn met het inzetten van de Lean tools of het opfrissen van je lean woordenschat. Lees dit boek vooral als je wilt nadenken over een andere wijze waarop je strategisch je bedrijf wilt veranderen.

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: book review,kanban,lean Posted on: 12 September 2019

06 Apr 2018

Kanban in de praktijk – Growing Agile

Focus aanbrengen en zaken daadwerkelijk afmaken voordat je aan iets nieuws begint. Het klinkt zo eenvoudig, maar in de praktijk blijkt dit toch lastiger dan gedacht. Met – het van Japanse origine zijnde Kanban – kun je deze uitdaging te lijf gaan.

In het boek Kanban in de praktijk leggen Karen Greaves en Sam Laing stap voor stap uit hoe je Kanban voor je kunt laten werken. Er is geen technische of praktische voorkennis benodigd, het boek is voornamelijk gericht op beginnende teams en organisaties.

De auteurs hebben vanuit hun bedrijf Growing Agile inmiddels al een aantal publicaties op hun naam staan. Ze beschrijven steeds concrete thema’s uit het Agile werkveld. Zo ook Kanban in de praktijk, de Nederlandse vertaling van Kanban Workbook uit 2016. Aan de hand van het fictieve hoveniersbedrijf Growing Garden nemen Greaves en Laing de mogelijkheden van Kanban door. Door de geleidelijke opbouw, zonder gebruik van jargon of bijvoorbeeld IT-gerelateerde termen, is dit boek geschikt voor iedereen die met Kanban aan de slag wil om meer te doen in minder tijd.

Inleiding
Hfd 1. Werk visualiseren
Hfd 2. WIP en pull
Hfd 3. Doorstroom verbeteren
Hfd 4. Expliciete afspraken
Hfd 5. Samen verbeteren
Bijlage – Personal Kanban
Bijlage – Het vliegtuigspel

De verhaallijn is duidelijk. Er wordt een gezamenlijk project gestart door Linda, Ellen en Joost, tussen de reguliere werkzaamheden van iedereen door. De drie besluiten Kanban in te zetten met als doel dat het werk, het schrijven van een boek, daadwerkelijk afkomt. In elk volgend hoofdstuk leren onze hoveniers dat er best nog wat verbeterd kan worden aan de opzet die zij tot dan toe gebruikten. De leercurve die zij meemaken zie je ook vaak in de praktijk terug, met trial en error ontstaat een werkwijze die passend is voor situatie.

Qua theoretische volledigheid zit het boek goed. De basisprincipes worden uitgelegd en daarna komen vaste onderdelen aan bod: initiële Kanbanborden, WIP-limieten per persoon of kolom, creëren van Pull en spelregels. Het geheel wordt aangevuld met praktische tips, voorbeelden en vragen voor de lezer. Op deze wijze rol je eenvoudig door een scala van opties en kun je de beste opties voor je eigen situatie bepalen. De suggestie die de auteurs geven om na ieder hoofdstuk zelf met de aanpassingen en vragen aan de slag te gaan, is nuttig. Zo ervaar je direct wat voor- of nadelen van bepaalde keuzes zijn.

Daarnaast hebben de auteurs in het verhaal een aantal bekende kenmerken van Scrum aan het gebruik van Kanban toegevoegd. De dagelijkse Standup, Retrospective en Definition of Done zijn ingebed. Zij hebben deze practises hiermee onderdeel gemaakt van Kanban, logisch want deze Agile practices zijn hiervoor prima geschikt. Puristen zullen zeggen dat zij hiermee feitelijk ScrumBan beschreven hebben. Deze samenvoeging doet echter niets af aan de waarde van het verhaal en sluit aan bij de ontwikkelingen in de praktijk. Zo heeft Scrum.org vorige maand een publicatie uitgebracht waarbij Kanban wordt beschreven als werkwijze binnen Scrum teams. [zie https://www.scrum.org/resources/kanban-guide-scrum-teams].

In de bijlagen van het boek zijn tevens twee extra’s opgenomen ‘Personal Kanban’ en ‘Het vliegtuigspel’. De laatste sprak mij het meeste aan en geeft snel inzicht in de kracht van Pull. Probeer deze eens uit met je team en je zult zien wat het effect is van een kleine aanpassing in werkafspraken.

Conclusie

Kanban in de Praktijk is geschikt voor iedereen die weinig bekend is met de werkwijze Kanban en graag met concrete voorbeelden en/of stappen werkt. Mocht je een vlotte lezer zijn dan bestaat de kans dat je het boekje binnen een uur uit hebt. Dat is geen ramp, in dat geval ben je waarschijnlijk ook al bekender met de materie en kun je wellicht met een aantal tips direct aan de slag.

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

Cheers,
– Sjors Meekels

Download blog as PDF

This blog is available here:

Filled Under: agile,book review,kanban,scrum,software development Posted on: 6 April 2018

01 Sep 2017

Visualization helps Agile Teams & Organizations

Transparency is one of the corner stones of great Agile teams and organizations. If that is the case, isn’t it strange that so many teams have little outwards visualizations? Not only teams benefit from visualization, but also management and other stakeholders could gain direct insights from the information presented. In this blog, I will discuss visualization from different perspectives using my own checklist as a starting point (see at the bottom of this blog). At the end, I will share a few pointers to get you started.

The eight examples on my checklist are a nice start. Depending on your team or department characteristics, you can probably add a dozen others. Some at least as important as the ones on the list. However, the true value for me lies in the dialogues and questions that arise from them instead of the – more fundamental – discussion on which items should or should not be on the list.

Team perspective
Let’s start with the team perspective. The first reaction and question that usually pops up is: for whom are we visualizing? Unarguably, it should be for ourselves and our stakeholders. So, if we do it for ourselves, we need to have information radiating that is important and useful for us. In my opinion, all topics on the checklist should matter to any given team. If not, there is a chance something is off in the basic way the team is functioning and/or supported by its organization. Do it, pick one topic and argue that it is not important for a healthy routine of your team.

The second reaction from teams can come from two directions: “we don’t have that information” or “it takes too much time to gather it”. Both arguments are excellent starting points for valuable discussions – during retro’s or just over coffee. Not having the information means that your team is flying in the dark. Either the product or the company’s road map is not clear or perhaps the feedback loop for continuous improvements is not implemented. If collecting these basic team drivers takes too much time, chances are that tooling is not in place or not used correctly. The reactions mentioned in this paragraph are indicators that the Way of Working can be improved.

Management perspective
Let us shift to the managerial perspective. In more Agile oriented organizations this perspective often leads to a different reaction compared to the ones above. “My teams are self-organizing, self-managing or self-supporting, so they decide what is shown and needed.” Wrong! As long as managers are responsible for their performance – either hierarchical or via a more servant-leadership – it is their job to have an interest in these subjects. If not, they’ll have a tough time explaining what added value they have for their teams and thus their organization. For example, how can a team manager not want to see Impediments or improvements made by his or her teams? In addition, teams often need directions and coaching on organizational goals and drivers. Outward visualization helps the process of aligning the organizational goals and the Way of Working of the teams.

In practice, it can be challenging to implement and decide on the most useful visualizations for your teams or department. Remember it is good to try things and ask around who is interested in what information. Or as a manager, discuss with your teams what the goal and improvements are from an organizational point of view. If done right, the information not only benefits the teams, it is also a source of information that could substitute numeral status meetings.

Stakeholder perspective
The third and last perspective is that of the stakeholders. Top priorities for stakeholders usually contain the question: “When is this or that feature finished?” By showing this information crystal clear in the team area, the team provides the stakeholders with direct insight. Moreover, it helps by building confidence and making the team predictable for its environment. Perhaps the expected date example is a bit simplified. How about this one: create a good Story map of the current product (iteration) and put it in a visible place in the area. Make sure you add significant release dates, in case you don’t go to production in every sprint yet. Now, the timeline has its own functional context which makes clear what the stakeholders can expect. For teams, it is good to adjust to the stakeholder’s needs. Thus, especially as a Product Owner you should invest in what the stakeholders would like to see and hear from the team. Also, be confident to use visualization and communication forms you have seen working before.

A few pointers to get started
Responsibility: who’s responsible for visualization? When teams just start, most of the times it is the Scrum Master who begins with Burn down charts and Impediment boards followed by other more Scrum – or process – related information. In my opinion, it should be a Scrum team effort. In other words, everybody – also the Product Owner – is using the team area to show road maps, examples or key metrics. This will stimulate the philosophy that if it is important for the team, we put it up there. Anyone can decide or try to use some new metric or insight. This does not mean that other stakeholders cannot let the team know what they would like to see.

Gemba walks: one practice that provides insights to all stakeholders is doing Gemba walks across multiple team areas. Don’t ask how things are going straight away. Instead, look around and see what the information presented is telling you. I have used this technique also with colleagues visiting other teams. Besides entertaining it is an easy mechanism to share practices and bring teams a little closer. A Gemba walk might be a catalyst for explorations on visualization benefits for teams, managers and stakeholders.

How to show: I did not elaborate on the form in which information is shown. That is on purpose. Depending on the team, tools and context, you’ll get different outcomes. The fact that I am not a great sketch artist results in more print outs for my teams. In companies with big screens available in team areas you can have as much metrics and info on the screen as you would like. In some companies on the other hand, there is a strict clean desk policy and very little information is allowed to radiate from team areas.

Conclusion

The discussions and feedback from teams and stakeholders can be as valuable as the visualizations themselves. So, make sure you are aware of their thoughts and needs before mounting all kinds of information to the walls. Depending on your role you can initiate the dialogue with or within your teams in diverse ways. Use the checklist, the Gemba walk or any another conversion-starter in your team or department to explore the benefits of visualization. I am curious to hear your experiences and/or remarks. The discussion and feedback from teams and stakeholders can be just as valuable as the visualizations themselves. So make sure you have these before you start mounting all kinds of information to the walls, or demanding this as management.

Download the one-pager: Visualization helps Teams and Organizations

Cheers,
– Sjors Meekels

References

There is a lot of information out there, so I added just a few examples to get you going:
[1] www.infoq.com: Visualize Agile https://www.infoq.com/visualize-big-picture-agile
[2] Ben Linders: Visualizations https://www.benlinders.com/visualization-team-deliver-value/
[3] www.thoughtworks.com: Story-mapping https://www.thoughtworks.com/story-mapping
[4] Toolbox for the Agile Coach – 96 Visualization examples, Jimmy Janlén, 2015
[5] Coaching Agile Teams, Lyssa Adkins, 2010

Download blog as PDF

This blog is available here:

Filled Under: agile,agile projectmanagement,kanban,scrum Posted on: 1 September 2017

10 Jul 2016

Dilbert saves the Agile day

It is amazing to see some of the comics made by Scott Adams are already more than a decade old and are still spot-on. Today I will use 4 of them and connect them with real live challenges that are happening in our daily routines creating software.

‘One Dilbert says more than a thousand words.’

Silver bullets don’t exist. The same holds true for best – or good – practices embraced in Agile software development. Be aware if you are in a transforming organization and senior management pushes Agile forward to solve all kinds of problems. A few examples in which Agile or Scrum will not make your existing problems go away:
– The engineering workforce is not equipped for new projects and techniques.
– Management is not involved in your most relevant projects and is not managing or leading.
– There is no clear view on the product vision and roadmap or priorities.

Yes, often Agile working processes can help in solving these problems. Agile itself however, is not the solution to all existing problems.

For organizations to become successful in their Agile adoption, it is good to perceive the roles of business representatives and Product Owners carefully. In my opinion the most underestimated role in Agile & Scrum is that of the Product Owner. Early adopters often appointed an experienced user or analyst as the Product Owner and focused most attention on the Development Team. Sometimes this pattern can still be seen today. In a few cases it worked fine. However, often the skills needed to be a good Product Owner are much harder to find than with a quick look around. The impact a good Product Owner has on the team’s productivity and in the end the value delivered for the organization is huge. So invest in training and coaching newbies or hiring experienced Product Owners.

A lot of organizations have been in an Agile transformation for some years now. Probably a large part of those organizations claim they “Are Agile”. I guess it is more a question of perception than exact definition. In adopting a lot of Agile practices and converting existing teams into Scrum teams – or Kanban – it is easy to make that statement. But a genuine Agile organization is never ready, never stops learning and never stops adjusting. Do these organizations keep challenging their teams and product managers? Do they adapt their tools and engineering skills to new features and insights? Or have they adopted some practices and do they now keep using these for the next couple of years? A true answer might give the first sparkle to being Agile.

It is funny how some misinterpretations continue to happen. More productive teams may indeed be one of the results of a good Agile implementation. However, this does not imply that making the transition will get you there right away. No, transitioning to Agile means hard work and dedication. As in all transitions it is about two steps forward and one step back. There is not a general blueprint suitable for all organizations. So come up with a plan, skilled people and a lot of positive energy to start your company’s transformation.

5. Bermuda triangle of Agile
The last cartoon is not an original Dilbert comic but originated from Luca Minudel in 2011: https://www.flickr.com/photos/lucaminudel/6059269914/

Not all experienced project managers or hiring executives truly grasp the notion of Agile. Don’t let them fool you. One-way or the other, you cannot fix all attributes within an Agile project. At least part of the project needs to have a flexible angel, in either time, costs or preferably features. Yes, quality is in most projects not variable. For part of the features that are well understood and technically straightforward, it is okay to go for a fixed setup. Don’t get Bermudad all the way!

Sometimes I wonder if it would be possible to replace expensive managerial courses with just a good selection of these comics and start some honest reflection…..

[edit 2019] See Dilbert still struggles with Agile for new challenges and insights.
Or dive into the evolutiong of DevOps in DevOps: understanding the evolution.

Cheers,
– Sjors Meekels

Download blog as PDF

This blog is available here:

Filled Under: agile,kanban,software development Posted on: 10 July 2016

21 Jun 2016

Agile Project Management with Kanban

In zijn boek ‘Agile Project Management with Kanban’ deelt Eric Brechner zijn ervaringen met de introductie en het gebruik van Kanban bij het Microsoft Xbox platform. Hij borduurt voort op de groeiende populariteit van Kanban sinds 2010. Zijn doelgroep bestaat uit professionals van alle disciplines in software engineering met interesse voor praktische toepassing. Lezen en daarna zelf doen is zijn credo.

Voor sommigen zal de naam Eric Brechner bekend klinken, dat klopt. Eric Brechner is de auteur van het in 2007 verschenen boek ‘Hard Code’: een bundeling van interne columns over de softwareontwikkeling binnen Microsoft verschenen onder het pseudoniem I.M. Wright. Nu is hij terug met ‘Agile Project Management with Kanban’ en publiceert hij onder eigen naam. In zijn nieuwe boek staat het gebruik van Kanban bij zijn teams van Xbox bij Microsoft centraal.

Zonder er om heen te draaien wijst Brechner er in de inleiding op dat het boek bedoeld is voor professionals die geïnteresseerd zijn in een praktische toepassing van Kanban. Ben je op zoek naar meer achtergrondinformatie over de theorie en fundamentele uitgangspunten van Kanban, dan zijn er betere alternatieven.

Brechner gebruikt het eerste hoofdstuk om het gebruik van Kanban in een organisatie te introduceren. Het is met name gericht op het overtuigen van management en bevat naast de argumentatie tevens een voorbeeldmemo ter ondersteuning.
In het tweede hoofdstuk neem hij de lezer in 5 stappen mee in het opzetten van Kanban. Hij geeft voldoende informatie en handvatten om direct zelf aan de slag te gaan. Elegant kort is zijn vergelijking tussen Kanban-Scrum-Waterval en de wijze waarop deze technieken chaos beperken in stap 3 van het stappenplan. De uitleg over het gebruik van limieten aan Work in Progress en de werkwijze van het Kanbanbord is helder.
De volgende hoofdstukken behandelen specifieke onderwerpen gericht op verschillende organisatorische kenmerken. Hoofdstuk 3 richt zijn pijlen op het halen van deadlines – een terugkerende uitdaging in softwareontwikkeling – en het informeren van management omtrent planning en de inzet van schattingstechnieken.
Hoofdstuk 4 geeft een korte beschrijving van de introductie van Kanban bij een team dat de Waterval-methode gebruikt. Zonder grote verassingen neemt hij mogelijke weerstanden weg en focust hij zich met name op de voordelen van de transitie van Waterval naar Kanban.
De inhoud van het volgende hoofdstuk roept bij Scrum-professionals een aantal vragen en vermoedelijk enige weerstand op, namelijk het vervangen van Scrum door Kanban. De voordelen van Kanban ten opzichte van Scrum zijn vrij summier beschreven. Brechner waardeert Scrum zeker, hij waardeert Kanban nog meer. Tekenend is zijn statement dat ‘Kanban de volgende evolutie van Scrum is’. Dit is natuurlijk, niet geheel onterecht, voer voor discussies met Scrum-aanhangers.
Hoofdstuk 6 is redelijk technisch ingestoken en geeft een beknopte beschrijving van de inzet van verschillende branching, versioning en deployment strategieën. De interessante link met Kanban zijn de aanpassingen die hij inzet op het Kanbanbord en de gehanteerde flows.
Het opschalen van Kanban naar grotere organisaties, zoals Microsoft, vraagt om extra aanpassingen. Aan dit onderwerp besteedt hoofdstuk 7 aandacht. Brechner tackelt bekende problemen bij opschalen zoals communicatie en afhankelijkheden tussen teams. De verschillende manieren om volgordelijkheden tussen teamactiviteiten inzichtelijk te maken zijn naast leerzaam, ook zeker in andere Agile-frameworks toepasbaar.
Hoofdstuk 8 is geschreven door James Waletzky, een ervaren software engineer die voorheen werkzaam was in de Xbox teams. Hij beschrijft de integratie van het werken aan bugs met de doorontwikkeling van een product. Deze twee aspecten staan vaak op gespannen voet, vandaar de extra aandacht in een apart hoofdstuk. Voor diegenen die in productdevelopment werkzaam zijn, zijn de ‘troubleshooting’ voorbeelden zeer herkenbaar.
Het laatste hoofdstuk, behandelt uitbreiding van Kanban met andere methodes en technieken zoals Lean, Theory of Constraints of Critical Chain. Dit hoofdstuk is met name bedoeld voor meer ervaren teams die de basisflow in de vingers hebben en zoeken naar verdere optimalisaties.

Per hoofdstuk zijn praktische checklist toegevoegd en bij een aantal hoofdstukken zijn interessante vraag-antwoord voorbeelden opgenomen. Met name de voorbeelden bereiden de lezer voor op vragen van mogelijke klanten, managers of teamgenoten. Nuttig om te weten is dat de rekenvoorbeelden en het genoemde memo online beschikbaar zijn. Hiermee heeft de lezer direct één op één de voorbeelden uit het boek te pakken.

Brechner’s achtergrond als engineer verklaart wellicht het veelvuldig gebruik van checklists, tips, formules en voorbeelden. Hoewel de gebruikte formules en voorbeelden niet complex zijn, lees je dit boek waarschijnlijk niet in één adem uit. Dat hoeft ook niet. De gekozen opzet, met hoofdstukken gericht op specifieke situaties, geeft de lezer de mogelijkheid snel door te bladeren naar de voor hem of haar relevante onderdelen.

Heb je behoefte aan een praktische leidraad in Kanban of ben je nieuwsgierig naar het ontwikkelproces bij een top gaming platform & multinational zoals Microsoft – dan ben je met Agile Project Management with Kanban aan het juiste adres.

Over deze recensie
Deze boekrecensie is tevens verschenen op www.managementboek.nl. Aangezien het betreffende boek in het Engels is, is een Engelse recensie wellicht passender. Bij voldoende tijd zal ik hem alsnog vertalen.

Cheers,
– Sjors Meekels

Note in English

This book review is in Dutch and is also published on www.managementboek.nl. The book is in English so it would make sense to write an English review. Again, when I do have some spare time I will make a translation