Category Archives: Software development

Leading Image

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.

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

Leading Image

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.

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

Leading Image

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
Dilbert_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?
Dilbert_worthless_employees
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
Dilbert_That_is_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
Dilbert_twizzle_the_flurm
“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
Dilbert_Agile_strategy
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…

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.

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

Leading Image

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.

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

Leading Image

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.

Additional reading:

samples.leanpub.com/funretrospectives-sample.pdf (retro formats)
leanpub.com/50quickretrospectives (retro formats)
www.mountaingoatsoftware.com/blog/a-simple-way-to-run-a-sprint-retrospective
(basic explanation of running a retrospective by Mike Cohn)

Agile Retrospectives – Making Good Teams Great (Esther Derby & Diana Larsen)
Coaching Agile Teams (Lyssa Adkins)
Large-Scale Scrum – Chapter 14 (Craig Larman & Bas Vodde)

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!

Filled Under: agile,scrum,software development Posted on: 9 March 2018

Leading Image

First LeSS Conference – Ever

The first LeSS Conference – Ever
So the first ever LeSS conference was about to take place in Amsterdam. A few former colleagues were planning on going so I was immediately interested as well. The lineup was promising, Bas Vodde and Craig Larman would be present and Gojko Adzic was one of their guest speakers. My knowledge of LeSS was limited to what I had read online as I have not yet been in an organization using LeSS as a scaling framework. Well, you guessed right, I ended up going and in this blog I will share some of my personal highlights of this two-day-event.

Opening and setting
The body organization of LeSS is not a big commercial vehicle which rolls out events like this every few weeks. So things were new and the atmosphere was also newish and therefore relaxing. Cesario had the honor of opening the conference

Story of Less- Bas Vodde
The history of Less may be told during trainings, yet as I heard the story for the first time it was entertaining, recognizable but also refreshing. LeSS is still Scrum, but with a little extra. The focus on Feature teams is an important aspect and needs to be strong. Component teams are not ‘forbidden’, but they mustn’t form the majority. Another interesting point is continuing the Scrum mindset as a framework. The opposite as with RUP, which you have to tailor down, meaning don’t use everything except the parts fitting your own situation. In LeSS it is called “Build Your Method Up”. Bas can probably tell the Story of Less like no one else and the good thing was, he told the story like sitting around a bonfire (just a fire on a video this time). He only showed the slides of the actual story in a total of 20 seconds when he was finishing up. The story was mainly on the core essence and the history of LeSS and not like a mini-course.

Teams and assignments
One of the goals the event organization has was to establish new communities and to enhance the interaction between visitors. The leading mechanism they initiated was the forming of new team who should collaborate on genuine product to be shown at the end of day two. So the entire group of people were gently pushed to form teams by self-organizing. Every visitor had received one or more small buttons indicating a certain capability, e.g. developer, designer, LeSS expert. The goal was to create teams with all the capabilities covered. Yes indeed like a true cross functional team. So this was my team:

Less Conference 2016 My team

The method worked pretty well and it was indeed good for introductions to new people. The actual goal for the assignment wasn’t that clear so most teams lost quite a bit of time on discussions and a few teams dissolved entirely the next day. Yet, experimenting is also a foundation of LeSS so no harm there.

Owning versus Renting Your System – Craig Larman
The title sounds somewhat more relating to a car or house but it made quite an impact on me. When coaching and convincing people to adopt Scrum and to adhere to the rituals correctly you can really see the difference. Some teams start breathing Scrum and start coaching each other- yes and me – when things are not done properly. Stand ups are swift, the board is neat and people respect priority set by the Product Owner. Other teams, are never prepared for anything, forget Dailys when the Scrum Master is not around and follow the coach or Scrum Masters guidance a bit reluctant. The latter team is just Renting Scrum they don’t Own it, the first team does! Craig didn’t use this example, that’s just my reflection of the difference in my daily struggles.

Less Conference 2016 Craig Larman
The way to make people buy into an idea and letting them own it was the main thread in his talk. The Why (by Simon Sinek) is solid starter and he then used some more examples based on system theory to let people reach their own opinion and ideas about the way of working. In doing so people are coming up with a part of the solution and start owning it – bit by bit.

Memorable Quotes:

‘No more yak shaving’

‘Underpants gnome profit plan’

So..
The relaxing atmosphere and openness to experiment with the format was nice. Only downside was that it perhaps was a bit stretched and for me personally the last sessions of the second day lost some value. All in all it was very interesting and an excellent place to meet like minded people and increase your network and at the same time increase your knowledge!

Contributions & References

