This is just to collect a few thoughts I had on June 28, 2013 to make them easier to find and refer to. This tweet started it: https://twitter.com/GeekTieGuy/statuses/350639064703176705

Here is what the next few tweets summarized:

Slack is to your organization as sleep is to your body: time to regenerate and be inspired by dreams and wake with new energy.

What happens when we deprive the body of sleep? We become manic, disoriented. We diminish our capability to be creative, we go insane.

What happens when we deprive the organization of slack? It becomes reactive, haphazard, brittle, overloaded, unable to think.

I recently led a session at Agile Open California with this same title. It was interesting to a few people, and I was sure I’d blogged my expanding tweets, but I apparently hadn’t. Fixed that now…

[2020-04-24 – I’m re-doing the math on this one, since my “30 days to a month” did not take into account that we don’t work on weekends… It ends up changing the conclusion downward from 7.5 to 7 hours.]

I was looking at the updated 2013 Scrum Guide, and because of some questions that have come up at work, I looked at how much time the guide suggests as the upper limit for various Scrum meetings.

The four larger meetings look like this in the scrum guide:

(Daily Scrum: 15 minutes per day; for completeness of this list)
Planning: 8 hours per month
Review: 4 hours per month
Retrospective: 3 hours per month
Refinement: no more than 10% of available capacity

That last one was a bit of a puzzler to me. How much would that be if expressed in hours, like the other meetings?

[Previous / old calculation:

If we call “a month” 30 days, and each day 8 hours, we end up with 240 hours per month. Translating to percent of time we arrive at:

Planning: 3.33%
Review: 1.67%
Retrospective: 1.25%
Refinement: no more than 10% of available capacity

]

[New calculation:
If we call “a month” 20 days, and each day 8 hours, we end up with 160 hours per month. Translating to percent of time we arrive at:

(Daily Scrum: 15 minutes per day = 5 hours per month =~ 3.125%)
Planning: 8 hours =~ 5%
Review: 4 hours =~ 2.5%
Retrospective: 3 hours =~ 1.875%
Refinement: no more than 10% of available capacity
]

Turn that back into hours on a two week sprint (80 hours) and you get:

(Daily Scrum: 2.5 hours)
Planning: 4 hours
Review: 2 hours
Retrospective: 1.5 hour

And the kicker (after subtracting the meetings above from 80 hours, leaving 70 hours):

Refinement: no more than 7 hours, assuming “ideal capacity”

This was a HUGE surprise to me. Actually a happy surprise! I’ve heard over and over from scrum teams I work with that clarity on what to build is the biggest problem they need to work on. So the good news is that the official Scrum Guide recognizes that it’s okay to spend up to 7 hours or so (in a two week “ideal” sprint) on refinement activities, which to me include improving clarity on what to build. I only wish it hadn’t been expressed in %-of-time.

Here’s a quick thought for (probably mostly Ha- and Ri-level) practitioners of Agile software development who are thinking about holding retrospectives on a fixed cadence versus going to an on-demand practice.

I like that the weekend comes around every five days. I’d sure feel uncomfortable if it didn’t. I enjoy the comfort of knowing that I’ll get some time with different things to do: play, learn, relax, create, sleep, connect with others. Every once in a while I’ll need a day off outside the weekend to take care of exceptional things. Other times I’ll need more than just a few days, so I’ll take a week or three for a change of scenery and recharge.

Is it so different for teams at work? Just a thought.

I’m not sure if this is an original idea, but I came up with (and used it) today. Normally I’ve had my questions written down in a notebook and gone through them one by one, trying to steer the conversation, which sometimes causes abrupt and somewhat awkward transitions. Today I did this instead:

Write down each question on its own index card. Some questions are fully formed, some just keywords.
Show all of the cards to the person I’m interviewing, saying “Here are the questions and topics I’d like us to talk about. Please play product owner for a minute and prioritize them in an order that works for you, and then we’ll start talking. If you want to ask me clarifying questions while you order, feel free to do so.”

