A daily Scrum Master BONUS podcast on re-vers-ify

The conversations I had with Vasco Duarte about Scrum, Scrum Masters and Scrum Master challenges were broadcasted in the week of 17-21 April 2017.

As an extension Vasco asked me to clarify the ideas I had expressed as “re.vers.ify“. Our conversation has been broadcasted on 21 May 2017 and is NOW AVAILABLE at the Scrum Master Toolbox website.

In “re.vers.ify“ I have consolidated over a decade of experience, ideas, beliefs and observations of Scrum and organisational transformation through Scrum (or the lack thereof). Re.vers.ify is an act, an act of simplicity, rhythm and focus. Re.vers.ify is a way for people to re.imagine their Scrum, and deliberately re-emerge the structures of their organisation. Re.vers.ify helps people and organisations shape the third Scrum wave.

 

Conversations with Vasco Duarte (available as daily Scrum Master podcasts)

I recently had some great conversations with Vasco Duarte about Scrum, Scrum Masters and Scrum Master challenges. In the week of 17-21 April 2017 they were broadcasted as daily Scrum Master podcasts.

Click the links below to listen to them again.

Vasco also recorded a bonus session, in which he invited me to share the ideas consolidated in “re-vers-ify”, or how re-imagining your Scrum can re-vers-ify your organisation. This bonus session has been broadcasted on 21 May 2017.

Find all Scrum Master Toolbox podcasts at http://scrum-master-toolbox.org or subscribe via iTunes.

Branching Done

I was recently contacted by a senior executive of a mid-sized company that is evolving their product development to Scrum. He explained a situation he had been in and wanted my opinion. He accepted me to share his story here (with some abstractions, and calling him Jim) in an open-ended way, inviting the reader -much like he did- to reflect on the purpose and accountability of the Scrum Master and how that role is needed for… well, many reasons still.

Jim’s company started out doing Scrum on some smaller, carefully contained projects with individual Scrum Teams developing clearly separated products and product areas. Through these projects they discovered how iterative-incremental product development increased transparency, and how disciplined engineering practices allowed them to excel. Where Scrum in the beginning was much seen as mainly for IT people, they soon found out the need for a mandated Product Owner representing the internal business and the user base to the teams. They felt that hiring a Scrum Master with three years of experience had been really helpful.

One of these early projects was recently expanded to two teams. Both teams work on the same product and draw work from one and the same Product Backlog. The Product Owner and the Scrum Master perform their roles for both teams.

Jim contacted me after he was invited to and attended the second Sprint Review after the expansion to two teams.

At this Sprint Review the two teams took 60 minutes each to walk everyone through the software functionality they had created. Each team showed the work from their separated code branch. By the end of the Sprint Review, Jim inquired about releasing the software, but got an unclear answer. In the end it boiled down to the teams promising they would have a look at it, and discuss it with the release department who hadn’t been involved so far.

Jim felt like not straining the teams more but an uneasy feeling had crept in. After all, one of the reasons why they started adopting Scrum were their long release cycles, and unclear release dates. It had led to many customer complaints and even losing a couple of important customers.

When he asked for my advice I told him only I was very interested to hear about the conversation I suggested he set up with the Scrum Master. He seemed a bit surprised when I started talking about the role of the Scrum Master.

How about you? If any, where would you situate the accountability of the Scrum Master in this?

A Mirror of the Scrum Master’s Work (so far)

Introducing “ScrumAnd”

Jigsaw Scrum

Adopting Scrum best starts by doing Scrum in the first place, getting all the formal elements of Scrum in place. It is like a jigsaw that isn’t complete until you have fitted all the pieces together. Luckily Scrum doesn’t have many pieces: 3 roles, 3 artifacts and 5 events. A simple set of rules can emerge complex behavior.

This ability to say “Yes, we do Scrum” however is only the start, not the end. Scrum is not the goal, Scrum is a mean to a goal. In order to increase the benefits, the way Scrum is used is to be maximized, thereby moving to “Yes, we do Scrum. And…“. There is a “ScrumAnd” for a myriad of elements. In the post Illustrations of ScrumAnd this was demonstrated through (1) the Product Owner role, (2) the ability to create releasable Increments and (3) the level of collaboration within a team.

Applying the “ScrumAnd” model on the role of the Scrum Master.

The Scrum Master facilitates Product Owners, Development Teams and the wider organization with services. The benefits gained through Scrum depend on the services provided by the Scrum Master. Or is it the other way around?

ScrumAnd (Scrum Master)

It is unfavorable, difficult and probably impossible to forcefully command people, teams and organizations into higher performance. In a “ScrumAnd” view on the Scrum Master role, there is less of a deliberate choice or strategy involved to increase benefits.

Teams though can be facilitated and wisely lead into benefits that will last. Yes, you do Scrum if you have a Scrum Master. And the level of services that the Scrum Master provides probably reflects the state of Scrum:

  • A Scrum Master teaches techniques for others to use; how to manage Product Backlog (syntax, sizing, splitting, grouping, descriptions, refining, dependencies), how to create visibility of progress (burndown charts, Scrum boards, cards, velocity, release plans), creating a definition of Done, how to plan and execute a Sprint, how to do a Sprint Retrospective meeting, the value of time-boxing.
  • A Scrum Master helps teams and their wider environment optimize the use of Scrum through Scrum’s foundation in empiricism; how Scrum implements transparency, inspection and adaptation, how Scrum helps when only the past is certain and the future is uncertain and highly unpredictable.
  • A Scrum Master shifts the focus from using Scrum to deliver on a set expectations (scope against time and budget) toward organizing work for creating the most valuable outcome; shifts focus from the process itself to the goal of the process.
  • A Scrum Master focuses on behavior, instead of ‘process’ and even outcomes. Accountability drives behavior, and behavior becomes grounded in the Scrum values, and Scrum is understood and applied through the values and principles expressed in the Manifesto for Agile Software Development.
  • A Scrum Master is present with a team, and within the organization; a silent, non-intrusive, mentoring, comforting, observing presence.

Scrum Masters are often expected to operate on the practices end, to be teaching techniques. Development Teams might want it because they have always been told what to do. Managers might want it because it is as close as they feel a Scrum Master can get to executing control in this new way of working. Scrum Masters themselves have the intrinsic desire to be invisibly present.

Whenever a service is needed, by the Scrum Master’s observation or by explicit request, a Scrum Master assesses the service level required depending on the requester, context, time. The happiest moment for a Scrum Master occurs when teams push back for being provided with too low level services.

The service that the Scrum Master is providing becomes a mirror for the Scrum Master’s work so far. Complexity equals instability, by default. Staffing changes (in the teams and in the organization), relationships change, strategies and objectives change, technologies change. A Scrum Master keeps going back and forth, up and down through the range of services possible. A Scrum Master cannot expect to steadily provide only one type of service.

Where are you, as a Scrum Master? What services are requested from you? Do you provide services that reflect the actual maturity of the team and the organization’s understanding and usage of Scrum?

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.