[1] Conference home: less-large-scale-scrum.com
[2] Program and slides less-large-scale-scrum.com/program.html
[3] Less: less.works
[4] Story of Yak shaving: sethgodin.typepad.com/seths_blog/2005/03/dont_shave_that.html
[5] Origin of Underpants gnomes: www.youtube.com/watch?v=tO5sxLapAts
[6] Impact Mapping (Gojko Adzic): github.com/facilitation-games/revenue-stream-map

Filled Under: agile,scrum,software development Posted on: 5 September 2016

Leading Image

Scrum – Novice to Ninja

David Green combineert een academische achtergrond in Sociologie en Organisatiekunde met zijn ervaringen in het veld als engineer in het boek Scrum: Novice to Ninja. Het boek is gericht op organisaties die Web- en Mobiele applicaties maken en heeft de professional met relatief weinig ervaring in het gebruik van Scrum op het oog.

Het boek Scrum: Novice to Ninja is tevens het eerste boek wat David Green publiceert. Hij schrijft echter al geruime tijd online artikelen en is een ervaren software engineer. In zijn boek staat de introductie van Scrum centraal en bedient hij de onervaren professional die met Scrum aan de slag wil.

Het verschil met andere boeken die Scrum beschrijven is de specifieke focus op het ontwikkelen van Web en Mobiele applicaties. In hoofdstuk 1 legt Green uit waarom juist deze domeinen zich met uitstek lenen voor de inzet van Scrum. Zo zijn aanpassingen ter ondersteuning van nieuwe browsers of mobiele devices vaak erg urgent. Ook gewenste communicatie-uitingen vragen vaak om ad-hoc werkzaamheden.

De rode draad van het boek is de introductie van Scrum in het fictieve bedrijf WithKittens.com. In hoofdstuk 2 introduceert Green het bedrijf met haar belangrijkste betrokkenen in deze Agile transitie. Vanuit de ogen van bijvoorbeeld een productmanager, een designer of een engineer, laat hij zien wat de huidige motivaties en verwachtingen zijn. Deze persona’s zijn goed gekozen en geven een realistische doorsnede van veel voorkomende teamrollen in organisaties.

Het theoretische kader van Scrum is de boodschap van de hoofdstukken 3, 4 en 5. De beschrijving volgt een logische volgorde van de gedefinieerde rollen, rituelen en gehanteerde artefacten. Wat de beschrijving luchtig houdt, is de speelse manier waarmee het framework in de dagelijkse praktijk wordt gepositioneerd. Concrete dagbeschrijvingen in hoofdstuk 3 geven een informeel en praktisch overzicht van de activiteiten in het leven van een Scrum-practitioner.

In de hoofdstukken 6, 7 en 8 gaat het fictieve bedrijf concreet met Scrum aan de slag en komen de onzekerheden en pijnpunten bij de toepassing aan de orde. Met korte dialogen tussen teamleden en praktische voorbeelden laat Green zien hoe het Scrum spel gespeeld wordt.

Hoofdstuk 9 richt zich op het finetunen en omzeilen van veelvoorkomende problemen. De titel van het hoofdstuk doet vermoeden dat de oplossingen voornamelijk gericht zijn op Web en Mobiele teams. Echter de suggesties en tips zijn in ieder domein van waarde. Welk team is niet gebaat bij ge-timeboxte rituelen of een minimum aan interrupties na de start van een sprint?

Zoals in Scrum retrospectives gebruikelijk is, zo blikt ook Green in hoofdstuk 10 terug. De persona’s, waarmee we eerder kennis hebben gemaakt, kijken terug op hun ervaringen met het gebruik van Scrum. Zij reflecteren op hun eerste reserveringen en geven aan wat zij hebben geleerd. Het meest interessant zijn de overblijvende frustraties en de wijzen hoe de verschillende persona’s hiermee omgaan. Deze zullen voor ervaren Scrum practitioners bekend voorkomen en voor de beginnende professionals een waarschuwing zijn.

Hoofdstuk indeling:
1. Introductie van Scrum
2. Ontmoet het Team
3. Scrum Rollen
4. Scrum Rituelen
5. Scrum Artefacten
6. Het Scrum Contract
7. De levenscyclus van een Story
8. Werken met Scrum
9. Scrum voor Web en Mobile Team
10. Aanpassen aan Scrum

Green hanteert een ruime interpretatie van de officiële Scrum Guides en geeft er zijn eigen twist aan.
Een tekenend voorbeeld is het verschil in terminologie en zijn beschrijving van de Demo’s de Sprint Review in hoofdstuk 4. Is dat erg? Nee, zeker niet. Het geeft de lezer gewoonweg inzicht in de ervaringen en ideeën van de auteur. Het boek is hierdoor wel minder geschikt voor diegenen die zich willen voorbereiden op certificering als Scrum Master.

