Help!!! My Sprint Review is Out of Control!

A past co-worker reach out distressed about their Sprint Review meetings running amuck. Too many participants, topics, and tangents dropped the value of the meeting down to zero. Clearly, the Scrum Master must get the meeting refocused, but what’s the best way to do that?

National Library of Ireland - Flickr

National Library of Ireland – Flickr

This team operates in a plan, build, and run model. In other words, there are people responsible for planning, people responsible for development, and people responsible for support. A problem with this model is the cost of transitioning work between the 3 teams.

In an attempt to lower the cost of the handoff, the build team (scrum team) decided to incorporate the transfer to the support team (run) during their Sprint Review meeting.

Not surprisingly, the participants in the Sprint Review meeting increased and the build team now struggles to complete the support transition in the 4 hour time box (4 week Sprints), let alone the actual activities that are supposed to be completed during a Sprint Review meeting.

From the Scrum Guide:

During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value. This is an informal meeting, not a status meeting, and the presentation of the Increment is intended to elicit feedback and foster collaboration.

This means that the build team is not properly reviewing the current increment of software. They are not adjusting the product backlog to optimize the potential value of the next Sprint. And they are not collaborating with the product owner to get aligned for the next Sprint Planning session.

To solve this problem, the build team should add transitioning support of the new feature/story/bug fix to their Definition of Done. There are 3 clear benefits to moving the cost of this activity from the Sprint Review Meeting to the overall Sprint.

  1. Impact of the requirement will show in the team’s velocity. The build team should estimate their work knowing that transitioning the feature to the support team is part of the effort. This ensure that the cost of the process is known and can be discussed in real terms.
  2. Impact of the requirement will show in the value delivered. Similar to the value benefit, knowing the impact to amount of value a team can deliver in a sprint is another metric that can help guide better decision making and operational practices.
  3. The value of the requirement can be discussed in terms of impact to the organization. Having metrics replaces emotional conversations. Rather than argue that a transition meeting has zero value, the team can discuss the merits of the system in terms of value.

Perhaps most important of all is that the build team gets their Sprint Review meeting back. This meeting is critical for getting the team ready for the next Sprint and to ensure that product backlog is optimized and ready to be used in the next Sprint Planning meeting.

[QUESTION] Why Do Scrum Teams Call Agile Iterations “Sprints”?

The Scrum Guide tells us what a “sprint” is and gives best practices around duration and timing, but it says nothing about why scrum teams call iterations “sprints” in the first place.

phgaillard2001 | le depart | flickr

phgaillard2001 | le depart | flickr

This question actually came from a podcast that I listen to called This Agile Life.

John Sextro, Craig Buchek, Amos King, Jason Tice, and Lee McCauley publish this weekly podcast about life as agile coaches and developers.

On This Agile Life episode #64, the topic was Giles Bowkett’s blog post – How Scrum Should Just Basically Die in a Fire. I recently blogged about this same post, but did not comment on Mr. Bowkett’s disagreement with Scrum calling agile iterations “sprints”:

Scrum’s an agile development methodology, and one of its major goals is sustainable development. However, it works by time-boxing efforts into iterations of a week or two in length, and refers to these iterations as “sprints.” Time-boxed iterations are very useful, but there’s a fundamental cognitive dissonance between “sprints” and “sustainable development,” because there is no such thing as a sustainable sprint.

The This Agile Life crew zeroed in on this criticism and mused about asking Jeff Sutherland why he decided to call scrum iterations “sprints”. Fortunately, Mr. Sutherland has a new book out called Scrum: The Art of Doing Twice the Work in Half the Time AND he answered this question:

And so my team embarked on what we called “sprints”. We called them that because the name evoked a quality of intensity. We were going to work all out for a short period of time and stop to see where we were.

With the origin story in mind, the “sprint” label makes sense for scrum teams:

  1. The goal is intensity:  Scrum teams are laser focused on a sprint goal and work diligently on their sprint backlog items to turn their stories in to working software.
  2. Scrum teams take time to catch their breath: At the end of each sprint is a sprint review meeting. During the sprint review meeting, scrum teams stop to examine the sprint activities, the latest increment of software the team delivered, and the product backlog. The scrum team also conducts a sprint retrospective to examine how the team got to where they are and how they can do things better during the next sprint.
  3. Sprints are short for a reason: Mr. Bowkett is correct when he says that there is no such thing as a sustainable sprint. But short (2-4 week) sprints with time taken to inspect and adapt the work IS sustainable. Not stopping at the end of the time box jeopardizes sustainable pace as does going past the 1 month maximum sprint length.

Inspecting scrum is a great way to become a better agile practitioner. Podcasts like This Agile Life and blogs like Mr. Bowkett’s are great places to help you think about scrum and deepen your understanding about the practices that you use every day. It’s a tip that I’ve given in the past, but I cannot stress it enough as a great way to improve.

