Monthly Archives: mei 2016

Leading Image

Scrum wegwijzer – Gunther Verheyen

In 20 jaar tijd heeft Scrum zich bewezen en gevestigd als het de-facto standaard framework in het vakgebied van softwareontwikkeling. Ondanks dit grote succes bevinden veel organisaties zich nog volop in de Agile transitie. De ervaren professional in het veld heeft een blijvende behoefte aan een goed beknopt overzicht van het populaire framework. Voor beide doelgroepen is het boek Scrum wegwijzer – Een kompas voor de bewuste reiziger een handig hulpmiddel in hun reis door de wereld van Scrum.

In 2013 schreef Gunther Verheyen al het Engelstalige boekje Scrum Pocket Guide. Nu, drie jaar later, heeft hij een opgepoetste Nederlandse vertaling hiervan uitgebracht onder de titel Scrum Wegwijzer – Een kompas voor de bewuste reiziger. Verheyen zelf is momenteel werkzaam bij Scrum.org en bekend in Nederland en daarbuiten in het Agile werkveld als trainer, auteur en consultant.

In een kleine 90 bladzijden neemt hij de lezer in vier heldere hoofdstukken mee vanuit de oorsprong van Scrum naar de regels van het Framework zelf, gevolgd door de toepassing ervan. Het boek sluit af met een korte beschouwing over de toekomst van Scrum.

Hoofdstuk indeling:
1. Het Agile Paradigma
2. Scrum
3. Technieken versus regels
4. De toekomst van Scrum

De start van het Agile denken en de noodzaak om af te stappen van oude denkbeelden in de aansturing van kenniswerkers dient als basis voor hoofdstuk 1. Zonder af te dwalen schetst Verheyen de belangrijkste problemen en uitdagingen bij het invoeren van een Agile werkwijze. Met name de statements dat Agility geen eindtoestand is en een transitie niet is te plannen, zijn prikkelend.

In hoofdstuk 2 positioneert de auteur Scrum als een spel wat gespeeld wordt met als doel optimale controle te houden over software-ontwikkeling in turbulente omstandigheden. Net als bij andere spellen gelden regels waaraan alle deelnemers zich dienen te houden. Hoewel er niet veel regels zijn, vereist Scrum een grote discipline van de spelers. De opbrengst van deze regels en discipline is een ongekend potentieel aan motivatie, zelfsturing en probleemoplossend vermogen binnen de Scrum teams.

Nuttig en voor veel lezers wellicht een eyeopener, zijn de voorbeelden in hoofdstuk 3 van de verplichte regels ten opzichte van mogelijk inzetbare technieken. Juist de ruimte die teams hierin zelf kunnen nemen, biedt inzicht in de kracht en aanpasbaarheid van Scrum. Geregeld trappen meer ervaren professionals in de valkuil dat ze denken dat zaken ‘worden voorgeschreven’ vanuit Scrum. Enkel en alleen omdat ze bepaalde technieken in meerdere projecten hebben toegepast. Verheyen laat haarfijn zien waar de grenzen van de regels en de vrijheden zich in het spel bevinden.

Aan het eind van hoofdstuk 3 zijn enkele paragrafen gewijd aan het uitschalen van Scrum naar een groter verband, naar bijvoorbeeld meerdere teams of producten. Opvallend is dat bekende scaling frameworks als DAD, SAFe en LeSS ontbreken en zelfs Nexus, een initiatief vanuit Scrum.org, geen plek heeft gekregen. Wellicht is dit een bewuste keuze van de auteur. Een keus die in ieder geval zorgt dat de focus goed gericht blijft op Scrum.

In het laatste hoofdstuk geeft hij een korte verwachting van de ontwikkeling die Scrum de komende jaren in organisaties gaat maken. Stroomopwaarts, zoals hij het noemt, heeft Scrum de potentie om developmentteams te overstijgen en ook toepassing te vinden in management, productontwikkeling en zelfs in hele organisaties.



