agile – Pagina 3

Category Archives: Agile

17 Jun 2017

Interview with De Baak – Sjors Meekels

Being a manager-freak does not necessarily change while working Agile.

Daily planking to ensure short and concise sessions
I am now in an environment where we need to work with several teams simultaneously. In order to let people interact in another way, among others, I organize boot camps. Working out together; that is an excellent way to get to know each other better. It is team transient and it creates short lines. If you also know people from a different setting, it will make a difference than just passing the office. In addition, I have also seen organizations where they do the daily stand-up in the planking pose. Be sure that it helps keep things short and concise.

Working Agile won’t solve all problems, it does make them very visible though
I have been enthusiastic about working with agile teams and organizations for years. Being part of the IT side of an organization, you know how difficult it is to build things well and, on the other hand, to build the right things. The faster the uncertainties and problems that clutter the process are made clear, the better it is for everyone.
Sometimes you see new management that thinks ‘that’s a great method that will solve a lot of things for us’, they are wrong. Agile does not solve organizational problems. It will help, but the problems themselves are not resolved. The problems are systematically and quickly made visible.

Trust is an important bottleneck in transitions
An important bottleneck in an Agile transition is to keep everything controlled. One of the values of Agile is to make teams responsible and in control. Make them self-organizing to solve problems and do everything needed to become successful. This requires trust from managers and the room to fail. Sometimes this proves to be hard, it is not how we are used to run companies or departments. For all distinct roles we had people, procedures and guidelines. To overcome this, is a major challenge for a lot of organizations.

Don’t envy a Product Owner’s position
The Product Owner is the one who determines what is being build and in which order. He also ensures that stakeholders are involved continuously. It is a crucial role. The Product Owner must act in a field with many different interests, multiple stakeholders and many different priorities.
Classic is the contradiction between developing new customer demands versus upgrades or maintenance of systems. New opportunities then collide with the continuity of the systems.
So, you’ll have to be an excellent Product Owner with a good vision of what is best for the company. ‘Quick wins’ and stability of the system should be considered. That is an unfortunate position! A product owner must act as a small entrepreneur and be daring. In my opinion, this is the most critical role in an Agile environment. The Product Owner is the one controlling flame or fame.

Cross team knowledge sharing: Lunch pitches
Also within an Agile context knowledge sharing will not happen on its own. If a team has gained brilliant insights, as an organization you’ll want other teams to learn from it. At one organization, we actively went shopping at the teams. If you have something you would like to share, please let us know, we will schedule it. We made sure that were no blockers: at lunch time! There are always a few first movers who will stand up: I have something to share. ”

Does Agile impact the way we communicate?
Communication per se? I do not see that would be very different if you work agile. If you were a freak in the old organization, you can be one in the agile organization as well.

About this interview

This interview was originally in Dutch and held for De Baak, in case you’re interested: interview. De Baak is one of Hollands leading firms when it comes to education on topics as management and leadership. More information about De Baak can be found here: www.debaak.nl. Any faults in the translation can only be my mistake…

Download blog as PDF

This blog is available here:

Filled Under: agile Posted on: 17 June 2017

14 Apr 2017

Product Owners in DevOps: What dominates your Backlog, Urgent or Important matters?

Product Owners have a great responsibility in prioritizing the work on the Backlogs. Their role can hardly be underestimated. How about some support from the past? Decades ago Eisenhower made a quote on important and urgent matters. His idea has transferred into a matrix used to prioritize personal actions. Can Eisenhower’s priority matrix help Product Owners in prioritizing backlog items? I think so. In this post I will combine Eisenhower’s ideas with those of Agile product backlog management, and a little wild life.

Eisenhower’s matrix
In short, Eisenhower’s matrix focuses on four distinctive quadrants created by the two viewpoints – urgency and importance. The goal is to determine someone’s priorities [1][2].

Urgent matters: require immediate attention. If possible you should act on these matters now. Important matters: these relate to long term objectives and need constant focus. When combined this leads to the following overview and actions:

Now let’s transpose these quadrants to backlog management in an Agile environment. All work on the Backlog can be qualified according to Eisenhower’s quadrants. But what is the optimum setup for your Sprint Backlog? Is there any? Based on the model, I will discuss a set of situations which are all taken from projects and teams I have worked with over the years. In these situations, teams are working on Product Backlog Items that primarily originate from one of the quadrants. To make teams easily recognizable, they all have a different nickname which sticks out.

1. Orange Firefighters, brave and busy

If your teams are busy working on the urgent important issues or new work of this category is entered each running sprint, it seems like your devops-teams are firefighting. This is only a good thing when a) there is an actual fire and b) – more importantly – they can extinguish the fire. If this pattern is more the rule than the exception, changes are something is not OK. This could relate to your production environment, either the applications, the infra, people handling it, or all. Try to look for the root causes and fix those, via the regular process of course. Instead of focusing on optimizing the fire-hoses and firemen. Although your teams are working on the top priority work items, there are risks and down sights. For example, every Product Backlog item which is refined or taken in the sprint and pushed out by the orange firefighters, has been a waste of time. Moreover, the company’s short term future may get hurt if this situation occurs for too long a time.