In this case, we learned that the label “sprint” is meant to give teams a sense of urgency, but with the intention of taking rest after the intense work it takes to turn sprint backlog items in to increments of software.

Question: What do you think about the term “sprint”? Does it express the right intention, or is it time to go back to “iterations”? You can leave a comment by clicking here.

Bad Agile Management Burns Scrum Teams

Last month Giles Bowkett wrote a scathing blog post about scrum called: Why Scrum Should Basically Just Die in a Fire. It’s a provocative article that shows how damaging bad agile and scrum can be to a team.

Ms. Glaze | Flame | Flickr

Ms. Glaze | Flame | Flickr

I’m not going to go point by point and argue with Mr. Bowkett about his experiences with scrum. They are his experiences, and they are truly awful. I have sympathy for him and those who have been burned by a botched agile transformation.

With waterfall, teams know what they are signing up for at the start of a project. They know there will be problems and that a death march is likely. They also know that the date set at the beginning of the project is likely wrong, but still they soldier on.

But with agile and scrum it’s supposed to be different. The agile manifesto is a developer play aimed at making the lives of engineers better. Scrum specifically puts the team in control of how they accomplish their work. Everything should be great.

But often, it isn’t.

Mr. Bowkett makes this point by calling out many common scrum anti-patterns that he has experienced:

These are all valid – and unfortunately common – problems on scrum teams. However, the conclusion that he draws from the existence of these problems misses the mark.

In other words, in its best-case scenario, Scrum’s a dog-and-pony show. But that best-case scenario is rare. In the much more common case, Scrum covers up the inability to recruit (or even recognize) engineering talent, which is currently one of the most valuable things in the world, with a process for managing engineers as if they were cogs in a machine, all of equal value.

Rather than cover up individual inabilities, scrum exposes the bad practices of organizations. Quickly. Work becomes transparent, impediments become obvious, and old practices become extra painful.

The culprit here are manager who thought they were getting hyper-productivity for free. They want the benefits of scrum, without having to change.

Mr. Bowkett’s problem is with lousy managers, not scrum.

The agile community is also partially to blame. The tendency is to focus coaching and training on the scrum team. But it is the management team members that we need to be working on the most. Bad scrum cannot take root in an organization that embraces the scrum values from the top down.

Part of embracing the scrum values is accepting the twelve principles of agile from the agile manifesto, which Mr. Bowkett also railed against.

I don’t think highly of Scrum, but the problem here goes deeper. The Agile Manifesto is flawed too. Consider this core principle of Agile development: “business people and developers must work together.” Why are we supposed to think developers are not business people?

We’re not. The intent of this agile principle is the end the “us vs them” mentality between IT and “the business”. With Scrum, the expectation is that the product owner is co-located with the development team and available to answer questions about the product backlog items.

This isn’t a slight against the business acumen of developers. It’s a call for close collaboration between stakeholders and engineers. How else can the development team know if they are working on the most valuable features for the business?

Question: Have you been a part of a poor agile transformation? What went wrong? How could things have gone better? You can leave a comment by clicking here.

Agile Coach Camp 2014 Was A Huge Success

During the closing circle of Agile Coach Camp 2014 our facilitator – Deb Hartmann Preuss – asked us: Which word described our experiences during the conference? The word that immediately came to mind was “humbling”.

CS | Share | Flickr.com

CS | Share | Flickr.com

Agile Coach Camp is an open space event. It’s an “unconference” where agile coaches network and develop relationships while inventing ideas, concepts and practices. The attendees come up with high-level topics and create their own conference agenda – better known as the marketplace.

They then gather around the topics that interest them and collaborate, plan, discuss, and dig deeper as a group to develop new “things”. You can fine more information about the open space concept here.

One of the interesting parts about this format is that the presenter is actually a facilitator. They are responsible for proposing a problem or an idea, but after that the session turns in to a dynamic group discussion.

At this year’s Agile Coach Camp, some of the biggest names in the industry showed up. People like Diana Larsen, Esther Derby, Don Gray, George Dinwiddie, and Tim Ottinger facilitated and presented alongside the other 90 participants.

While it was humbling, it was also amazing. Getting to exchange ideas with some of the best coaches in the industry was tremendous fun. That kind of interaction is simply not possible at the larger conferences. It is a level of sharing that I’ve never seen in a community.

In fact, many of the topics we discussed would not have made it in to the agenda of a traditional conference. Those events are filled with talks on metrics, agile tools, and scaling scrum.

At Agile Coach Camp, the focus is squarely on individuals and interactions and not process and tools.

