Happy Scrum Year

I hope your beginning of the year 2014 was as good as mine was. I wish you a great future no matter!

Crossing from one year to another is often a time for some retrospective introspections. It is a time where we more naturally step away from the daily, monthly and quarterly rush to look back and learn in the face of the upcoming times. As a result, but even besides it, it is also a good time to reground ourselves. Obviously we should retrospect and reground more often, but let’s say that this is a good time to absolutely do it.

My life has much to do with Scrum (below picture has some 2013 highlights). Here are some simple foundational aspects of Scrum I’ve ingrained over the years. They have often helped others to keep grounded or reground. These are bare basics that may seem non-essential at first sight. They have little value when respecting them. However, they become more essential when not respecting them. Not respecting them diminishes credibility in the communities, and it damages how Scrum is seen outside of the communities.

  • Stop calling Scrum a ‘methodology’. It is not. It is a framework. Note that we have even overcome the perception of Scrum as a method for ‘Agile project management’, and the Scrum Master as an ‘Agile project manager’. Focus on the software product, continuous discovery and value.
  • Stop writing Scrum in capitals (“SCRUM”). Scrum is not an acronym, nor an abbreviation. Write “Scrum”.
  • Cherish that Scrum is incomplete. It is by design. This is not a restriction nor a dysfunction. It takes away the illusive and deceptive certainty that from the method itself every possible answer, for every possible situation, at any possible time can be deduced. It applies to any method but Scrum makes it explicit. Use Scrum as a foundation, and apply the ScrumAnd thinking to address your specific problems and situation.

Happy Scrum Year (2014)

Writing Scrum Writings

On top of managing the agile offering of Capgemini (Dutch description here) as a Product Owner and mentoring our Scrum coaches and Scrum trainers I also give Professional Scrum trainings.

Scrum.org-Logo_with_taglineAfter my classes I send out a thank you to the participants in which I include some guidelines to prepare for the online assessment they get access to. I also point people to some background readings. Over time I have created a small library of blog notes I’ve written from which I can select some to refer attendants to for additional information on top of the courseware:

I always pick some of following topics to add:

Fyi. have a look at the most beautiful location I have ever trained in.

Take It To The Team

Lyssa Adkins - Coaching Agile TeamsI have read Coaching Agile Teams by Lyssa Adkins in a gradual way. I regularly stopped reading for a while because I wanted time and mental room to absorb, practice and reflect about what I was reading before continuing down the fascinating path of insights offered by this book. Although I require from every professional book to give me something I can immediately apply, in this case the richness was so huge that the need to stop-start seemed a lot bigger. I also regularly stopped reading to take my newest gained words and insights to the team; test and try them, plant some seeds, watch out for sparks that might turn into a fire.

In Short

Lyssa Adkins has written a very comprehensive book that covers a great, all-round collection of topics concerning agile, professional coaching and… agile coaching. She uses her past of traditional project manager to describe how she discovered the beauty, the power and the value of agile via Scrum and self-organization. But Lyssa is also a co-active coach, doing coaching from a peer perspective with an emphasis on active collaboration between coach and coachée. The book blends the aspects of agile (via Scrum) and (co-active) coaching in a fantastic and enlightening way. But I highly appreciate Lyssa’s strong emphasis that our journey as Scrum coaches is not only about coaching in general, nor about life, personal or love coaching but that it’s about agile coaching. It’s about helping, mentoring, facilitating people, teams and organizations to become great in agile, to achieve high performance through agility. And that is a lot more than producing still mediocre products, just faster.

Audience

On its cover the book says to address a rather broad audience (‘A companion for Scrum Masters, Agile coaches, and project managers in transition‘). But I see Scrum Masters as an important target audience:

  • Because the book has its origins in Scrum, the most applied agile framework, and Scrum foresees the roles of Scrum Master, Product Owner and Development Team.
  • Because this companion holds extremely useful material on behavioral aspects in facilitating Scrum and from my practical experience and as a Professional Scrum trainer for Scrum.org I see much room for improvement there for many Scrum Masters.
  • Because Scrum Masters are expected to be coaches too, doing much more than just managing the process of Scrum.
  • Because too many people think ‘coach’ is a title to achieve, and not a level of mastery to grow into.