Conclusie: Scrum – Novice to Ninja is in toegankelijk Engels geschreven en geschikt voor iedereen met weinig ervaring met Scrum en zodoende een prima startpunt. De voorbeelden die de auteur projecteert op de medewerkers van WithKittens.com zijn uit de praktijk gegrepen en heb ik zelf bijna zonder uitzondering ervaren. Met 10 beknopte hoofdstukken in 160 bladzijden is het een prima boek om rustig in een weekend door te nemen.

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.

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

Filled Under: agile,book review,scrum,software development Posted on: 17 July 2016

Leading Image

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.’

1. Chairs and pants
Dilbert - Chairs and PantsDILBERT © 2013 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

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.

2. Success of Agile just doesn’t depend on good engineers alone
Dilbert - Give me all FeaturesDILBERT © 2003 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

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.

3. Being Agile versus Doing Agile
Dilbert - Training Agile ProgrammingDILBERT © 2003 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

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.

4. One more Agile myth
Dilbert - Agile Programming SpeedDILBERT © 2005 Scott Adams. Used By permission of UNIVERSAL UCLICK. All rights reserved.

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
Bermuda TriangleThe 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.

 

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

Leading Image

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.

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

  7. 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.

  8. 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.

  9. 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.

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

Filled Under: agile,book review,kanban,scrum,software development Posted on: 21 June 2016

Leading Image

Principles, prince2ples, everywhere… Part II

In the first part of this blogpost I have elaborated on the Prince2 principles from the viewpoint of the Agile mindset. Today we are going to turn the tables. We could consider the four Agile values defined in the Agile Manifesto as our primary subject; however, with a full set of twelve available Agile core principles that would be a shame. It is possible to recognize benefits for projects from all of the twelve Agile principles [3]. This is an interesting exercise, but it is not the same however, as judging these principles from another viewpoint.

A small side note: in order to keep this blogpost from becoming an unwelcoming long read, I will be short on those principles that are not part of Prince2 at all and rank these as neutral votes.

1. Customer satisfaction
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

Being on time and within budget are still often the classic elements on which a project is rewarded, with quality often as the lesser third.Although Prince2 values finished work packages, these are often part of progress reports; early and continuous delivery of software is not required. Working software is just not the highest priority. As the iterative flow of Prince2 does encourage smaller delivery moments, a neutral vote fits best for this principle.

2. Embrase change
Welcome changing requirements, even late indevelopment. Agile processes harness change for the customer’s competitive advantage.

Welcoming change is a different approach compared to a strict defined change process to cope with adjustments. A little exaggeration to indicate the contrast: Prince2 follows the paradigm “Stick to the plan” whereas Agile is designed on the paradigm “Change the plan”. Changes in Prince2 follow a formalized process. Due to their nature of being a change to the current project plan, they often require an official approval from the project board. The principle is therefore not shared and placed in the conflicting corner.

3. Frequent delivery
Deliver working software frequently, from acouple of weeks to a couple of months, with apreference to the shorter timescale.

As discussed in the first part of this blog, Prince2 uses stages or iterations to create a smaller scope. We linked this principle to principle 5 “Manage by stages” and concluded these were shared.

4. Ongoing collaboration
Business people and developers must worktogether daily throughout the project.

This principle is not part of any official Prince2 description. While there is nothing against it as well, we consider it as neutral.

5. Support self organization
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

This principle has one interesting aspect that stands out for me. It is the last phrase, “trust them to get the job done”. In the very acronym of Prince2 the term “Controlled” is present, which makes me refer to a quotation attributed to Lenin: “trust is good, control is better”. I have a hard time convincing myself the principle is shared.

6. Face-to face communication
The most efficient and effective method ofconveying information to and within a development team is face-to-face conversation.

In the discussion of the second Prince2 principle “2. Manage by exception principle” we already concluded the two methods have an opposite approach. The conflicting votes have gained another member.

7. Progress measurement
Working software is the primary measure of progress.

While monitoring progress and clear reporting is an important aspect of Prince2, there is no defined measurement of progress itself. The project manager is responsible for setting up fitting measurements and reporting to the project board. Given  the fact that working software is in practice an important part of the progress report, I lean towards a neutral vote.

8. Sustainable development
Agile processes promote sustainable development. The sponsors, developers, and users should be ableto maintain a constant pace indefinitely.

One of my favorite Agile principles shows the difference in approach from the classic project methods. From a Prince2 perspective, with a temporary organization and fixed time frame, it seems there is no direct need to keep a sustainable pace. Projects with fixed dates even find themselves falling back to proven anti-patterns such as dead marches or scaling up teams to mythical proportions [2] when the end of the project comes into view. On the other side, I have seen this happening in Agile projects as well. Leaving the real life experiences behind, Prince2 does not have anything against a sustainable pace, so this principle finds itself on neutral ground.