I didn’t know how this was going to work out, so I started by asking “What do you think of this idea for our interview?” I got a really good response.

In order to not take up the whole time with the candidate talking about the cards, I stopped midway through and said “OK. How about your questions for me?” After that we came back to the remaining questions on the table, and finished with another short “Do you have more questions for me?” segment.

I think this was a pretty good way to be transparent about the interviewing process, a good way to let the candidate start forming a narrative and not getting blindsided, and giving the candidate a breath of fresh air from the traditional interviewing format.

These were the questions on my cards:

Agile Journey
Organizational Change
Scaling Agile
Outline a retrospective. How do you keep it fresh?
What is your Agile superpower? [I shared what I consider mine as an example when we got here]
Frameworks you’re not familiar with
Reading. Who influences you? Who do you influence?
Agile method/framework you’re familiar with

As we went along, I sprinkled in more questions, of course, but this was my skeleton.

What do you think? Novel? Useful? Boring? Comments would be much appreciated!

My oldest daughter recently introduced me to Gordon Ramsay’s Fox TV show “Kitchen Nightmares”. It was the episode on Amy’s Baking Company, and we sat and watched it together on YouTube. I couldn’t believe what I was seeing! The participants in the show engaged in almost nonstop verbal abuse, miscommunication, denial and dysfunction. It was like watching the proverbial train wreck in slow motion. I watched that episode three times. To use Gordon Ramsay’s favorite word: “Wow!”.

GordonRamsay

After a week or so of not thinking about it further, I started wondering if Ramsay ever visits a restaurant where the food is not horrid. I found that Hulu offers the show for watching on demand, and I watched two handfuls, or so, of shows. Apart from the entertainment value (the Anna Karenina principle), I started becoming interested in Gordon Ramsay’s approach for helping his show participants. Like others who have written about this, I’ve noticed some patterns and principles. Here’s my take on the show, viewed from an Agile coaching perspective:

Listen and gather information

Ramsay’s first step is to gather information. He meets the people involved in running the restaurant, talking to owners and staff to find out what they think is causing the restaurant’s problems. Most of the time he talks to everyone in private to make sure he hears unfiltered and uninhibited views.

 

Go see

As a second step Chef Ramsay focuses on tasting the food, usually at lunchtime. He also takes a look at the dining area’s décor, the number and kinds of items on the menu, cleanliness, POS systems, etc. This starts filling in more of the picture that he needs to start helping. Finally, he’ll observe how the kitchen functions during the busiest time of day, the dinner service. Usually this is also where he takes a look at the ingredients used, their freshness, the kitchen equipment, the cleanliness of the environment, how the people communicate and interact, and what the mood is like when things get busy and chaotic.

Hold up a mirror

It is usually during dinner service that Ramsay starts holding up a mirror for the owners and staff. His style is incredibly direct and, really, brutal. He doesn’t mince words. He doesn’t hold back. Profanities fly. He confronts people with ruthless injection of reality showing them how far away from excellent practices the restaurant is. This is usually close to the point where people reach “rock bottom”. They realize that they need to change, badly.

Ask for commitment

At this point Ramsay is still not convinced that he wants to help. He has a calmer conversation where he tries to gauge whether there is a willingness to commit to change. Usually his coachees end up expressing a commitment. Sometimes the expression is vague, but Ramsay picks up on it and is willing to go with it.

Inject energy

Chef Ramsay’s next step is usually to transform the restaurant physically. Some places haven’t had their interior refreshed in five to ten years. Ramsay injects new energy into both the environment and the people. He simplifies the menu and presents the actual dishes for test-tasting and to show the crew what is possible when you focus on quality and freshness. But it doesn’t stop there.

Teach and mentor

Next comes the preparation for the re-launch. This is usually where he teaches people. Sometimes it’s about the cooking and kitchen operations, sometimes about team organization, better communication, and getting owners to fully embrace the roles they need to play. Sometimes he’ll bring in other successful, experienced professionals to mentor and guide his protégés.