PROS: working on top priority items, CONS: waste in preparation time, pressure within teams, ATTENTION: should not persist for long, focus on fixing root causes!

2. Blue Coyotes, opportunistic

Sometimes teams are working on urgent but not important issues sprint after sprint. These teams are the so-called coyotes. This scenario also raises an interesting question. Are those issues really urgent? If you and your team tend to say no, there should be a dialogue. Re-discuss these issues with your stakeholders and try to balance them out with your company’s important stories. In practice it is more convenient to work on topics that are urgent to our stakeholders now. However, don’t go for convenient, but invest in discussions and long-term goals.

Okay, so are you done when the answer is yes? Well, sorry, no. If this situation is continues for a long period of time, it could be a sign that you are understaffed. Not working on the important issues, could be a serious threat to business continuity on the long term. Perhaps you can consider to appoint a temporary team that can eliminate the ‘pile’ of urgent stuff, which is in the way of working on the important stories. However, one thing should be in place before you scale up: a clear vision on what is actually important. This may sound like a no-brainer, but more than a few Product Owners are struggling in identifying what is really contributing to the company’s future.

PROS: satisfying to stakeholders, CONS: not working on the long run, ATTENTION: are backlog items really that urgent or is there too much stuff in the way?

3. Green Tortoises, steady but a bit boring

The third scenario reflects the mindset of the tortoise. Namely, where the majority of the work directly relates to important backlog items. Good for you, you keep the company or department in business. However, you might be missing out on immediate revenues from low hanging fruit. Why not optimize your SEO rank now and then, or eliminate that bug 80% of your users are complaining about? These small improvements won’t harm the long-term objective and they do give you a change to help users, increase the short-term cash-flow and satisfy a few stakeholders along the way. Like their nickname, these projects or teams can be a bit boring and move slowly towards a certain ‘old age’ or goal. In their journey, they could lose the connection with the rest of the organization when results are not made visible in the meantime. Besides that, if these projects entail migration without new functionalities, also the teams can get bored. They may benefit from the diversion of small improvement stories.

PROS: working on the mission of the company, CONS: in long running projects stakeholders can get detached, ATTENTION: room for quick wins along the way?

4. Well… Black Dodo’s

If you have teams working on the black stuff, something is off. Perhaps you are way overstaffed, or backlog management is in utterly disorder. Avoid this situation at all costs. When nothing changes soon these teams will become extinct…

PROS: none, CONS: waste of time and energy for all, ATTENTION: immediate action required!

Balancing act, rhythm and focus

Do you feel like you are getting mixed signals now? You are right. This is the arena where great Product Owners can stand out of the mediocre crowd. If they are able to balance the Product Backlog with the stakeholders and find a rhythm together with their team(s) to ensure enough focus, you have a winning combination. Relevant questions to be answered are: Who is your most important stakeholder? And how are competing stakeholders managed? What is most important for the customer and the future of the company?

A predicable heartbeat helps the team and PO in delivering on regular intervals. Yet, it also promotes alignment in the rest of the organization. The characteristics play an profound role in the optimum heartbeat. For example, if you are part of a true DevOps team, you know ad-hoc work (important and urgent issues) will emerge and that is part of your sprint routine. In another case you might have a more component oriented team, building stuff for other teams.

If you only have one development team available, the balancing act of shifting priorities becomes more precarious. The team can feel comfortable working on multiple topics in one sprint and it is not forbidden to do so, as long as there is enough clarity and stories are really Done at sprint’s end. However, most teams benefit from focus during the sprint, so when possible, craft your Sprint goal on one or two categories only. You could for example spend one sprint on urgent matters and the next two or three on the important trajectory. In general, true orange stories are always executed asap. When multiple teams are involved you can have more flexibility and for example rotate duties between teams every few sprints.

Last thoughts

So, Eisenhower can help in identifying certain wanted or unwanted patterns in your current Product Backlog. What it cannot do is provide the ‘correct’ distribution. That task is still meant for the Product Owners and their teams. I am curious, what kind of wildlife represent your teams currently and how is your Backlog setup in terms of Eisenhower’s quadrants?

Cheers,
– Sjors Meekels

References

[1] Eisenhower: http://www.eisenhower.me/eisenhower-matrix
[2] Eisenhower: http://www.businessinsider.com/dwight-eisenhower…..
[3] Coyote: https://nl.wikipedia.org/wiki/Coyote
[4] Tortoise: https://en.wikipedia.org/wiki/Tortoise
[5] Dodo: https://en.wikipedia.org/wiki/Dodo

Download blog as PDF

This blog is available here:

Filled Under: agile,devops,scrum Posted on: 14 April 2017

14 Nov 2016

Must I Do This Now? In an Agile context

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

Must I do this now?

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

1. [MUST] I do this now?

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

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

2. Must [I] do this now?

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

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

3. Must I [DO] this now?

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

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

4. Must I do [THIS] now?

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

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

5. Must I do this [NOW]?

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

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

Agile & Common sense

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

Side note

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

Cheers,
– Sjors Meekels

References

