Scrum Master is a Marketing and Sales Role, Not a Managerial One

I recently saw this tweet:

and it spurred me to write this post. Note the word “forced” used multiple times here. This Scrum master likely believes they need to control and manage their team. However, I believe an effective Scrum master (or product manager) role is a marketing and sales role.

Even after shown to be false, the myth pervades that creative workers need to be managed and made to follow certain orders. It honestly surprises me  that we still need to write on this topic.

In order to explore this idea more deeply, let’s define what marketing and sales int the team space are:

  • Marketing – Making known to others that you have something potentially valuable.
  • Sales – Knowing what someone values and explaining how what you have is either valuable to them or not.

Note that this may not seem like a typical definition of sales. Sales gets a bad rap from all those used cars salesmen tropes and the like. Ethical sales requires very little convincing, instead requiring a deep understanding of what your potential users value.  Ethically selling sometimes leads us to choose against selling to a user, a negative sell. We must be alright with this happening.

Let’s look at the exciting world of Scrum mastering to the development team from the site, scrum.org:

  • Coaching the Development Team in self-organization and cross-functionality.
  • Helping the Development Team to create high-value products.
  • Removing impediments to the Development Team’s progress.
  • Facilitating Scrum events as requested or needed.
  • Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

I see coaching in here twice. Coaching is often focused around introducing new patterns and solutions to the team that may solve their current problems. This falls in line with our definition of marketing. One key to successful coaches is that they can explain how a potential solution is valuable to the team members at their level of competence. That matches our definition of sales.

Helping the Development Team to create high-value products is so generic that we could shoehorn in how marketing and sales fits into this, but I don’t believe it is valuable.

There are other things listed above that the scrum master should do, that do not fit the marketing/sales mode. That is alright, a Scrum master or product manager is not only a marketing and sales role, but it is much more so these things than a managerial role. The only thing that could possibly be seen as managerial is facilitation of Scrum events, but that would be a warped definition of facilitation. I find the best facilitation is one where the facilitator is as objective as possible, not displaying opinions or taking sides in discussions during these events.

To force the team is to lose their trust and a loss in trust loses performance. If you put on a marketing and sales hat during many of your activities as a Scrum master or product manager, you will see significant gains in team ownership and performance. As we described above, marketing and sales can allow us to be fully authentic, honest and transparent. We need not apply them as they are traditionally viewed.

 

A Newborn Baby as a Finite State Machine, Part 3

In the previous post we created a grid of states, triggers, and transitions. This is a great format to transcribe to a computer, such as your automated test suite. However, it is not easy for humans to reason about or to onboard someone on how a newborn baby works. Fortunately we can easily translate this into a Finite State Machine diagram using a tool like Draw.io.

As you can see, even with our simplifications a newborn baby is quite a complex state machine. I would imagine, if using TDD in isolation, we are all but guaranteed to miss some transitions. But despite the complexity we are able to easily account for all scenarios through this exercise. As a bonus we can also manually trace through any flow with this diagram, allowing us to perform sanity checks.

Another potential benefit beyond performing TDD in isolation is that we don’t need an overabundance of integration or end to end tests for the different flows, or series of transitions. Using a structured approach of triggers, transitions, and states mathematically guarantees that any combination of flows can work, assuming each transition has been unit tested.

One thing we did not cover was side effects. For example the baby may smile when you touch her but it does not affect her overall state. Side effects are useful to annotate and know about but are not necessary to effectively model the program.

I hope this demonstrates how we can tackle complex programs by modeling them as finite state machines.

A Newborn Baby as a Finite State Machine, Part 2

In the previous post I introduced why modeling software as a Finite State Machine can be useful and used a newborn baby as an example. This post will fill in the transitions for the baby.

I realize I missed two key triggers, hopefully this does not reflect on my real-life parenting ability. Feeding the baby and changing the diaper should have an impact on the state of a newborn, so let’s include those. That gives us the following grid of states and triggers:

Quiet Alert Active Alert Crying Drowsiness Quiet Sleep Active Sleep
Hunger
Dirty Diaper
Lack of comfort
30 min interval
Sudden light/noise
Physical Touch
Feed
Change Diaper

Let’s fill in more of the obvious transitions:

Quiet Alert Active Alert Crying Drowsiness Quiet Sleep Active Sleep
Hunger Crying Crying Crying Crying Crying Crying
Dirty Diaper Crying Crying Crying Crying Crying Crying
Lack of comfort Crying Crying Crying Crying Crying Crying
Time passes Active Alert Drowsiness Drowsiness if was asleep, Quiet Sleep; else Active Alert Drowsiness Quiet Sleep
Sudden light/noise
Physical Touch
Feed
Change Diaper

For simplicity’s sake let’s assume that a baby will always immediately cry when an unhappy event occurs. This is a human being and we cannot expect a program to fully represent the nuances of even a newborn, so this is good enough for now. It is common to need to simplify things for the sake of understanding the program, in any case. It is valuable to simplify the unimportant details for the sake of the important ones.

Next let’s look at what happens as time passes:

Quiet Alert Active Alert Crying Drowsiness Quiet Sleep Active Sleep
Hunger Crying Crying Crying Crying Crying Crying
Dirty Diaper Crying Crying Crying Crying Crying Crying
Lack of comfort Crying Crying Crying Crying Crying Crying
Time passes Active Alert Drowsiness Drowsiness if was asleep, Quiet Alert
else Quiet Sleep
Active Sleep Quiet Sleep
Sudden light/noise
Physical Touch
Feed
Change Diaper