Stand with the team

All during the re-launch, Ramsay stays with the restaurant crew. He keeps holding up the mirror, providing observations and feedback, still brutally honest and direct. He also acknowledges when things work well, praising individuals for jobs well done.

Reflect and offer feedback

Finally, after the dinner re-launch is over, Chef Ramsay (as he is now universally called by the team) calls everyone together to briefly reflect on what happened and how. Due to his participation and in-the-moment steering, most re-launch nights are quite successful, possibly dotted with a few hiccups. Ramsay reminds the people who need change the most to make sure they don’t revert to old, more comfortable habits.

 

Agile approaches

If you look back over the subheadings above, you’ll see a lot of similarities between Gordon Ramsay’s coaching approach and Agile coaching approaches (as, for example in Lyssa Adkins’ book “Coaching Agile Teams”). Of course, as an Agile coach you wouldn’t want to use Ramsay’s brutal tone, volume and body language. The show wouldn’t have half the entertainment value without them, but outside of a TV show a calmer approach is more effective.

Apart from the above similarities, you’ll discover that Ramsay ultimately is all about what Christopher Avery calls the Responsibility Process. Ramsay manages to help people discover that they must overcome denial, blaming, justification, shame and obligation to ultimately take responsibility for the business they are running. They need to own setting the tone, making the rules, ensuring that they’re followed, setting quality and communication standards, etc. Of course, in an Agile context this becomes the job of the Agile team, not the manager, scrum master or any other single person. But just like in Kitchen Nightmares, sometimes teams need an Agile coach to help them with situations they’re grappling with and aren’t sure how to overcome. An Agile coach helps such teams help themselves with techniques very similar to the ones Gordon Ramsay models on his show.

I’ve been part of teams that practice Agile software development methods for quite a while now. My own team at work has been doing things in an agile manner since about 2008. Before that I was a co-founder of the Agile SIG (Special Interest Group) at work for several years, attempting to bring agile into the organization from the grassroots level. I’ve been trained for the role of Scrum Master by Ken Schwaber and Jeff McKenna. I started a group of retrospective facilitators at work as well, in the hopes of turning the organization I was part of into a more consciously learning organization. Before the job at my current company, I practiced eXtreme Programming in a startup. This is (I think) my first blog post exploring some aspect of Agile software development methods.

Over the years I’ve come to realize what it is about agile that makes it work. Agile is basically a mitigation strategy/technology that addresses the human tendency to fail at communicating effectively. Let’s look at this from the perspective of a model I learned about in high school from my language arts teacher – the basic human communication model. This model comes in various forms, but I like the one from my high school years. It’s one of the few things that have stuck with me from that time:

image

The Sender and Receiver in this case are people (although this model applies to pretty much any communication situation and is used in computer-communication model discussions as well). The Context on each side is complex. It’s made up of a person’s knowledge, cultural upbringing, state of mind, experience, financial situation, family circumstances, and many, many other factors. The Sender intends to convey a Message to the Receiver and the only way to do so is by Encoding the Message (in a way that the Sender hopes the Receiver will be able to Decode) and to pick a Channel for transmitting the Message. The Sender’s only way to verify if the Message reached the Receiver is by some Feedback mechanism, which actually just reverses the situation of the diagram. There are lots of ways that the communication can break down. For example, the Sender might pick an Encoding the Receiver isn’t able to Decode; the Channel might garble the Message so it becomes unrecognizable; or the Receiver might be in a Context that prevents the Message from being Decoded properly. Other communication breakdowns involve the Sender making unstated assumptions about the Receiver’s Context, the Sender picking a Channel that is inappropriate for carrying all the meaning necessary for Decoding the Message, or the Receiver not being receptive to the Message coming through the Channel.