9. Invest in Technical skills and design
Continuous attention to technical excellence and good design enhances agility.

This principle is not known or rewarded in Prince2; even more, enhancing agility is not a useful project goal to have at all as itcan lead to gold plating and over engineering. Good design in itself is valuable indeed. You can raise the argument that actual continuous attention to good design for agility is only a project goal if Changeability (as a dimension of Maintainability in ISO 1926) is in the official requirements. The omission of a Prince2 view on this principle puts it in the neutral camp.

10. Simplicity
Simplicity – the art of maximizing the amount of work not done – is essential.

Focus on concrete products, doing what is in the plan and not losing valuable resources on non-attributing work, these ideas are all perfect from a Prince2 viewpoint. In an actual project there will be discussions as to whether something is in- or out of the scope of the project. This is especially true in fixed priced projects. In Agile projects we have similar discussions in deciding when a story is Done (an interesting approach is Just Barely Good Enough [5]).  There is a mutual appreciation of this principle.

11. Self organization for the best results
The best architectures, requirements, and designs emerge from self-organizing teams.

Prince2 does not acknowledge self-organizing teams; on the contrary, team managers and project managers are responsible to guide the project and teams. The usual organizational approach is by Product Breakdown Structures (PBS) and distributing work packages to teams and individuals. Team involvement is then accomplished through team plans and team sessions. Although this means the teams are involved, they are not self-organizing. This raises the number of conflicting votes by one.

12. Inspect and adapt
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Learning is a defined part of Prince2: this corresponds directly with principle 3 “Learn from experience” and avoids reinventing the wheel. So this principle is shared.

Conclusion

The votes of the Agile principles perceived by Prince2 are in: there are 5 neutral votes, 3 shared ones and the remaining 4 present us with conflicting ones. The contrast to the outcome of the first part is big, where 6 out of 7 of the Prince2 principles are rewarded in Agile as well. How can this difference be explained?

First of all Prince2 is a general project management method, this means it can be used for any types of projects. Furthermore, it is stated the specialist contributions (in software engineering all team members) are not part of it. Agile is founded on software engineering best practices and describes a way how teams and specialist should interact. This explains why 5 out of 12 of the Agile principles are not present from Prince2 perspective: they are just too specific. The fact that the majority of Prince2 principles are rewarded by the Agile mindset can be attributed to this difference in granularity as well. And they are still good principles, in the previous blog we concluded that did not come as a surprise.

The next interesting observation is about the four conflicting Agile principles. Three out of four of these principles (5, 6 & 11) are tightly coupled to self-organizing teams and communication. Besides the previous point about being too specific, the Agile mindset is based on a very different starting point. This is best illustrated by the Agile Manifesto itself: “Individuals and interactions over process and tools”; it contrasts to the defined process that Prince2 is about. The remaining conflict, principle 2, can also be explained using the Manifesto: “Responding to change over following a plan”. Again, these plans are at the core of Prince2.

What can we learn from this exercise in principles? The most important aspect is that the views and actions of project management should be fundamentally changed when they combine Prince2 and Agile. The two methods can be set up as complimentary, but the shift in paradigm for project managers is bigger than for their practicing Agilists specialist (teams). That shift is not easy. In fact it is really hard to change attitude and behavior, particularly when the pressure is high in a project. Sadly, that is why so many ‘Agile’ projects or organizations [9] slip and fall back to the same mistakes made by old school project management – years and years ago.

Contributions & References

[1] Prince2: http://prince2.wiki
[2] Mythical Man Month, F.P. Brooks: www.amazon.com/The-Mythical-Man-Month-Engineering-Anniversary
[3] Agile Project Mngmnt for Dummies, M.C. Layton:
Agile-Project-Management-For-Dummies
[4] Simplicity: agile-principle-simplicity-the-art-of-maximising-the-work-not-done
[5] JBGE Just Barely Good Enough, Scot Ambler: agilemodeling.com/essays/barelyGoodEnough.html
[6] Changeability: en.wikipedia.org/wiki/ISO/IEC_9126
[7] Agile Manifesto: www.agilemanifesto.org
[8] ScrumGuides: scrumguides.org
[9] Failing Agile- InfoQ: www.infoq.com/articles/agile-fails-enterprise

Filled Under: agile,agile projectmanagement,prince2,scrum,software development Posted on: 3 June 2016

Mission statement

Setup, guide and coach high performing teams capable in delivering truly great software.

Be Awesome

How? Try to improve something small everyday..... In management, in coding or life.

Learn from anybody

Be aware that every colleague, teammember or friend is capable of something that you are not.

Fail and letting fail

Failure is the only way to success, so fail fast and fail often, especially in software development.