Lyssa clearly depicts what it might take to ‘be’ a Scrum Master (or agile coach as you wish), not just ‘do’ it. Remember that, as servant-leaders, Scrum Masters help the other roles within the Scrum Team to play their part (like a conductor would do, one of Lyssa’s metaphors). They help Development Teams achieve great team dynamics. They help Product Owners interact with stakeholders and discover better product ideas. They inform the organization about the Scrum process. They promote agility, agile behavior and the agile principles. They make sure that the wider organization gets the absolute maximum out of Scrum, as part of the continuous search for the art of the possible. And Scrum Masters know how to adapt their communication and working style according to place, time and audience.

Content

Coaching Agile Teams starts by helping the reader to introspect on behavior, habits and attitude in “Part I: it starts with you”.

Part II (“Helping the team get more for themselves”) obviously is the main part as it shifts the focus to the role of a facilitating coach towards the team. It does so by highlighting the various appearances a team facilitator might want to learn to master, the natural fluency with which appearances can be switched, the honesty and openness it takes to learn and admit failures while learning. Some important coach appearances include the teacher, the mentor and the conflict navigator. Throughout Lyssa offers advice, techniques and insights all based on practical experience.

In Part III (“Getting more for yourself”) Lyssa reverts back to the reader with a chapter that describes failure and success modes, skills and abilities that might help and war stories of some world class coaches. It makes most sense for experienced and seasoned practitioners. The danger of reading this chapter too soon is that people will turn some of the topics into incentives, objectives and goals to strive for, rather than real life findings one wants to match his/her personal experiences against.

At a personal level

Lyssa’s book has helped me in many ways. It gave explicit words, a vocabulary, to some of my existing -often unspoken- observations, practices and behavior. It enriched my existing ways of working with additional insights, evidence and perspectives. It offered many new ideas, insights, practices, papers and backgrounds. It helped me further transcend the technical views on agile and Scrum with the book’s strong focus on human behavior, psychology, people and professional coaching. And I can share this transcendent perspective better with others now.

Many great books on agile have I read, but Coaching Agile Teams by Lyssa Adkins is one of the few agile books that truly changed my life. And it’s been a while since I had that feeling over an agile book again.

Impediments (and where to find them)

Probably the most known purpose (task) of a Scrum Master is to remove impediments. If that is reassuring: it’s even described in the Scrum Guide. A Scrum Master is indeed ‘officially’ expected to remove impediments to development and to the Development Team’s progress.

Unfortunately, this is sometimes interpreted as the Scrum Master having to be an ‘impediment hunter‘. That suggests that a Scrum Master should proactively search for impediments in order to track them down and kill them. There is a danger in this wording, besides the very negative feel to it. I particularly wonder how this aligns with the self-organization of teams and transparency? Self-organization is essential in Scrum and it’s to be promoted, served, coached, taught and mentored by that same Scrum Master. Transparency is required to know about reality, inspect it, learn from it and make proper adaptations.

An impediment is an “obstruction; hindrance; obstacle”. And Scrum is a framework that helps teams in finding better ways to create working software in 30 days, or less, and handle the complexity attached to that. An impediment in Scrum is therefore anything that blocks the (development) team in its creation of a valuable piece of software in a Sprint, or restricts the team in achieving its intrinsic progress.

Where to find an impediment?

We can expect a team to raise an impediment, any annoying problem that is truly blocking them. Actively looking for (‘hunting’) and removing impediments is solving problems that are not a problem yet. It assumes that a Scrum Master, as 1 single person, knows more -or pretends to know more- than the united brains of a complete team of up to 10 people; a team that daily makes hard choices by disciplined collaboration.

Solving a problem before it’s a problem points at a lack of belief in the self-organizing capability of a team. Solving a problem before it’s a problem prevents learning and improving because it obfuscates transparency to the team. Solving a problem before it’s a problem is mostly a waste of time and energy because the team will probably handle it by itself anyhow, without the Scrum Master, preventing it from turning into something that truly blocks them. They probably even solve more problems than the Scrum Master knows or can imagine.

It’s simple, an impediment is not an impediment if it hasn’t been raised by the team. Impediments cannot be anticipated. And if there undeniably is an impediment (not an anticipated one and not an issue that the team is already handling) and it is not being raised, the question of the safety of the environment arises. What is preventing the team from raising the impediment?

Not raising an impediment does block the team. What’s then the real problem for the Scrum Master to solve?

What does an impediment look like?

Issues only become impediments if they cannot be tackled within the self-organizing ecosystem. The concept of ‘impediments’ is not a replacement of the traditional escalation procedures. Traditionally people are told to escalate whatever bothers them to a person external to their work to solve it for them. Easy and convenient. But is it also helping?