Het boek is vlot geschreven en laat zo nu en dan de raakvlakken zien met andere Agile frameworks. De kracht van het boek is echter gelegen in de sterke focus op de spelregels van Scrum. Door de beknopte schrijfstijl en het feit dat het boek Nederlandstalig is, is het zeer toegankelijk voor zowel de beginnende Scrum-enthousiasts als de meer ervaren professional of manager die zijn parate kennis wil opfrissen. Een boekwerk wat zich prima in een avond laat uitlezen en inzichten geeft om er daarna concreet mee aan de slag te gaan!

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

[edit 2019] Gunthers tweede editie is verschenen in het Engels, de Engelse review hiervan kun je hier vinden.

Cheers,
– Sjors Meekels

Note in English

This book review is in Dutch and is also published on www.managementboek.nl. Due to the fact that the book is in Dutch it did not make a lot of sense to write an English review. However an earlier version was released in 2013 and that was indeed in English. It was called Scrum – A Pocket Guide and is still available as well. If time permits I will also translate my review…..

[edit 2019] Gunthers’s next edition is in English and I gave it an English review, you can find it here.

Filled Under: agile,book review,scrum,software development Posted on: 22 May 2016

Leading Image

Principles, prince2ples, everywhere… Part I

Many Agile professionals in the field are wary to use terms like project management or even dare to consider possible benefits of Prince2 compared to the Agile way of working. On the other side the project management professionals, like the APMG [1] with AgilePM or Prince2 Agile from Axelos [2], are really hooking into the Agile way of working. Their approaching is, of course, from the management perspective. It is interesting to observe as to whether any shared values can be found. What better way to start investigating than the foundation of both worlds – their principles.

According to the Cambridge Dictionary a principle is:
A basic idea or rule that explains or controls how something happens or works.

In this diptych I will elaborate on the principles of one, perceived from the viewpoint of the other. In one corner stands Prince2, an acronym for PRojects IN Controlled Environment, described as a de facto process-based method for effective project management. The first version came out in 1989, followed by a few updates later on. At the moment it has seven core Prince2 principles. In the opposite corner we have the Agile Manifesto, containing 12 Agile Principles. The Manifesto and its principles emerged in 2001. As Prince2 saw the light in 1989, it is only fair to start with these principles.

1. Continued business justification
The Business Case is the most important document, and is updated at every Stage of the project to ensure that the project is still viable. Early termination can occur if this ceases to be the case.

In Agile terms no project artifact can be more important than working software. However, the ongoing justification of the business case should relate to the value delivered. This idea is at the core of the functioning of the Backlog and the priorities the Product Owner provides. Each sprint these can be redefined. In Scrum there is no official notion of a business case, just shifts in priority, followed by new stories to be picked up. These stories are driven by the value they generate for the business; that is as close to a business case as you might get.

2. Manage by exception
Regular meetings, especially the dreaded “weekly team meetings” are considered inefficient and unnecessary. Instead, work packages are assigned by Team Managers to Team Members including deliverables with time and quality tolerances. If work progresses smoothly then the workers have no need to interfere with the Team Manager’s time. Only if something deviated from the plan is communication and management required from them.

By far this is the principle Agilists get most agitated by. What do you mean, personal communication inefficient and unnecessary? A long story short, in Agile the approach is the opposite – by a mere 180 degrees.

3. Learn from experience
Each project maintains a Lessons Log and projects should continually refer to their own and to previous and concurrent projects’ Lessons Logs to avoid reinventing wheels.

Good, learn from your own experiences and those of others. Within Scrum we are accustomed to looking back and forward each sprint in order to improve ourselves. In that way, we can hardly disagree with the third principle. Learning in Agile teams, however, is a team matter and is effectuated more hands on. All team members actively participate and the stage is set in each retrospective for so called “full disclosure”. In contrast of the Prince2 way where the project leader is responsible for keeping the logs, these may even be unknown by the team. The learned lessons log resembles the good intention of a paper tiger. From the Agile perspective it is not helpful enough and the distance to the team and everyday work is just too large. So the principle is good, the effectuation in practice is far less.

4. Defined roles and responsibilities
Roles are separated from individuals, who may take on multiple roles or share a role. By naming and defining roles in the Prince2 standard it becomes clear exactly who has what responsibility and decision making powers, avoiding arguments.