When building software, the central thing we do is to turn ideas in our head into instructions for a computer to execute. If this were a solitary exercise, there wouldn’t be much of a problem: you have an idea; you think about how to translate it into something the computer can do, taking into consideration your skills, the computer environment, your choice of software technology stack, programming language, experience, etc., etc.; you sit down for a few hours, weeks or months to design, write code, test, deploy – and you’re done! In terms of human communication there is none, so the model doesn’t really come into play.

The trouble doesn’t start until you’re working on something that takes more than one person to accomplish in a reasonable amount of time. Unfortunately, most things undertaken in software these days are of this nature. This means several things. One, there will be human communication going on! Two, the kinds of communication will take many different forms and concern many different topics. And now we’re squarely in the domain of the communication model.

Just thinking of the number and kinds of things that will need to be communicated between people can make your head spin:

  • How many features will the software have?
  • What are the features?
  • How will we know that a feature is done?
  • What technologies will we choose to implement the software?
  • What computing systems will we support?
  • How will we construct the software so it is robust enough, yet easy to change in unforeseen ways?
  • What are the major parts of the software?
  • How will the parts communicate?
  • Will the user be able to understand it and use it as intended?
  • Will we be able to deliver the software on time?
  • What does on time mean?

And these are just some technical questions. There are others as well, more business related:

  • Will the software have value to customers and users?
  • Will the customer pay for it?
  • How much will the customer pay?
  • Will the customer be made mode productive by using the software?
  • How will we deliver the software to the customer?
  • How will we know if we’re building the right thing?
  • How will a customer be able to provide feedback on the software?

Pulling off almost any kind of software effort requires answers to these questions, and more. The nature of software development is one of producing ideas and mental constructs that can be turned into instructions for a computer to execute. If more than one person is involved in this activity, those ideas and mental constructs have to make their way from one person’s brain to another’s, so the people can collaborate to get the software built within some time limit. Agile software development methods bring to this process more formal opportunities for people to interact, increasing the likelihood of this communication happening  regularly and at varying levels of complexity, timescale and team composition.

Let’s take Scrum as an example. Scrum sets up a framework for communication and feedback like this (from high level/long timescale to low level/short timescale):

  • At the Sprint level (usually every 2 weeks these days, but Scrum originally used 30 days) –
    Sprint planning/review meetings and Sprint retrospectives. These provide opportunities for medium-term communication and feedback on the production of a usable increment of software functionality.
  • At the Backlog grooming level (usually at least once a week, but not specified by Scrum) –
    An opportunity for communication and feedback about user story details that concern upcoming sprints.
  • At the Daily Scrum level (every day at the same time) –
    What happened yesterday, what will happen today, what’s getting in the way? This is an opportunity to quickly gather feedback and communicate about nitty-gritty day-to-day details.

Scrum’s official rules (found in the Scrum Guide) were recently updated (in July and October of 2011) to allow for more freedom in selecting practices and experimenting with new things. So, as of the latest edition of the Scrum Guide, Release Planning is no longer part of the official Scrum rules. If it had been, I would have argued that Release Planning and the Release Retrospective provide the highest level of overall communication and feedback loop that Scrum puts in place. Since many people still use Release Planning as a tool, I think the point still holds.

Many people mix in good technical practices as well, which add things like:

  • Pair programming –
    Instant, real time communication and feedback on the construction of ideas and expression of those ideas in code.
  • Continuous integration –
    Feedback on code quality, feature readiness, etc. on a daily basis or more often.
  • User story estimation (part of Sprint planning) –
    Feedback and learning about what a software feature is supposed to do, how it will be implemented, what its acceptance criteria are, etc. Often summarized by a relative size called “story points” based on the Fibonacci series of numbers, which are useful because people are somewhat better at judging relative sizes than absolute sizes.

Human communication tends to break down in unexpected ways. Agile software methods give people plenty of opportunities to communicate and get feedback, helping to mitigate the breakdowns that occur in the complex context of team-based software development.