[1] MoSCoW method: en.wikipedia.org/wiki/MoSCoW_method
[2] Sprint Goal: www.scrumguides.org/scrum-guide.html
[3] Eisenhower Decision Matrix: www.artofmanliness.com/2013/10/23/eisenhower-decision-matrix
[4] Origin I Moet ik dit nu doen: lifehacking.nl/persoonlijk-tips/moet-ik-dit-nu-doen (Dutch)
[5] Origin II Moet ik dit nu doen: www.carrieretijger.nl/prioriteiten-stellen (Dutch)
[6] Grammar Must – to have to: www.englishgrammarsecrets.com/musthaveto

Download blog as PDF

This blog is available here:

Filled Under: agile,interim management,scrum Posted on: 14 November 2016

05 Sep 2016

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:

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.

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!

Cheers,
– Sjors Meekels

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

Download blog as PDF

This blog is available here:

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

24 Jul 2016

Scrum Day Europe 2016

In the first week of July the fifth version of the Scrum Day Europe was held, this was Scrum Day Europe’s first anniversary. Again it was hosted in the beautifully located Pakhuis de Zwijger near the center of Amsterdam. As with a lot of conferences you need to make choices because there are more sessions than time permits you to join. Today I’ll give my thoughts on three I joined and end with an overall opinion.

Keynote – Dave West (Scrum.org)
In his keynote Dave West looked a bit back on the progress Scrum has made in the last years and the challenges that are still present. Especially the getting things really “Done” is one of the big topics this edition and after more than 20 years is still relevant. He also gave a glimpse of the ideas concerning Scrum Studio and setting up a separate organization disentangled from the “old slow organization”. In his afternoon session he went into more detail on this topic, but he did gave the most away in the keynote.

“Saying goodbye to command and control for good” – Christian Brath (Movingimage)
Before this session I never heard of the Berlin company Movingimage but after today the impression will last. During the coffee in the morning I already met Christian and his story intrigued me to go and join his presentation. His company Movingimage has re-invented their business models and therefore also their own organization. They went as far as transforming the entire organization in an Agile setup. They iterated in a few steps to their current model. Of course when flattening the hierarchical structure of your organization you are bound to run into questions like “Who is doing the annual appraisals ?” and “How about conflicts between backlog priorities of different team?”.
Christian was very open and said that not everything is already in a well working definitive state. For me this only indicates that such transformations take years Even after years you will come up with the conclusion that the Agile way of working and transformation will never really stop.

“The future present of Scrum – Are we Done yet?” – Gunther Verheyen (Ullizee-Inc)
I have heard Gunther speak before and have read his book “Scrum wegwijzer”. He can always reduce the complexity of Scrum to the core and focus on the most important subject to discuss. Well today that is getting really working Increments after a sprint. It seems that most organizations still struggle with getting actual working software of the belt at the end of the sprint. Interesting to notice that this is still so hard after 20 years of Scrum. He focused on getting to the root of the problems for not getting to Done, is it the Definition or is the delivery process? In the end it does not matter as long as you involve your Scrum Masters and management and get all impeding affairs out of the way.
His weblog and slides can be found here: The-future-present-of-scrum and here scrum-day-europe-2016-the-future-present-of-scrum. So ask yourself the question, how often does your team or organization deliver working increments? And if not every sprint, what is holding them back?

Wrap up

All in all it was an interesting day with some good sessions. Personally I would have expected to see more people from previous editions and some more acquaintances. At the start of the day a short inventory was done and roughly 80% of the audience was there for the first time and after a steep decline only a handful had visited for over 3 times.

A downside of the way this conference is organized is that you can expect a lot of sessions (co-) presented by people from Prowareness. In itself this is not necessarily a bad thing but bit more variance can be a good thing. The up side is that the people who where present were enthusiastic and I have enjoyed a lot of interesting coffee breaks as well. Enough reasons to come back next year.

See you there in 2017, you can already save the date on July 6!

For more detailed information about this years edition and of next years see: www.scrumdayeurope.com
You can check out a part of the presentation here: www.scrumdayeurope.com/sde-2016
Please note that not all slides are currently present.

Cheers,
– Sjors Meekels

Download blog as PDF

This blog is available here:

Filled Under: agile,scrum Posted on: 24 July 2016

17 Jul 2016

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.

Cheers,
– Sjors Meekels

Note in English

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

Download blog as PDF

This blog is available here:

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

10 Jul 2016

Dilbert saves the Agile day

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

‘One Dilbert says more than a thousand words.’

1. Chairs and pants
DILBERT © 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 © 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 © 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 © 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
The last cartoon is not an original Dilbert comic but originated from Luca Minudel in 2011: https://www.flickr.com/photos/lucaminudel/6059269914/

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

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

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

Cheers,
– Sjors Meekels

Download blog as PDF

This blog is available here:

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

21 Jun 2016

Agile Project Management with Kanban

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

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

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

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

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

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

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

Cheers,
– Sjors Meekels

Note in English

Download blog as PDF

This blog is available here:

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

03 Jun 2016

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.

Cheers,
– Sjors Meekels

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

Download blog as PDF

This blog is available here:

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

22 May 2016

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.