We are saying that a baby will start quiet, become quite active, and then tire herself out into drowsiness until falling asleep, again a simplification. The final simplification we have here is that a baby will get tired if she cries enough without any intervention (not recommended in real life). Note that we put our first conditional transition, when the baby is Drowsy. The baby can be drowsy waking up or falling asleep so we need to know in which “direction” the baby is going to make a decision. Too many conditional transitions can indicate that we need to refactor our States to be clearer. In this case we are fine for now.

Next, let’s cover what I would categorize as the “crying solving” triggers. Most parents are familiar with this checklist of things to check when a baby is crying:

Quiet Alert Active Alert Crying Drowsiness Quiet Sleep Active Sleep
Hunger Crying Crying Crying Crying Crying Crying
Dirty Diaper Crying Crying Crying Crying Crying Crying
Lack of comfort Crying Crying Crying Crying Crying Crying
Time passes Active Alert Drowsiness Drowsiness if was asleep, Quiet Alert
else Quiet Sleep
Active Sleep Quiet Sleep
Sudden light/noise
Physical Touch Quiet Alert Active Alert if discomfort, Quiet Alert
else Crying
Drowsiness Quiet Sleep Active Sleep
Feed Quiet Alert Active Alert if hungry, Quiet Alert
else Crying
Drowsiness Drowsiness Drowsiness
Change Diaper Quiet Alert Active Alert if dirty diaper, Quiet Alert
else Crying
Drowsiness Drowsiness Drowsiness

We added more conditional transitions as the baby could be crying for different reasons. Note that physical touch does not normally wake the baby, but feeding and changing does. We may not have known this when we first took her home, but after being around her we now know how she will respond. This goes back to ensuring you gain the domain knowledge to answer these questions. If you don’t know up front, that is fine. The willingness and ability to find answers or to make assumptions and move on is one thing that separates efficiencers from average software developers.

Finally let’s fill in that last trigger:

Quiet Alert Active Alert Crying Drowsiness Quiet Sleep Active Sleep
Hunger Crying Crying Crying Crying Crying Crying
Dirty Diaper Crying Crying Crying Crying Crying Crying
Lack of comfort Crying Crying Crying Crying Crying Crying
Time passes Active Alert Drowsiness Drowsiness if was asleep, Quiet Alert
else Quiet Sleep
Active Sleep Quiet Sleep
Sudden light/noise Active Alert Active Alert Crying Active Alert Drowsiness Drowsiness
Physical Touch Quiet Alert Active Alert if discomfort, Quiet Alert
else Crying
Drowsiness Quiet Sleep Active Sleep
Feed Quiet Alert Active Alert if hungry, Quiet Alert
else Crying
Drowsiness Drowsiness Drowsiness
Change Diaper Quiet Alert Active Alert if dirty diaper, Quiet Alert
else Crying
Drowsiness Drowsiness Drowsiness

We can see from observing the baby for a while that any sudden noise or light will “jump start” the baby into an active alert state in most cases, unless she is crying or asleep.

This is a great format to transcribe to a computer, such as your automated test suite. However, it is not easy for humans to reason about or to onboard someone how a newborn baby works. In the next post we will see the resulting diagram that we can use to help us and our coworkers reason about newborns.

A Newborn Baby as a Finite State Machine, Part 1

TDD is great but sometimes I need an extra oomph into my design to help model a non-trivial problem. I find that modeling things as finite state machines help me to achieve this.

A finite state machine is a system where a set of inputs, called triggers, can cause the system to transition from one state of being to another state of being.

Why is this a useful way to model behavior?

  • It constrains me to think in terms of a limited set of abstractions: triggers, states, transitions and side effects.
  • It exposes edge cases I  may not have thought of through pure TDD.
  • It frees from me from thinking about things as sequential series of events, which other models such as Flowcharts can sometimes trap us into doing.

Before I model the state machine I ensure I understand the domain well enough to know the potential states and triggers. A state can be one value (like an enum) or a combination of values. A trigger can be any event, user action, or time passing. Here are the steps I usually take:

  1. I start by making a grid out of these states and triggers, then filling in the transitions (destination State) and any side effects.
  2. Then I diagram the state machine visually using Draw.io or similar tool so that my pair partner or other devs can easily understand the solution being developed. I try not to underestimate the cost of knowledge transfer on a team.
  3. Finally, I test-drive out the functionality in the code itself. Even though I modeled the scenarios ahead of time, this let’s me flesh out those nitty-gritty details, like what the triggers look like, the surface area of the state machine, how it needs to fit into the codebase, etc.

Let’s take an example. I just had a beautiful baby girl, so let’s use a newborn baby as a state machine. A book I am reading, The New Father, says that there are 6 states to a newborn baby: Quiet Alert, Active Alert, Crying, Drowsiness, Quiet Sleep, Active Sleep.

Transitions are a bit trickier and require us to infer a bit, as it will be with most problems we are solving for a customer. Crying is a (well known) state and all parents likely know that babies cry due to a few things: they are hungry, they have a dirty diaper, and they need comfort. The latter covers  range of comfort needs, like temperature change and parental affection but I lumped them together for simplicity. From the book we know that Quiet Sleep and Active Sleep switch every 30 minutes so time passing is another trigger. Other triggers may include sudden light or noise and physical contact. Also note that transitions can be both conditional (only happens some of the time based on trigger context) and unconditional (will always happen when the trigger occurs).

So now we have a grid we can setup:

Quiet Alert Active Alert Crying Drowsiness Quiet Sleep Active Sleep
Hunger
Dirty Diaper
Lack of comfort
30 min interval
Sudden light/noise
Physical Touch

In the next post in the series we will fill in the transitions and diagram the machine.