Scrum delivers great results because it thrives on self-organization, accountability and skills; it appeals to those elements. Scrum restores the respect for people and the understanding of software development as complex and creative work. By definition, in Scrum an issue only becomes an impediment if it can’t be unblocked through the authorizations of the (development) team.

Let’s illustrate this with the example of a team conflict, a conflict between team members.

A team might have problems in resolving a conflict and call the conflict an impediment, expecting the Scrum Master to remove it for them. They expect the Scrum Master to solve the conflict. However, working as a team inevitably includes getting to know each other, finding ways of building software together, exploring different ways to collaborate, outgrowing the desire for personal heroism, and improving through constructive disagreement. Conflicts are a part of working with people, part of becoming a self-organizing team, part of aiming at high performance.

Once again we should raise the question what the real problem for the Scrum Master is to solve? Is it the Scrum Master’s role to solve the conflict? Or would that be an undesired intervention in the self-organizing ecosystem, undermining future honesty, learning and self-improvement? How can the Scrum Master facilitate self-organization? Is it by offering teams an excuse, an external decision to hide behind? Consider how to help a team work out their problems themselves and offer any tools, trainings and insights on how to do this.

Not dealing with an issue does block the team. What’s then the real problem for the Scrum Master to solve?

Another dog year gone by, 2011 in review

Zo’n goed jaar geleden (30 januari 2011 om exact te zijn) publiceerde ik hier een bericht onder de hoofding Brief aan mijn Psycholoog. Het was een openhartige terugblik op een woelig 2010. Alhoewel we ons terecht de vraag kunnen stellen welk jaar uiteindelijk geen ‘woelig’ jaar is, voelde ik de nood om -tijdens een korte, maar prachtige familiekerstvakantie- een iets meer gestructureerde terugblik te wijden aan het -op dat moment- aflopende jaar. En al doende werd het blikveld ineens verruimd naar… mijn leven. Uit het geheel van terugblikken putte ik moed voor het -op dat moment- aanstormende 2011 op vlak van mijn Bruto Persoonlijk Geluk. Intussen kan ik al verklappen dat 2011 leerde dat ik op en top een Type I ben volgens de Motivation 3.0 van Daniel Pink. Een grootse toekomst ligt daarom duidelijk in het verschiet!

Nadat ik eerder al terugblikte op mijn statistisch blog-jaar (Another blog year gone by) en mijn top-muziek-jaar (Another sound year gone by), wil ik hierbij een vervolgje breien aan mijn persoonlijk jaaroverzicht 2010 door ook 2011 in kaart te brengen.

Uit de curve van einde 2010 die ik opnam in de  Brief aan mijn Psycholoog bleek de verwachting dat er een sterke groei zou zijn vanaf april 2011. Wel, het werd uiteindelijk juni, maar de groei was daarbij nog veel explosiever dan verwacht. Een mutatie binnen Capgemini leverde me na 8 jaren roepen in de IT-woestijn een fenomenale doorbraak in Scrum op. Net daarvoor (april) had ik Ken Schwaber nog naar Brussel gehaald voor het Agile Consortium België en een week later woonde ik, op uitdrukkelijke uitnodiging van Ken zelf, zijn sessie van de nieuwe PSPO cursus bij in Amsterdam (Professional Scrum Product Owner). Dat ik hiervoor privé-vakantie moest nemen, is intussen al lang vergeten omdat het me de kans gaf om de nodige certificaten te halen in PSPO, waarna ik goedkeuring kreeg om Professional Scrum trainer te worden in zowel PSM (Professional Scrum Master) als in PSPO. Door administratieve perikelen raakte het uiteindelijk pas gefinaliseerd in de zomer, wat op dat moment dan weer een sterke impuls in goed gevoel opleverde. Het najaar bracht vooral veel werkdruk, evangelisatie en trainingen (maken, geven en trainers trainen). Daarbij werkte ik aan publicaties op mijn blog maar ook op de award-winning blog van Capgemini, Capping IT Off, maar het hoogtepunt was de overname en publicatie op Scrum.org van mijn paper, The Blending Philosophies of Lean and Agile.

