Re-vers-ify (re-imagine your Scrum to re-vers-ify your organization)

Agility is why organizations adopt Scrum.

Organizations suffer as they fail to act with agility through product releases, on the market, for users and consumers, facing competitors. Scrum is mandated and it is overlooked that the agility demonstrated outwardly also depends on the setup of internal structures.

Organisational rigidity is the result when people are separated in functional silos, when collaboration is instructed through hand-overs and governance, when go-see management is not practiced, when the daily work has no room for discontinuous innovation. Basically, such rigidity is the anti-thesis of Agile and impedes outward agility.

Scrum is a simple framework for complex product delivery. Scrum thrives on the self-organizing capabilities of collaboractive people creating finished versions of product in short cycles, called Sprints. Scrum is in itself agnostic of internal structures, positions, titles, hierarchies. Scrum has no mandatory rules for organisational constructs. Scrum is simple, not easy. The simple rules and roles of Scrum are most often twisted and broken to fit an existing organization. Yet, it is nearly impossible to benefit really from adopting Scrum without updating the internal operating systems.

The sensible and courageous way forward is to re-vers-ify, to re-imagine your Scrum to re-emerge your organization. It is a path, not the destination. The destination, an updated organization, is unknown, remains to be discovered.

  • Use Product Backlog as the single plan for one (1) meaningful initiative (project/product/service). Slice the initiative if it is too big.
  • Reset the accountabilities for the selected initiative to Product Owner, Scrum Master and Development Team(s).
  • Facilitate the eco-system with tools, infrastructure and a (Scrum) team zone in order for them to create sashimi releases. A controlled and automated deployment pipeline is certainly a much needed step forward.
  • Repeat, grow, learn, expand.

“Re-vers-ify” is a narrative to help people re-invent their organizations; an invitation for people to re-imagine their Scrum to re-vers-ify their organization. Over the course of 2017 I have introduced re-vers-ify in several ways. I have now highlighted the essence in a short movie. It takes only slightly over 3 minutes of your time. Enjoy!

If you have more time to spend, consider reading my book “Scrum – A Pocket Guide (A smart travel companion)“. It ends with following belief:

Scrum Master, the modern manager

A Scrum Master is rarely seen, let alone enacted, as a management role. The role however does show us how a modern manager would act.

Scrum Master, as a modern manager, fosters an environment of safety. An environment of safety is an environment in which people, from a traditional point of view, act in a highly unsafe way; speaking up, challenging, sharing, thinking, pausing, collaborating, deviating, creating, innovating.

In the past I have already published my views on how Scrum Master is a manager. I have now highlighted the essence of the Scrum Master role in a short movie. It takes less than 3 minutes of your time. Enjoy!

If you have more time to spend, consider reading my book “Scrum – A Pocket Guide (A smart travel companion)“.

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 actually applies to any method but only Scrum makes it an explicit tenet. Use Scrum as a foundation, and apply the ScrumAnd thinking to address your specific problems and situation.

Happy Scrum Year (2014)