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?

Illustrations of ScrumAnd

Although Scrum has an acknowledged body of knowledge, the Scrum Guide, it is -by design- incomplete. Scrum is a framework, not a methodology. With Scrum, an empirical foundation is created from which the details and specifics of the actual working processes emerge. And while the actual working processes keep evolving, the foundation of Scrum provides stability.

Scrum needs the continuous selection, application and revision of good practices, strategies and tactics to be really effective. The rules in themselves provide foundational guidance. The effective benefits an organization gets from Scrum largely depend on how the game is played. Ultimately the benefits gained from Scrum will vary with the implementation, usage and application of Scrum; from roles, rules, players, and principles to techniques, practices, strategies and tactics.

Doing Scrum, and doing it properly, is only the beginning. Yes, you do Scrum if you have the formal elements in place. And from that much more beauty comes within reach. We refer to this idea as ScrumAnd.

Yes, We Do Scrum. And

There is a ScrumAnd for a myriad of elements included in or attached to the use of the Scrum framework. I will illustrate the ScrumAnd potential to augment the fun, energy, and benefits from Scrum upon 3 elements only:

1. The Product Owner role

Yes, you do Scrum if you have a Product Owner. And you will do even better depending on how the role is fulfilled:

Yes, We Have A Product Owner. And

Scrum is at first often implemented as the new IT-process, or is started within the IT-departments exclusively. So, a business analyst is put in the role. In organizations suffering from the traditional Business-IT dichotomy, it is often much later that business comes into play; forcing themselves in or being invited to do so.

  • A (business) Analyst in the role has limited benefits. But development organizations feel like securing control over the process with an analyst as Product Owner; just because it is an IT-person (‘Can’t trust business people!’). However, for many decisions the analyst doesn’t have the answer, needs to revert to product management, look at the project manager, wait for an external decision, get an upfront approval from a steering committee. Every time the Development Team is halted, must wait, pick up other work, restart previous work, park work for a longer time. No flow, no value.
  • A proxy for the business, like an account manager or other gap bridging alternatives, is slightly better. Control remains with IT (‘Still can’t trust business people!’) but IT puts a person in the role who is closer to the business, who is more connected to the business. It creates less delays, less waiting time, less hick-ups; although many of those remain.
  • Often the business gets a smell of the role and sees the fun and advantage of it, or the organization just opens up to broader collaboration. A person is sent in from a business or product management department to fulfill the role. It is another improvement. There is more direct availability of functional knowledge and stakeholder expectations. Yet, still much waiting time for decisions by the real authorities, as the business representative often has limited autonomy in his representation of product management aspects to the development organization.
  • It works better if the person is not only from business, but also has the trust and the mandate to take decisions (on the spot). A mandate is a signal that the role is taken more seriously. Often the person in the role is allowed to spend more time on it. Less hick-ups, less context and task switching, largely improved flow. The Development Team can focus more, and get things done.
  • It is great if the Product Owner is a mini-CEO over the product, a real owner of the product (what’s in a role’s name, right?), a business person with full (functional and budgetary) responsibility over the product and knowledge over all product management aspects (marketing, competition, users, legal, finance). The person’s professional life is dedicated to the well-being of the product. They don’t come much better than this.

2. Releasable software

Yes, you do Scrum if you have a definition of Done. And you will do even better when it reflects ‘releasable’ and all work for it can be done within a Sprint (not post-Sprint):

Yes, We Have A Definition Of Done. And

Scrum has no exact prescriptions for software development practices. However, the empiricism of Scrum thrives on transparency. A part of transparency lies in common standards and agreements, to drive inspection and adaptation. Engineering standards are a crucial part of that. Engineering standards guide the definition of Done, give focus to a team in getting stuff done, help a team in forecasting Product Backlog for a Sprint, define quality, create accountability.

  • Development (here as synonymous to ‘programming’) is quite essential in the wonderful world of software development. Without it, no result, right? And although the importance of it is often even underrated (think of the separation of design from development in separate, upfront phases), programming in itself is hardly enough. Although code aspects like clear code, self-explanatory code, naming conventions, refactoring are very important, it is only the start. But for sure, without development (‘coding’), no progress as there can’t be any working software, the primary measure of progress.
  • Code requires testing. And if all testing is to be done within a Sprint, testing skills are required in the Development Team and testing becomes part of the development activities. Testing is minimally needed at a technical unit and at a functional level. It gets even better if this part of development can be done first, can be automated as much as possible and is performed progressively within the Sprint, not just toward the end of the Sprint.
  • The releasability of an Increment, produced by the end of a Sprint, takes a giant leap if all integration, regression testing and alike work is done within the Sprint, and within the Sprint across multiple teams working on the same product or dependent products. It does help additionally if also this work can be automated and is done progressively in the Sprint, not just toward the end of the Sprint.
  • Teams can do better if they not only have the skills, access and mandate to perform QA work in the Sprint, but are also facilitated by organizational guidelines for quality, designs and architecture. No rework arising from QA on earlier Increments disrupts a current Sprint, or must be added to the Product Backlog. It does help additionally if any QA work can be automated and is done progressively in the Sprint, if quality is built in into the product and not just verified toward the end of the Sprint.
  • Even when doing Scrum, many organizations foresee additional stabilization time to prepare an Increment or a set of Increments for an actual release. Imagine the gain if this work can be done within the Sprint. Every 2-3 weeks a truly potentially shippable Increment of software is available, that can be brought to the market without additional costs or work. A good time to start thinking about continuous delivery.

3. A Collaborative Team

Yes, you do Scrum if you have a Scrum Team with a Development Team, a Product Owner, and a Scrum Master. And you will do even better when the team can improve its relationships and collaboration, often by remaining stable:

Yes, We Are A Team. And

Self-organized team work is the corner stone of Scrum. Teams however cannot be built or constructed like a mechanical object. With support, cherishing and nurturing, a collaborative team might gradually emerge.

  • A team gets formed by bringing a group of people together, preferably -but not always- in a shared workspace. Most of them are in observing mode, are keeping some distance. Formal arrangements and agreements get made, possibly including team agreements, engineering standards, a definition of Done, team values, meeting timings. And the team formally starts following them. Gradually people start expressing deeper thoughts, ideas and concerns.
  • A team goes through some storming as the team members get to know each other better and start expressing options and ideas that don’t match exactly. They sort the differences out. At first they might take it personally only to find out later that they are not used to the others’ gestures, tone of voice and facial expressions. They find out and they build a sense of trust.
  • The group of people jells better and better. The whole becomes equal to the sum of the parts. They become co-operative, they better align their individual work with the work of the others. They adjust their individual expectations to their team peers. They find a productive way to deal with conflicting ideas.
  • The team is really starting to know each other, even share more personal backgrounds. They have grown confidence in understanding each others’ remarks, stop taking comments personally. They stop looking for blame and stop covering up. A solution becomes the goal. As there is trust, and openness and honesty arising from it, they develop shared goals and are committed to these shared goals and objectives. Individual benefits are being sacrificed for the good of the whole.
  • The team has become a smooth, collaborative unit. Everyone’s focus is on the whole. The team members have passionate debates, engage on opposing ideas, look for the best possible outcomes and get their satisfaction from being part of the group. What used to take them hours and hours to sort out now only takes them a smile and a wink.

Organizations tend to overlook the scaling potential in the way Scrum is being played. Take advantage of these options first, enjoy the cumulative effect of multiple ScrumAnds and avoid the additional complexity that arises from volume-oriented scaling like adding people, adding teams, adding roles, adding phases.