software development

Category Archives: Software development

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

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.

Download blog as PDF

This blog is available here:

Filled Under: agile,interim management,scrum,software development Posted on: 8 February 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

09 Mar 2018

What I gained from 100+ retrospectives

Nothing teaches better lessons on retrospectives than running retrospectives in practice. In this blog I will share personal lessons on retros and some ideas for alternative structures. The first four topic describe mindsets and things to consider during preparation or follow ups. The latter four provide ideas on alternative retro formats.

Boy-scout-approach: It is okay not to have life changing outcomes of the retro. Small steps count very much in the overall picture. If every retro would produce a live changing outcome, all teams would be top notch by now. Why not use a boy-scout-approach: each time you sit together try to leave the room in a slightly better shape than you came in. It is just like Uncle Bob advises programmers to do before checking in code.

No absolutism in having one: It is also okay to skip the retro occasionally, for example when the whole team wants to work on finishing an important feature in a sprint or simply because a lot of people are not in. This forms no problem just as long as this is incidentally and not structural.

Attendees & information: Some teams and Scrum Masters are really outspoken on who should or should not attend their retrospectives. My personal ‘ground rules’ are:
– Always invite and encourage Product Owners to join in;
– Let management know they can sometimes join, I only invite them directly when needed;
– Actively share the outcomes of the retro with PO, teams and management.
For me it is a healthy sign if Product Owners like to participate and have a genuine interest in being there. In general, the same holds for occasional attendance of line management or perhaps even project managers. In case of the latter two, their role should be kept equal to that of the team members or should be that of an observer. Although when teams don’t feel safe anymore, you should reconsider the setting and check what is hindering the team. In case (project) management or Product Owners show no interest in the outcomes, this indicates a gap in involvement and should be addressed. Of course, there is a mutual obligation to inform, but management should have a basic interest in the teams.

Historical perspective: Save the teams retro outcomes in a form, so you can see what is happening over time. Not just to check if actions and outcomes are put to effective use. If you have done this a few times for multiple starting teams, you see some patterns emerging. For example, in the type of topics discussed during retros. Knowledge, team spirit, basic rules on the Agile Way of Working are all topics to be found for starting teams. More importantly, you can see if topics reoccur and if topics in general relate to more process or enhanced improvements. These insights enable you to think about the ‘why’ of these reoccurring topics and appropriate actions.

Team-coffee: After a sprint went sour, it could work just to have a team-coffee and let people spill their guts and let their frustrations run freely. Change of scenario helps in getting people in the trusted zone to talk. No need for a formal routine, just write down what you hear and do a summary & wrap up of what you have heard to. If you feel more comfortable with increased structure, you can follow the steps of lean coffee to steer the session, see: lean coffee.

Communication & personalities: Working on team collaboration and being able to understand each other’s dos and don’ts can add real value. I have created an easy format to help teams through a session by prepping and explaining themselves. The personal test results are not interesting to me – although sometimes the combined results of a team can tell you a few things – but it certainly is a nice personal pitch starter. By allowing everyone to share their own characteristics people often surprise each other. For more info on the format see: retrospective-team-communication-and-personalities.

Feedback & speed dating: For teams who are a more familiar with each other, you can try a setup for providing and accepting feedback. Step one would be to share some basic rules and theory. And of course, invite people to provide each other feedback. Mind that this usually does not mean people will start doing it. It seems giving feedback is not that easy. A little trick here is to setup a retro like a speed date session. People sit in one-on-one sessions and give each other a tip and a compliment on their work in the team. This will help team members overcome the first hesitations to share their thoughts. To conclude everyone can present the top-tip he or she received to the group.

Retro tools: In some situations, you might be part of a co-located team. The team could be spread across a building, city or even across countries and time zones. Working in these teams requires extra energy and work from everybody. This is especially true for sessions like a retro where discussions and interactions are the foundation of valuable outcome. Some tools support distributed retrospectives like retrospectives-tool-for-distributed-retrospectives. Even when you are perfectly sitting together, the change in format by using a digital tool can be fun.

Special thanx to Stefan Jansen for letting me use the retro picture as he is the only person recognizable in the collage. Furthermore, the teams of Zoover, Weeronline, PGGM, Info Support, Softelligence and FourCorners have very much contributed!

Cheers,
– Sjors Meekels

Additional reading:

[1] samples.leanpub.com/funretrospectives-sample.pdf (retro formats)
[2] leanpub.com/50quickretrospectives (retro formats)
[3] www.mountaingoatsoftware.com/blog/a-simple-way-to-run-a-sprint-retrospective
(basic explanation of running a retrospective by Mike Cohn)
[4] Agile Retrospectives – Making Good Teams Great (Esther Derby & Diana Larsen)
[5] Coaching Agile Teams (Lyssa Adkins)
[6] Large-Scale Scrum – Chapter 14 (Craig Larman & Bas Vodde)