To give you an idea of this, here are some of the sessions that I attended:

  1. Agile Game Mechanics (@paul_boos): A discussion on how traditional game mechanics – random event decks, dice rolling, character creation, quest mechanics, and action points – can be used to develop agile games and simulations.
  2. Conjoint Coaching (@gdinwiddie): Coaching teams as a whole and how to model behavior. Also a great discussion on observing teams and feedback loops to get to the core of what drives the way people interact on an agile team.
  3. Thinking for a Living (@tottinge): The challenges of breaking away from the factory mindset in an age where your job is to think, not assemble. We looked at how the brain works, how naps make people more productive, and even the best time to have a parole hearing (ego depletion example).
  4. BA’s Role on an Agile Team (@agilesquirrel): Where does a BA fit on an agile team? Should they be a scrum master or a product owner? Is “business analyst” a valid agile role? These questions and how to avoid a squirrel attack were covered in detail.
  5. Agile Coaching is Dead (@howardsublett): An incredibly honest discussion about whether or not agile coaching is a bubble ready to burst. We also dove in to the role that certification bodies play in the impending demise of the agile coach, along with what agile coaches can do to change direction and bring value to their customers.

The outcomes of these talks led to what many of us called “ideas too big to tweet”. The conversations were rich and we all walked away with new ideas and more importantly new friends.

This is now my favorite “unconference” that I will keep on my schedule for years to come. Next year Agile Coach Camp is in DC. I hope to see you there.

To read more about Agile Coach Camp 2014 and  the sessions you can visit the event log site here.

Question: Have you attended a conference that changed the way you look your work? Your life? Please share in the comments below. You can leave a comment by clicking here.

Scrum Master is a Title, Servant Leadership is a Mindset

If a person believes that carrots and sticks lead to productivity, no 2-day class and a certificate on the wall can change that. But those who seek to empower people and teams can become great scrum masters and servant leaders.

Unknown | Team | Flickr

Unknown | Team | Flickr

In the comments section of my post “Help! The Scrum Master is the Impediment”, Darko asked that I cover servant leadership. Darko seems to also have experience with a scrum master who does not behave well and asked some great questions about the role:

  1. What is a servant leader?
  2. How does a scrum master serve their team as opposed to directing it?
  3. Where in practice does the scrum master meet their servant role – can you give concrete examples?

What is a servant leader?

The term servant leader came about in an essay by Robert Greenleaf title “The Servant as Leader”. In his essay, Greenleaf described a servant leader as “one who makes sure that other people’s highest priority needs are being served.

He offered these question as a litmus test to servant leadership:  “Do those served grow as persons? Do they while being served, become healthier, wiser, freer, more autonomous, more likely themselves to become servants?

How does a scrum master serve their team as opposed to directing it?

The change in mindset necessary to become a servant leader is incredibly hard for a scrum master who comes from command and control background. There are a few changes in thinking that can help with this transition:

  • Favor self-organization:  Don’t make decisions for the team or assign their work, ask them how they will tackle the next sprint goal. And trust them to follow through.
  • Enable self-management:   Scrum teams self-manage their work and their practices. Rather than dictate how the team will deliver value back to their business partners, work to remove the organizational barriers to their success.
  • Let teams fail:  This is more difficult than it seems. Allowing a team to “fail” and learn important lesson that will pay off down the road is difficult. But sometimes it is necessary for the growth of the scrum team. When this does happen…
  • Provide cover for your team:  Your company/organization/business will not initially understand how your scrum team works. Coach up through the management chain so that “failure” and other experiments by the scrum team are encouraged, not punished.

Daniel Pink’s book “Drive” gives insights in to what motivates people and is the best argument against command and control that I’ve ever read. This is the book that project managers making the transition to scrum master should read – and then apply the lessons to their scrum teams.

Where in practice does the scrum master meet their servant role – can you give concrete examples?

A servant leadership minded scrum master should be a servant to their team every day. By challenging the team with a probing question during a sprint retrospective or by recommending a  fist of five check to get everyone involved in a discussion, scrum masters are constantly on the lookout for opportunities to apply their servant role.

I remember a particular situation as a scrum master where I had to work with a design manager who was against scrum and agile. He insisted on design reviews prior to any code being written and would mandate technical solutions that the scrum team did not agree with.

I was obligated by my role to try to coach this person in order to make sure that the scrum team was empowered to manage their work – within the bounds of accepted corporate standards. The discussions were tense and difficult. But the team came first. Eventually, we were able to work out modified design rules for scrum teams and we went on to have many successful sprints.

Situations like that are risky. I was dealing with a member of the management team and had to walk a very fine line in order to help the scrum team and keep my job. Ken Schwaber’s warning was constantly on my mind: A dead scrum master is a useless scrum master.

But things did – and tend to – work out.

Geoff Watts wrote and amazing book on scrum masters as servant leaders called “Scrum Mastery: From Good to Great Servant Leadership”. He goes in to a lot more detail about the habits and behaviors of great scrum masters. It is an excellent resource for any scrum master looking to improve.

Thanks to Darko for asking the questions about servant leadership. I hope that I’ve shed some light on this important topic. If you have a question or would like to see an agile topic covered please send me a message or leave a comment below. I look forward to hearing from you.

Question: What do you think it takes to become a great scrum master and servant leader? You can leave a comment by clicking here.