Privé bracht het jaar stabiliteit in de Duchenne-aandoening van onze oudste zoon, gingen we tijdens de kampen van onze zoons met de dochter naar Parijs en met het voltallige gezin hadden we een fantastische vakantie in Frankrijk. Op het einde van het jaar maakten we nog een chaotische uitstap naar London, die dan weer net op tijd kwam om een stevige professionele dip te verwerken. In de loop van het wilde 2011 moesten we verschillende elektrische toestellen vervangen. Maar dat resulteerde uiteindelijk ook in de aanschaf van Digitale TV (bij Telenet), en dat leidde tot een erg voldaan gevoel. Niet omdat ik met mijn Scrum Teams in de periode 2003-2006 hier zelf mee de basis van legde door de ontwikkeling van het Core Server Platform ervan, maar door de kwaliteit en de mogelijkheden. Na lange jaren en manmoedige inspanning was ik totaal niet meer verknocht aan het kijkkaske, maar met dat digitale gebeuren kan ik prima leven. Bij de meeste voldoening haal ik echter uit de realisatie van mijn eigen poëziebundel, La NOuvelle Cycluste (ONgekelderd en NOg dicht), nog steeds te verkijgen bij Unibook.com trouwens, maar ook de vrijgave van mijn lang geleden gerealiseerde muziek als hHijirt! op MySpace.com (niet dat dat nog een aantrekkelijk platform is, to be honest) onder de naam waar ik mijn toekomstige muziek onder wil componeren, Shifting Cargo.

Een erg opvallende evolutie op de scheidslijn van privé en werk (als die scheidslijn er al is in mijn werkaholisch geval) is dat ik nu geregeld op hotel vertoef, voor trainingen en om klanten (vooral in Nederland) te ondersteunen.

Ik heb de evolutie van 2011 doorgetrokken op deze van 2010 (en het leven dat daarvoor al had plaatsgevonden):

En wat brengt 2012?

Grootse plannen. Gewoon verder doen. Ik ben vast van plan om door te gaan op het ingeslagen pad, maar met wat noodzakelijke blikverruiming. Beetje afbouwen qua working like a dog. Terug een beetje borduren bijvoorbeeld en al eens terug wat literatuur lezen.

Personal Professional Scrum

Precaution: the author (me) is lately sharing a load of personal, retrospective findings with the world (you). Must be that he’s leaving some troubles and worries behind him. Or maybe it’s just the pills he’s taking?

It wasn’t until I started doing projects upon eXtreme Programming (2003) and Scrum (2004) that I finally found my way in IT, and started feeling at ease at a personal-slash-professional level. It then still took me several years (>2011) to find a professional homebase (some call it an employer) where I could really ‘go’ for my Agile and Scrum ways.

In the early years I never cared about profile or promotion; just me, expertise & the teams. But on the cross-point of deciding yes or no to stay in IT consultancy, I decided to give it one more chance. But it would be a ‘make or break’ and it had to be Agile and Scrum. I resurrected the knowledge and experience hidden in my brain and started publishing about it again. I finally went to Capgemini (March 2010), attracted by the fact that they had co-founded the Agile Consortium Belgium.

This was around the time that saw the emergence of Scrum.org by Ken Schwaber. I had my CSM by Ken back in 2004 but that was it. Never even considered CSP, CSC, CST or any other CS*. My reluctance for profile and promotion, you know. I liked the feel and the why of Scrum.org and engaged early. Full of doubts, but I demonstrated a good understanding as Professional Scrum Master, level I and level II. Confidence grew, I applied for PSM trainer, went to a PSM course by Ken (December 2010) and qualified as trainer.

Happily invited at an early class of the new Professional Scrum Product Owner program (April 2011), I fully subscribed the program’s goal of reaching out to Business people and helping Agile Product Management emerge. I demonstrated my understanding and my training qualification was extended with PSPO.

After a little migration within Capgemini I am now in the greatest position ever of working day and night in promoting, maintaining, supporting, coaching, training and facilitating Scrum; internally as well as at customers, locally (Belgium and Netherlands) and globally. And the Capgemini Academy is rolling out a training offering for private and for external audiences that combines:

  • Our Capgemini trainings: Scrum Kickstart, Scrum for Product People and Scrum for Managers;
  • The official Scrum.org trainings PSM and PSPO.

Our strategy connects to the vision of Scrum.org in presenting Scrum as a tool for Business Agility, not as an end in itself. As from Capgemini I sincerely hope to have impact but from a positive, open and adaptive attitude. Not grumpy or bitter or aggressive. Knowing that the path to Agility will remain a cobblestone path and there will be ups and downs. Keep an eye on the overall progress trend, a burnup chart of Agile values and Agility. Make the world a better place (to work in).