Roles and responsibilities are important for organizing groups of people who work together. In Prince2 the defined roles are those of all people involved except the actual team members. The two methods overlay on the roles of Team Manager and Project Manager on one hand versus Scrum Master and Product Owner on the other. It might be interesting to see how these roles are mixed and mingled; or even further, how all roles from both worlds may be complementary to one another. They both have a different approach, Prince2 provides the maximum configuration whereas Scrum describes the pure basics. But I ought to stay focused on the underlying principles here. In my opinion it is clear the principle of clear roles and responsibilities is shared, they just describe roles from a different angle.



5. Manage by stages
The project is planned and controlled on a stage by stage basis. This includes updating the Business Case, risks, overall plan, and detailed next-stage plan after each stage in the light of new evidence.

Stages as such are not a known concept within Scrum. What we do use is the notion of small iteration with focus on a subset of the entire scope. And that is exactly what stages are intended for as well. The project scope is not managed as a whole but is divided into concrete smaller portions. As with Scrum, the idea of a smaller scope, and thus with fewer risks or pitfalls, leads to a better manageable period of time.
Sprints are the rhythm and ‘stages’ of Scrum. You could argue the planning session of a new sprint resembles the ad-hoc making of a next-stage plan. The Backlog, output of the retrospective and input from all team members is used; these reflect the business case, new evidence and all kinds of logs. The exact way to manage stages is different, for one we tend to minimize the production of voluminous documents. Another difference is the length of a stage. Of course this depends on the type of project, but a stage of two weeks is not all that common. Back to the principle at hand, again the form differs, yet they both appreciate the value of the principle.

6. Focus on products
Each work package is defined by one or more deliverable products, preferably with tolerances to time, cost, scope and quality quantified in advance.

Why would Prince2 keep such a focus on products? It does help if a team knows up front what the requirements are for the software they are going to work on. The better these work packages are described, the better a team can make estimations and do programming on them. That sounds familiar. In Scrum we focus on concrete finished user stories at the end of a sprint, measured against the definition of Done. In that way the factors scope, cost and quality are taken into account. The teams’ direct influence on the stories, mini work packages, in Scrum is much larger. Still, we can conclude this principle is valued in Scrum.

7. Tailoring
Prince2 should not be applied blindly in a dogmatic, bureaucratic form. Rather it is defined to be a method in need of tailoring to specific projects.

Tailoring enables teams and projects to adjust the processes, documents and other parts to fit their needs. Prince2 has a variety of means to manage projects of any size. A dogmatic attitude is the arch enemy of an Agile project. In Agile we use the motto “Scrum the Scrum”. That is the exact same. So the two methods can embrace each other without a fight on this principle.

Halfway conclusion

We have reviewed the 7 principles that form the basis of a Prince2. Short to say is that 6 out of 7 principles are well rewarded in Scrum and only one principle presents a direct conflict. Is this a surprise? No, it is not. Scrum and Agile don’t have a monopoly on good principles. Besides that Prince2, has been designed on years of project experiences and has evolved over the years. But to say the least, Prince2 was never as successfully as Scrum is today. Before judging the rate of success based on principles, we will have to discuss the Agile principles from the Prince2 perspective. That subject is covered in the next part of this Blog. One cliff hanger though, the team and persons are much more centered in Scr…

Cheers,
– Sjors Meekels

Contributions & References

[1] AgilePM: http://www.apmg-international.com/en/qualifications/agile-pm/agile-pm.aspx
[2] Prince2 Agile: https://www.axelos.com/best-practice-solutions/prince2/prince2-agile
[3] Definition Principle: http://dictionary.cambridge.org/dictionary/english/principle
[4] Prince2: https://www.prince2.com
[5] Prince2: https://en.wikipedia.org/wiki/PRINCE2
[6] Agile Manifesto: http://www.agilemanifesto.org
[7] ScrumGuides: http://scrumguides.org/

Filled Under: agile,agile projectmanagement,prince2,scrum,software development Posted on: 17 May 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.

Fail and letting fail

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

Learn from anybody

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