Chapter 7

Driving Productive Agile Activities

There are a number of agile activities that are necessary to keep your organization agile. A good understanding of these activities will help ensure that they are being conducted properly.

Staying Lightweight

The difference between an agile activity and a regular meeting is easy to spot. Like a bouncer in a nightclub, there are only five approved agile activities on the list. Anything else should be left at the door.

These five activities are the only ones necessary to support the framework. These are sometimes called the agile activities. These five activities are usually facilitated by the ScrumMaster.

The agile activities are scheduled, well-structured meetings and shouldn't be confused with the spontaneous discussions that come up as part of a shared workspace. Those impromptu chats are for when developers need to sort out problems or hammer out details about a task.

The shared workspace is intended to eliminate the need for scheduled meetings because in a sense, the agile team is always meeting.²⁰

The shared workspace relies on osmotic communication—the ability to take in conversations in a crowded space. It's similar to dinner-party chatter. You can eavesdrop on conversations even when you're doing something else. You can focus on getting the last scoop of mashed potatoes and still hear someone in the other corner debate politics.

Osmotic communication has been fine-tuned over millennia. Your agile team should take advantage of this natural ability by prioritizing team collocation. Just sitting together in a shared workspace is enough for the team to get an idea of everyone's progress.

Human beings are naturally inclined to take in information from a shared space. Scheduled meetings try to make up for too much unnatural communication. Think of the times you've had a face-to-face meeting and finally understood what someone was saying—even after they've sent dozens of email messages.

The combination of osmotic communication and a shared workspace should keep the team out of scheduled meetings.

Any scheduled meeting that is not one of the five activities is considered low-value work.

Agile views meetings that are not part of the framework the same way. It's not that these meetings are bad. It's just that they're not considered work. You can work on delivering your project or be in a meeting—not both.

This is particularly true of scheduled meetings for external groups. These are the meetings familiar to anyone who's worked in a large organization. It's usually a presenter using a slide projector to give a presentation to a midsized audience.

The challenge with these meetings is that they don't deliver value to the customer. Remember that agile emphasizes working software. Anything that's not working software is considered lower value.

In modern teams, working software requires some degree of internal collaboration. A slide presentation is not collaborative.

Presentation meetings are centered on one-way communication. The presenter is updating the audience. This is usually a status update, a budget request, or an executive summary. It's the meeting equivalent of comprehensive documentation. Instead of delivering a report, you're presenting a status meeting.

It's not just the work lost during the meeting. It's also the work that goes into creating the material. If you have ever created a presentation, think about the time that went into tweaking your slides, then multiply that effort by the number of meetings you attend every two weeks.

Some of these meetings are deeply ingrained in an organization's culture. That means you'll have to pick your battles. One thing to keep in mind is that you should be completely transparent about the productivity the team is losing.

The agile team in the organization that emphasized work socialization decided to keep track of all the hours that they spent during each sprint in socializing their work. They simply kept track of the hours on a whiteboard. This allowed the product owner to do the simple math and figure out how much productivity was being lost.

If external meetings take up too much of the team's time, then the ScrumMaster might see these meetings as an obstacle that needs to be overcome.

Timeboxing

An agile project depends on scheduled, repeatable chunks of time called timeboxes. A timebox is intuitively named. It is a box of time that cannot expand. If you have an activity timeboxed for an hour, the activity cannot go more than an hour. When the hour's up, the activity ends.

The timebox is the building block on which all agile planning and scheduling depends. All the work in an agile project is broken down into the smallest possible timebox. Even the developers have their own timebox—they must work within their eight-hour day. Overtime and working weekends will interfere with the predictability of the schedule.

To understand the importance of a timebox, you have to look at an agile project as a whole.

An agile project has less up-front planning. Remember that agile is adaptive and not predictive. The Agile Manifesto values change more than planning.²²

With agile, when you start the project, you don't know how it's going to finish. You start with a general notion of where you're going and make frequent improvements on how to get there. Agile is adaptive but not predictive. Much of the energy comes from these project changes.

In traditional project management, a plan has project milestones that lead to a delivery date. An agile project also needs a delivery date. You'll never have a successful project without delivery. No executive would ever accept a “you'll get it when it's done” delivery schedule.

This means an agile project needs a different method for creating delivery dates. The product backlog is always changing, so you can't use that to create milestones. The product owner has the freedom to change the deliverable throughout the project. The high-priority task created one month ago might become a lower priority the next month.

Even though your agile project has a flexible scope, the budget and time remain constant. So even though you might not know the full scope, you can still commit to the cost and the schedule. To do this, an agile project needs to build up the schedule with these immutable timeboxes. You'll build your deliverable one box at a time—like a LEGO project.

Since the timeboxes are always building up, it is important to maintain them for all your work and activities. The daily standup is usually timeboxed to 15 minutes. If it takes one hour one day and 10 minutes the next day, then you've introduced variability into your sprint.

This is true of the other activities as well. If the sprint-planning activity takes four hours one sprint and then two hours the next, one sprint will give the team an extra two hours of work.

It will be near impossible for the team to create a predictable pace if the timeboxes have no meaning. It is unfair to ask the team how much they can complete per sprint if they don't know how long they'll be in a standup, planning, or other activities.

The ScrumMaster on the team is responsible for making sure these timeboxes remain constant. It won't take long for the agile framework to break down when the team breaks the sprints or allows the activities to run too long.

Multitasking

If you started work at 9:00 in the morning and had three tasks which will take an hour to complete, how would you organize your schedule? When most people are asked this question, they will say that they would start one task at nine, begin another at 10:00 and start the last one at 11:00 in order to have everything finished by noon. They would start one task at a time and finish each one before starting the next one.

In reality, few people actually work that way. The way most people work is they start all three at 9:00 and do a little bit of each simultaneously. That way, they will have more time for all three. If something takes longer than an hour, they will still have time before noon.

This is commonly called multitasking.²³ Most organizations encourage that trait in their teams. That's why on job websites you'll often see “ability to multitask” near the top of the list. But multitasking comes at a heavy price. People can't work on a number of tasks divided into even slices of time. A person is not like a pizza where if you take two slices of task time, then you'll still have six slices left. No one works that way.

Think about the last time you were working on something important. Sometimes it takes a long time to get started. Then you'll get momentum. Maybe you've figured out how to finish a memo, or maybe you finally got a good idea about how to balance the budget.

Then somebody knocks on your door. Or there's a beep. You see an email with an exclamation point. You switch off what you were doing and focus on this new task. Then you have to switch back and restart what you were doing.

This is called context switching. You go from what you were doing to doing something else. The impact of context switching is much greater than most people realize.

Most people think that if they have an hour, they can finish two 30-minute tasks. What's actually true is that when you work on two tasks, you really only have about 48 minutes of work time, not 60. The other 12 minutes are overhead from switching back and forth between the two. Overhead is the time when you say, “Okay, so where was I?” and then go back to work.

The more tasks you have, the greater the overhead—the time you need when switching between tasks increases with the workload. You can see by the bar chart,²⁴ that by the time you're working on three tasks, you've spent more time switching than working. The chart also shows that when you're working on more than five tasks, there is no reason to come into the office. Three-quarters of your time is spent just figuring out what you're doing. Instead, you can come into work for just one day and focus on a single task and have the same productivity.

Agile is designed to reduce this inefficiency. The whole team should be focused on the fewest number of tasks. All the activities are timeboxed. This forces the team to finish one thing and start another.

The agile activities (the five approved activities) should run the same way. Each activity is designed to build a finished artifact. The ScrumMaster needs to make sure that each timebox will create one thing. Maybe it's the plan for the next sprint or it could be a list of improvements after the retrospect.

That means that at the end of the planning activity, there has to be a completed plan. You can't mix up this activity with something that you couldn't complete earlier. When the timeboxes are exhausted, the team has to work with whatever was finished. They can't schedule more time. They can't combine this activity with the next daily standup. This would create too much multitasking and cause all the work to slow down.

It also means that when everyone is focused on a team activity, they can't work on other tasks.

There's no reason to have an hour-long meeting where people are working on several tasks. Instead, it's far more efficient to have a 15-minute meeting where everyone is focused on a single task. Then let everybody go answer their email or work on their memo.

It is easier to plan for the next two weeks when the team is participating and they are fully engaged. They're all working together to complete a single artifact. Everyone in the rowboat is rowing at the same pace to the same place. If you have people on the team multitasking, it will slow down the entire effort, and it will take longer than the two hours you are allowed for this activity.

As a ScrumMaster, this might be one area where you find yourself in conflict with the project manager. Often the project manager will like people multitasking. It is the human equivalent of a Gantt chart. You have people working on multiple concurrent streams of work. From their perspective, this makes sense. Traditional projects often depend on multitasking to meet the timeline.

These managers and project managers might require extra coaching. It's very hard to overcome the belief that working more doesn't always deliver more work. An agile team works harder by working more efficiently. Often, the only way to convince them is by running the agile project and over time showing an increase in productivity.

Running Agile Activities

The five agile activities that support the Scrum framework are standup, plan, refine, demo, and improve. Each of these activities should produce an outcome. Four of the five are limited to a maximum time limit. The activity is lightweight but has a tight agenda. If you're the ScrumMaster for the team, make sure you understand these activities and their results.

In the beginning, most of the ScrumMaster's time will be safeguarding these activities. The ScrumMaster should always be running interference for the team to keep from falling victim to meeting creep.

In traditional projects, there's a tendency to make sure everyone has a voice. When a project overlaps with a department, then you need to invite a representative of that department to join.

In agile, the activities should strive to become smaller and shorter. The five activities should have the fewest number of people possible, since everyone should be focused solely on achievable results. That's why the agenda for these activities is limited and should be closely followed.

The Daily Standup

The daily standup is a developer-led, 15-minute activity where developers tell one another what they're doing. It is the only agile activity the team performs every day.

Of all the agile activities, the daily standup is probably the most misused. It's like the ranch dressing of agile activities—widely accepted but also widely abused. Standups are often repurposed and may end up taking much longer than their scheduled time.

The development team stands in a circle and updates everyone about what they're working on. It sounds simple enough, but that's not how most organizations operate.

Most meetings are driven by whoever called the meeting. A self-organized standup is contrary to how most people think of working. Most managers feel that a group left to stand and chat will continue to chat until someone starts the meeting.

The ScrumMaster and the project manager must fight the temptation to drive the standup. The team may start chatty, but they'll quickly become more disciplined. All you need is a few standups that end on time even though a few people didn't contribute. Most meetings will continue to run if there's unfinished work. Agile activities don't have that luxury. Agile activities end when the timebox ends.

You can also think of it this way. If the team can't self-organize a standup, then how will they ever deliver a working product?

The daily standup will be a good indicator of how the self-organized team is progressing. If you're the ScrumMaster, take a look at how the team interacts. Are they fumbling and unsure? Who are they looking at when they talk? These will be your clues about what the developers are thinking.

If they're looking at the ScrumMaster, it usually means they haven't embraced self-organization. Those developers might need some extra coaching. Try to encourage these developers to look at other members of the team. They need to understand that they're working for one another.

The standup is typically held at the beginning of every day. It's not first thing in the morning because the team usually needs a little time to settle. Most standups start at 9:30 in the morning. The team will stand in their shared workspace and form a circle. The team stands to keep the meeting shorter. If your team decides to sit down during a standup, then they may have a more difficult time finishing.

Some teams like to stand in front of the task board so they can point to their work. Other teams will stand wherever they're comfortable. Some aggregate around the team's coffee machine.

If you're not a developer, then you're a sitter in this activity. This usually means you'll sit off to the side taking notes. Only the developers should contribute to the standup. The ScrumMaster and the product owner can answer questions, but they shouldn't start conversations.

There is one daily standup for every team. You should never merge several teams into one standup. The timebox is never large enough to accommodate that many developers.

It's important to keep the standup moving. A midsized team of seven developers will have about 45 seconds per question. So when a developer talks about what they did yesterday, they need to talk about specific tasks. You don't want them to start knowledge sharing.

A good response to the question “What did I do yesterday?” is something like this: “Yesterday, I finished the username and password fields for the mobile customer login page. So I moved that task over to the done column.”

Compare that to this response, “Yesterday, I finally found out why it's so difficult to login to the mobile login page. It turns out the new version of JavaScript isn't fully documented, and so I had to spend a lot of time searching the web. I went to a website called Java dev. Has anybody ever heard of that? Their information was really the most accurate.”

Then they'll go on and on about the best way to find information about JavaScript. This response will quickly exhaust the timebox.

If this happens, the ScrumMaster should coach them on how to contribute within the timebox. The ScrumMaster should fight the urge to interject while the standup is taking place. This might mean a few failed standups, but it will be better in the long run to encourage self-organizing.

Many organizations have a really difficult time allowing teams to self-organize their standup. One warning sign is when the project manager drives the activity. They will go around and ask each developer, “What did you do yesterday? What are you doing today? Do you have any obstacles?”

This style of status update sends a clear message: “I'm going to organize this self-organized team.”

This arrangement will always slow down development. It will send a mixed message of how the developers should work. For one, it confuses the role of the project manager. Developers might start to think that they work for the project manager. Then they'll approach the project manager with management questions. If the project manager answers those questions, you'll quickly transform into a traditional project. The project manager will manage the team. A closely managed team is not able to self-organize.

It may cause even bigger problems if the team also treats the ScrumMaster like a project manager. Then you'll have a traditional project manager and an agile project manager. That's two managers for your self-organized team. This type of arrangement is difficult in a traditional project—for an agile team, it's completely unworkable.

Creating The Product Backlog

The product backlog is a ranked list of user stories. These are often called your product backlog items, or PBIs. How the list is created isn't very important. It could be a spreadsheet, 3 × 5 cards, or even a simple Word document. What is important is how the team uses the list. The product backlog is the only way to add user stories for the team. The product owner has the sole authority to add work to the project. That includes all work, whether it's a change request, additional documentation, or a new feature.

In a traditional project, the team relies on having complete requirements before the work begins. In agile, the product backlog replaces these requirements. The backlog doesn't try to capture all the work at the beginning of the project. Instead, it's an ever-changing document. Work goes into the backlog. The list gets reprioritized. The highest-value stories are reordered and pushed to the top.

A good way to think of your backlog is to think of it as your project's PEZ dispenser. A PEZ dispenser is a little candy case with the head of a famous character on top. When you push back the character's head, a tiny little candy brick spits out from under their neck. Each time you push back the head, another candy brick pops out. A PEZ dispenser will only produce one brick at a time. It goes from top to bottom. Each time you push back and a brick pops out, another one slides up to take its place.

The dispenser keeps you from having too much candy at one time. It acts as a constraint. The highest-value candy pops out from the top and the next brick slides up to take its place.

Occasionally, you'll take out more than you can eat in one sitting. All you have to do is open up the dispenser and reprioritize the extra brick. Maybe it's one of your favorite flavors, so you put it close to the top. Or it could be Wintergreen, and you'll want to put it near the bottom.

The project uses the product backlog the same way you go through these candy bricks. The backlog dispenses one story at a time from top to bottom. You finish the highest-priority item and then on to the next brick. The next story clicks in as the top one is pulled out. If it's too much, you open the dispenser. Then you can replace, relist, and reprioritize.

Not every organization will respect the product owner's authority over the product backlog. Some organizations that are new to agile might have managers who will throw work into the backlog. To work effectively, the product owner has to be the only person who manages the team's work.

Because the backlog is a ranked list of stories, there is no reason for the product owner to reject changes. It's a way to add work to the list without disrupting the team. This means that the product owner doesn't have to evaluate what goes into the list. They only assign the priority. That often makes it much easier to work with the project stakeholders. The product owner is not giving their work a simple yes or no; instead, the product owner is saying we'll get to it when we have time.

This doesn't mean that the product owner has an easy job. When the product owners prioritize the work, it usually means they have to de-prioritize other work. That can lead to some tricky conversations with their stakeholders. The product owners have to explain to stakeholders why their work is less important.

The product owner also has to work with the development team. Sometimes the highest-priority work is not the best way to develop the product. The development team might request that some lower-priority stories be grouped together to increase efficiency.

This is particularly true with software development. Sometimes it's easier to develop stories slightly out of order. The developers might request that they develop stories one, three, and five. It's not always as simple as developing stories from top to bottom—one, two, and three. When that happens, the developers need to make the case to the product owner. A little patience might mean more of the product gets delivered.

It'll be up to the product owner to decide what's fair. You need to balance the highest-value items against the functional realities of delivering software. This can usually be done without the development team leading the project off track.

Refining The Product Backlog

Backlog refinement is the most fluid of all the agile activities. All of the other activities have set times with set limits. The refinement of the product backlog happens as needed by the product owner. In this activity, the product owner will request a meeting to estimate any new items in the product backlog.

The product owner needs these estimates so the list can be prioritized. These meetings are the least structured. The product owner will go over the product backlog with the developers. Developers might make recommendations on how to organize the list. This may include breaking larger items into smaller items. They also may talk the product owner into removing some items from the list because of complexity or redundancy. The team will also make estimates on the new items, which usually means another round of planning poker.

In Scrum's early years, this was called backlog grooming. Most of the Scrum community later abandoned the term.²⁵ Instead, they settled on the more neutral term backlog refinement.

Whichever you call it, the activity is pretty much the same thing. You refine the backlog by adding, removing, or updating the backlog items.

In many ways, refinement is probably not the best word. In the beginning, you'll be adding a lot of new stories to the backlog. It doesn't seem like much of a refinement if your backlog continues to grow. It's very common to have your backlog grow into a very large list. Then later, the product owner will prune down some of the items. It's better to think of the activity as backlog preparation.

The product owner should spend four to eight hours a week with the team on this activity. The backlog preparation should be timeboxed for two hours or less. Anything longer than that and the team will start to lose focus. The activity should be open and set up for discussion.

Typically, the activity starts with the product owner presenting a few user stories to the development team. The development team will try to understand the user stories at a high level. Remember that the development team doesn't task out the user story until sprint planning. The ScrumMaster should work hard to make sure that the team doesn't get too much into the weeds of how to deliver the story.

Once the team understands the story, they can go through a few rounds of planning poker. This will give the product owner a relative estimate of how much effort it takes to deliver the story. Then the product owner can go back and use this estimate to reprioritize the product backlog.

Usually, the biggest challenge with backlog preparation is how often to schedule the activity. The backlog represents the project's future. The question is how much of the present you sacrifice to prepare for the future.

The team runs into a similar problem with the backlog. If you spend too much time planning for the future, then you won't have enough time to finish what you need today. If you ignore the future, then it will take up too much of your time tomorrow. You have to set aside just enough seed corn to ensure the project keeps growing, but not so much that the team stops working on what they need today.

The team might spend as much as one full day each sprint preparing the product backlog. That might seem like a lot of time to tie up the entire team, but remember that this activity takes the place of more traditional project requirements. In traditional projects, it is certainly not uncommon to take one month to plan a one-year project. For many organizations, that would be much too quick. Agile spreads out this planning over the entire course of the project.

Still, it might be tempting to cut back on product-backlog preparation. It'll be up to the ScrumMaster to ensure that the product owner is getting the time needed to plan for the future.

A good way to remember the agenda is to think of the acronym DEEP. This acronym was created by Mike Cohn and is a good starting point for backlog refinement.

In this activity, the stories should be detailed appropriately. The highest-value user stories should be well understood so they can be completed in the next sprint. Distant stories can be described with less detail.

The stories should be estimated. The product backlog is more than a list of work. It is also a planning tool. Again, place the highest priority on the top stories. Stories further down can get a rougher estimate.

Once the team understands the stories they can go through a few rounds of planning poker. This gives the product owner an estimate of how much effort it takes to deliver the story. The product owner can then use these estimates to reprioritize the work.

The product backlog should be emergent. A backlog is not static. It will change over time. As the team learns more about the product, new user stories will be added, removed, or changed.

The backlog should be prioritized. The backlog should be sorted with the highest-value items at the top. The least valuable should be at the bottom. This way, the development will always be working on the highest-value items.

Planning Your Sprints

The sprint-planning activity is where the team decides what to deliver for the sprint. The activity is usually timeboxed to four hours. In this activity, the team plans and forecasts the work for the next two weeks. The team will take the highest-value items from the product backlog and make sure that everybody understands what needs to be done.

It's essential that the product owner attends this activity. The product owner decides what's next and needs to be available for questions. The product owner will take the top value stories and present them to the developers. Then they'll task out the highest-value stories.

Your team could also decide to plan the sprint without a task board. Many agile software packages provide virtual task boards. This has the advantage of allowing the teams to see the tasks without visiting a real board. The downside is that it minimizes the importance of the shared workspace.

When starting out, it is usually best to plan your sprint without any software. You may have the ScrumMaster create a second software board with all the stories. That way, if you switch, you can still have the benefit of historical reporting. The reason it's usually best to start analog is that it encourages the team to sit in the shared workspace. Developers are usually technophiles and prefer to work with software. That might make this a tough sell for the team.

At the start of the sprint-planning activity, developers decide how they will contribute to the story. They'll write a yellow sticky note with their tasks for each story. The team usually starts tasking the highest-value items first.

A task should be no more than one day of work for each person. When a task represents more than one day of work, then the task board doesn't reflect the team's progress. You don't want one sticky to represent a task that is a day long and another sticky to represent a task that is a few hours long because then there would be no way to tell how much work is left after the sprint begins.

It is best if sprint planning is scheduled immediately following the demo (the activity to show the results of the last sprint). Since the demo just concluded, there shouldn't be any work left. It's a terrific time to plan without impacting the team's productivity.

The activity should begin with the product owner delivering the stories that they wish to complete in the upcoming sprint, but the product owner shouldn't drive the activity.

The product owner should think of themselves as being customers in a restaurant, except instead of ordering dinner, they're ordering what they want delivered in the sprint. You'd never have a customer going back and standing over the chef. The same is true with the product owner. They are there to answer questions and not drive the team to deliver. They can have their salad dressing on the side. What they can't do is force the team to deliver a full meal for less than a dollar.

Agile pushes for transparency when planning the work. When a product owner tries to drive the team, they will only damage the reliability of their estimates. In agile, the team's productivity is seen as a constant. The developer shouldn't have to be coaxed into being more productive.

The product owner is there to produce the highest-value stories. It's up to the team to decide how they're going to deliver.

After the product owner delivers the highest-value stories, the developers should start tasking. Hopefully, the team will have estimated the stories in an earlier product-backlog refinement, so this shouldn't be the first time that the team sees the stories in the product backlog. They would've also asked questions about the story as a way to create an estimate.

Sprint planning is usually when you find out how good you've been with refining the backlog. Converting a user story to daily work is not always a smooth process. It's not uncommon for the development team to say things like “That's what you meant by that? I thought you meant the other thing.” Then they'll have to break down the story into smaller stories or quickly re-estimate.

As teams get better at backlog refining, they will spend less and less time talking about the stories during sprint planning. That way, they can spend less time focusing on what the story is and, instead, decide how they're going to deliver.

Demoing The Work

At the end of the sprint, the team schedules a review of the deliverable. This is sometimes called the sprint review. It's also commonly called the sprint demo. The team usually takes two hours to show the completed work to the project's stakeholders.

The product owner usually drives this activity since the product owner will have the closest relationship with the stakeholders and is probably best qualified to answer questions.

The sprint demo should actively engage the stakeholders. The theme of every demo is “here is what your money bought you over the last two weeks.” A good demo will also get suggestions and feedback from the stakeholders.

It's a bit of a double-edged sword to call the activity a demo. On the one hand, you're much more likely to get everyone to attend. A demonstration activity sounds far more alluring than a review. On the other hand, you don't want to give the stakeholders the idea that they need to sit and watch.

In larger organizations, a demonstration is usually a slide deck with screenshots. For a sprint demonstration, the agile team walks through a working deliverable—most of the time, that's software.

The agile demonstration is about communication and accountability. This is the activity where the stakeholders justify what they've spent with what the team's delivered. They should be thinking to themselves, “Okay, I spent so much money and here's what I have to show for it.”

The demonstration should be on the last day of the sprint, and it should be the first of the sequence of activities that end the sprint. The last day of the sprint will typically have a demo, then a planning activity, and then a reflection activity like a retrospective.

The agile demonstration is typically scheduled for two hours, but you may find that it is difficult to get project stakeholders to attend a two-hour activity late Wednesday afternoons. If your project has high-level stakeholders, then the team may be better off scheduling a one-hour meeting. But keep in mind that this arrangement puts more pressure on the product owner. They'll need to communicate more often with the stakeholders during the sprint.

As stated earlier, the product owner is the one who drives this activity. This is a common practice even though it's not explicitly stated in the Scrum framework. This is the only agile activity that has the development team sitting in the background. The talker in this activity is the product owner and the sitters are the rest of the team.

There are four reasons to have the product owner drive this activity. The first reason is that it helps the product owner feel like they have a stake in the outcome. The product owner should be keenly interested in the task board at the end of the sprint. They know that in a few days they'll be the one standing up in front of the stakeholders. Instead of some far-off deadline, the product owner has real-time skin in the game.

The second reason is that the product owner usually has the best relationship with the stakeholders, so you're more likely to get good back-and-forth feedback. The product owner should see the product from the view of the stakeholders and should describe the product the same way and have the same goal as the stakeholders.

The third reason is that you need to make sure that the stakeholders share the same vision with the product owner.

The fourth reason is that the development team is not usually very good at driving a demo. Often, the developers will talk about the product as a capability and not as a solution. They might talk about what software does and not necessarily why the software is valuable.

Sometimes the developers will do a NASCAR-style doughnut in front of the stakeholders. They may misinterpret this activity as a victory ceremony, and may view it as a good time for the team to get hard-earned recognition. Unfortunately, the demonstration is not nearly so satisfying.

If developers run the demo this way, it is likely that it will be lightly attended. The stakeholders might be patient in the beginning, but they will probably not want to sit through an activity every two weeks hearing about how great the team is doing developing great software.

Start running the demo correctly from the very beginning. The stakeholders are more likely to provide great feedback when they realize that this is their activity. Make sure that the product owner drives this activity. The rest of the team should be sitting in the background. Have them listen to how the product owner describes the product to stakeholders. If they have questions, they should save them for sprint planning.

Team Improvement

The self-improvement activity is limited to 2 hours and happens immediately after the product demo. This activity is often called a retrospective. Of the five activities, this one is arguably the most important because if the team can't improve, it will usually make the same mistakes each sprint.

In the beginning, the ScrumMaster may need to push the team to commit to specific improvements. Every organization has challenges and it will be the ScrumMaster's responsibility to keep the activity positive and productive.

If these five activities are done correctly, then the team will stay lightweight and productive.

Inviting The Right Groups

Agile activities are always timeboxed. Since the time is limited, there's always pressure to make the activities as efficient as possible, and it is the ScrumMaster who is responsible for setting up efficient activities. This means that the ScrumMaster is very careful about who contributes.

Often on an agile project, there are stakeholders outside the team that want to attend. Sometimes, agile is just starting in an organization, and these people want to attend out of curiosity. Other times, someone will have an interest in the deliverable and may want to have a connection to the project.

It's true that the agile team will almost always benefit from the added attention, but the challenge is to maintain the interest level without bogging down the team with overzealous participation.

The ScrumMaster should think about long-term efficiencies. It wouldn't be a good idea to tell an executive that they can't talk during a daily standup. If an important person passes through, it is best to let them contribute. What you do need to watch for are stakeholders who attend your activities on a regular basis. This is more about the senior manager who starts talking through your planning activities.

It's best to set a standard early in your agile project. If you let the activities turn into a group forum, then it will be very difficult to tie them down later. At the very beginning, the ScrumMaster should set the expectation that during an agile activity, not everyone is expected to contribute.

Trying to get everybody either sitting or talking will keep things moving. Sitting or talking is not a euphemism. A sitter should actually be sitting, and they should be sitting off to the side. This is a signal that they're not expected to contribute.

Sometimes it is a bit delicate to let someone know that he or she shouldn't be contributing. Some people interpret this to mean that they don't have anything valuable to contribute even if this isn't true.

The ScrumMaster needs to defend the agile activities and needs to stress to the participants that it's not about what they're saying, it's the forum. The timebox gives the activity very little wiggle room. This means the time is vulnerable to being hijacked.

Sometimes a sitter might hijack your activity and make an announcement or ask questions. The sitter may think there's no point in scheduling another meeting when everybody's already there. The ScrumMaster needs to ensure the sitter's concerns are addressed at another time and not during the focused agile activity.

The daily standup is the activity that's most likely to be hijacked. In the standup, the developers are the talkers. The activity is for them. The product owner, the ScrumMaster, and the project manager should always be sitters.

The activity will almost always break out of its timebox if the project manager hijacks the activity.

The product demo is another activity that is difficult to keep on track. The product owner usually drives this activity. They need to make sure that they agree with the sponsor on the vision for the project. What often happens is that the developers will want some visibility.

This makes sense. The development team has been working on this project and they have some pride in the deliverable. They'll want to show the sponsor all the bells and whistles. There is also an urge to spike the football. If the sponsor mentions something that was well done, then the developers might want to accept their share of the credit.

The product demo is also timeboxed. To run efficiently, the development team needs to sit and not contribute. The only time the developers should contribute is when the product owner asks them a question. Otherwise, the team should do its best to communicate that this is the product owner's activity. The rest of the team is there to sit and watch.

Often sitting and listening will give the team a much better sense of the activity. I've seen many demos were the development team picked up on cues that the product owner missed.

Gathering The Roadblocks

An organization is always looking for leaders. Managers complain that they need more leaders. Executives look for leadership qualities to promote or hire. They'll send senior managers to leadership seminars. They'll recommend the best leadership books.

Leadership is associated with someone who takes responsibility for outcomes and who drives the team forward.

There's no doubt that leadership plays a role in organizations. A great leader can do great things. But a lot gets done by people who aren't leaders. Not every great change requires great leadership. It's not always the person pushing forward. You also need people to keep the team from sliding backward.

That's where the ScrumMaster comes in. The ScrumMaster needs to remove the obstacles, so the team can focus on delivery. These obstacles can mean many different things. Sometimes it's hard for ScrumMasters to sort out the difference between removing obstacles and managing the team.

There is no clear list of every obstacle. The list will change depending on your organization. Even within the same organization, you're bound to run into many new obstacles. Instead of thinking of obstacles individually, try to think of them in terms of groups. In general, there are five groups of obstacles that you'll run into on your project. If your obstacle is not in one of these groups, then you might be in danger of managing the team.

You can remember the five groups by thinking of the word SMITH, which stands for setup, mentoring, input, training, and hiring. These are the five groups where you'll find most of your obstacles.

Setup: In some organizations, setting up a shared workspace is an enormous obstacle. If your agile team works on a floor with rows of cubicles, then it may be difficult to create a shared workspace. The organization may think these cubicles are the best way to work.

Setup is not just limited to a shared workspace. It also includes team roles. Sometimes an organization won't dedicate a product owner to the team. It will be the ScrumMaster's responsibility to convince the organization that the team won't succeed without a product owner.

Mentoring: This is the coaching part of the role. The ScrumMaster should be very knowledgeable about agile, particularly since the rest of the team may not know that much about the process.

This is particularly true with product owners. In many ways, product owners have the most to learn. They'll know the product, but they may not know agile. The ScrumMaster should work with them from the beginning to help them define their role and create a product backlog.

Another obstacle ScrumMasters could face is that the developers might not embrace self-organization. The ScrumMaster may have to coach them as well. The ScrumMaster should sit with the team and offer guidance. If an individual developer is having trouble with self-organizing, the ScrumMaster should pull the developer aside and set up time to help.

Input: The ScrumMaster will often come from a technical background. They're not developers in the project, but they might still offer best practices to the group.

It is very important for ScrumMasters to distinguish between input and direction. As a general rule, input is asked for and direction is given. Input is when the developer approaches the ScrumMaster and asks for an opinion on a JavaScript library. Direction is the ScrumMaster having a meeting with the developer, then encouraging the use of a JavaScript library the ScrumMaster has used in the past.

Training: It's the ScrumMaster's responsibility to assess the team's knowledge of agile. Many developers have worked on agile-like projects, but some of their practices might be wrong. Depending on the experience of the team, they might be spreading these incorrect practices. Other times, the team starts agile without any training.

In either case, the ScrumMaster needs to identify this as an obstacle. Agile training is a good way to get everyone to understand the framework, and it is also a good way to get everybody doing the same thing.

Hiring: The ScrumMaster's role in hiring is an advanced topic. A self-organized team should have control over their own developers. If not, you're giving the team responsibility for delivery but no authority to make any changes. Also, the team should know the most about what makes a successful developer.

But you don't want the team interviewing developers and posting jobs. It will take too much time away from development. Also, many organizations don't like other team members knowing one another's salaries.

Keeping The Activity Moving

To become fully agile, the team needs to abandon much of the traditional project management mindset. Traditional project management can be high stakes. If you're wrong about an estimate, then the project will need more money. That's usually not a happy result for the project manager.

Agile activities are different. An agile team needs to accept these differences. One of the big differences is that agile doesn't assume immediate expertise. It's pretty much accepted that a new agile team will be terrible at estimates and slowly get better. The same is true with sprint planning. The team will be bad with tasking, and the stories will usually be worse.

To be productive, an agile team has to have the courage to be wrong. Fear of the unknown cannot be an excuse for inaction. Projects, by definition, are almost always something new. Even longtime professionals will have a learning curve.

That's why in Scrum and extreme programming, there are several references to courage. It takes courage to accept that you might be wrong. The team still needs to move forward. Many organizations put a high penalty on being wrong. Accepting that they might be wrong may not be easy for developers who've worked on traditional projects for large organizations.

Moving The Daily Standup

Watch for developers who don't mention obstacles in the daily standup. This doesn't mean that they don't have obstacles. On the contrary, it sometimes means that they've stopped working.

It takes courage to stand up in a meeting and say you were wrong. Many developers strongly prefer to quietly engineer a fix before anyone notices. The challenge is when these fixes take time away from the sprint. Instead of being transparent, they start to work on fixes that the other developers don't even know about.

Moving The Backlog Refinement

Relative estimating is another area where the team needs to be comfortable with uncertainty. When many developers hear the word estimate, they think, “What is the longest I think this will take?” A relative estimate is not the worst-case scenario. It's not even really an estimate. It's a best guess.

One warning sign that the team is having trouble in this area is when the team complains that they don't have enough information. When the developers complain about this, what they're actually saying is, “I don't know what it takes to finish what you're asking for.”

When that happens, you need to remind the team that it takes courage to guess. Not knowing how you can finish doesn't mean that you can't get started.

Moving The Sprint Planning

You may also see this lack of commitment when tasking. The sticky notes need to represent one day of work. Many developers don't like to break down the stories into tasks. They're concerned that they might run into something that will take much longer than expected. So they'll create one large task that spans several days in the sprint.

Listening To Feedback

Agile doesn't have much up-front planning. The team instead relies on real-time feedback to keep their project on track.²⁷ These feedback loops are the best way to respond to changes.²⁸ That's why agile gets real value from project changes. It's the engine that drives the team to produce and improve.

The agile activities are designed to help create these loops. If there's no feedback, then it's probably because the team is not following these activities. It could also mean that the team is following activities, but not everyone is participating. If feedback is stalled, the project will most likely grind to a halt. It's very important to keep these feedback loops working so that the team can deliver something of value.

There are a few warning signs to look for when the team is not creating feedback loops.

Feedback During The Daily Standup

Feedback in a standup is a little tricky. It's a pre-feedback activity that gives you the information that you need before you can offer any feedback. In general, you want to announce challenges in large meetings and solve them in small meetings.

The standup activity is the large activity where everyone gets updated. It's a one-way conversation. The team members individually relate their tasks and obstacles. They don't try to solve anything.

What you want is feedback after the activity. The team needs to coordinate after the meeting. Developers should be reacting to what they heard. They should be sewing their work together. The ScrumMaster should be getting the information they need to remove obstacles.

The team is not having those conversations if after the activity, they scatter like a box of spilled cereal. If you're the ScrumMaster for the team, then you need to fix this loop. Is the team breaking the project into areas of responsibility? Is everyone waiting on someone? These are the types of obstacles you'll need to sort out.

Feedback During Product Backlog Refinement

The product owner should be scheduling as many refining activities as necessary to prioritize the backlog. The product backlog should be an ever-changing list. The team should take a look at the new ideas in the backlog. The product owner may have to reprioritize some of the user stories. They should discuss the impact of the change with the team.

If the product owner doesn't have these activities, this feedback loop will be broken and the product backlog will freeze. Then the team may not be working on the highest-value stories. This usually happens when the product owner doesn't dedicate the time needed to successfully fill the role. What you end up with is a concrete requirements document that seldom changes.

This is another time when the ScrumMaster should see the problem and talk with the product owner about a possible solution. Sometimes the product owner just doesn't have the time to maintain the product backlog. When that happens, it might be a good idea to ask the product owner to dedicate an assistant to fill the role full time. It's better to have a product owner with more time and less clout than a product owner with no time. A product owner without sufficient time will end up slowing down the team.

Feedback During The Sprint Demo

One of the most important feedback loops is the sprint demo. This activity needs to ensure that the customer is giving feedback to the product owner and that they share the same vision for the deliverable. There are a few things to look for if this feedback loop isn't working well.

The first is when you hear the customer asking the same questions over and over again. If that happens, the product owner might want to create a heard it/did it board. This is a simple way to record what the customer is saying during the demo. It might mean that the customer is not being heard or it might mean that the customer isn't recognizing the request in the product backlog.

The product owner creates a whiteboard with two columns. As the deliverable is being demoed, the product owner should put all the feedback under the heard it column. For the next demo, the product owner should move everything they completed from that sprint to the did it column.

This whiteboard shouldn't be a replacement for the product backlog. What it can do is give a high-level view of the feedback that goes into creating the backlog. It can help the product owner start a conversation about the priority of the work. If the same feedback is in the heard it column after each demo, it might mean that the product owner is not doing a good job prioritizing the work.

Feedback During The Retrospective

A lot of teams think that the retrospective is the most important of all the activities. This is when the team gives feedback to one another about the work. Again, it's much easier said than done.

When the team is starting out, they don't really know how to give one another good feedback. On traditional projects, there isn't a standard way for everyone to give each other feedback. Sometimes, there might be a meeting after the project is complete, but usually there is only a meeting while the work is ongoing.

The facilitator for the team needs to make sure that everybody in the retrospective is talking. Often the quietest people on the team have the most to say. They just need to be coaxed to share their feedback. The facilitator needs to be careful not to be too active, though, because it might stifle the rest of the team. The facilitator should organize this activity, not drive it.

If the retrospective is too quiet, then the facilitator may want to ask some very open-ended questions. They can use themselves as a way to get people talking. Something like, “What could I have done better this last sprint?” and “What did I do really well this last sprint?” If that works well, then just ask the team to pose those questions to one another.

Agenda Setting

You need to be careful that your activities are not taken over by people who do not have “skin in the game.” Not everyone needs to participate in your meetings or is committed to the process.

You should think about this joke when you start your agile activities. Who's really got skin in the game? In agile, you routinely hear about chickens and pigs. The chickens don't have any skin in the game. They are free to listen. But the activity is not for them. It is always for the pigs. They are the people who are truly committed to delivering the project.

Even though the pigs are fully committed, it doesn't mean that they drive all the activities. Pigs are sometimes sitters and at other times talkers.

In some organizations, the senior managers will stop in to watch the daily standup. It's a good way to see the team's progress. The ScrumMaster needs to communicate the fact that they shouldn't participate in the standup. They might be senior managers in the organization, but on a Scrum team they're chickens.

Depending on the organization, your activities might be overwhelmed by chickens. It's the ScrumMaster's role to make sure that the chickens don't take over your pig team. Sometimes getting chickens to accept their status is not an easy assignment. Chickens are always sitters and never talkers. It's difficult to keep salespeople and managers from talking to the team during the standup. They almost always want to offer guidance and advice.

One way that the ScrumMaster can help is by sitting down in between the chickens and the developers. The ScrumMaster can physically block access to the team. Managers who don't know agile very well will often misinterpret this activity. They assume that the team is giving a status update to the ScrumMaster. They think the ScrumMaster is a manager and the team is giving a progress update. The ScrumMaster can sometimes quash interruptions by just asking that the chickens save any questions until the end of the standup.

This is one of the challenges associated with being a ScrumMaster. Sometimes you'll have to “speak truth to power” to protect the team. In some organizations, the agile team will have different organizational managers. It will take some finesse to tell a manager that they can't question someone who works for them.

The key is to focus on the agile process and how things are run. If you're the ScrumMaster, try to emphasize that you're not saying they can't talk to someone who works for them. You're only asking if they could refrain from asking questions during this 15-minute activity.

Reporting Status At Standups

There are a lot of challenges around having a good daily standup. Overzealous managers could hijack the activity—the people who should be sitting decide to talk. The agile chickens may see this as a town-hall sharing session and may begin taking up valuable time with questions or visioning.

All these obstacles are there and you should be aware of them. But the team has its own challenges. Even without all these distractions it's difficult for the development team to get into a 15-minute rhythm.

There are usually many different personalities on a development team. But there are some common personalities that may cause problems during a standup. The ones you'll most likely see are the late risers, the Oscar winners, and the educators.

The one I'm most sympathetic with are the late risers. These are the developers that have trouble focusing first thing in the morning. You can usually identify them by the telltale giant coffee mug.

A good agile team should have about five to nine developers. Each one should talk for about three minutes. That's their three questions, one minute each. That gives 15 to 30 little bits of information. That's a lot of information. It is especially a lot for someone who doesn't spring out of bed. It's very easy to start zoning out.

Typically a late riser will zone out for everyone except for the person immediately to the left and right of them. The standup almost always takes the form of a circle. It's easier for a late riser to listen to the person who's next to them than it is to listen to anyone across the room.

The ScrumMaster can usually tell the late riser because they won't talk with anyone immediately after the standup. They'll want to plug into their computer and just start working until they wake up. Unfortunately, the conversations after the standup are key for communication. When a late riser skips these activities, they are missing out on a crucial self-organization exercise.

The second personality that might give you trouble is the daily standup Oscar winner. Have you ever watched the Oscars when someone wins and stands up in front of a crowd holding their new gold statue? They thank their friends and relatives. Then the music starts. They start trying to shout over the music. Finally someone shows them back to their seat.

There are times during the standup where you might wish you could summon your own orchestra to encourage a team member to finish up. There are some developers who cannot answer the three questions succinctly. Sometimes, it's because they talk very slowly. Other times, it's because they thank other team members for their help. Maybe they'll remind the ScrumMaster that there is still an outstanding obstacle. Whatever the case, the additional chatter will quickly eat up time for the rest of the team.

It's the role of the ScrumMaster to keep this activity moving. They may want to talk to this person after the activity and remind them of the timebox. Sometimes that's not effective. For those tougher cases, you may want to bring back your koosh ball. No one wants to tell someone they need to stop talking, it just feels rude. It's much easier to tell a long-winded developer that it's time to “throw the ball.” If you remind the developer enough times, then after a while it usually becomes a natural habit.

The final personality that might get you into trouble in the standup is the educator. You definitely want a lot of knowledge sharing on an agile team. Ideally, each team member should be able to work on everybody else's tasks. What you don't want is for that knowledge sharing to happen during the standup. The activity just doesn't have a timebox to accommodate that extra information.

It's very typical that developers will want to share some of their solution when talking about their work. That's just how many good developers think. It's difficult to separate the work from the solution.

The team can run into trouble when the daily standup turns into an ad hoc brainstorming session.

You want developers to talk about what they did, but not why they did it.

Breaking The Sprint

Breaking the sprint is when the team cannot create a high-value deliverable at the end of two weeks. This is also called abnormally terminating. If your team has old-school developers, they might use the dorkier abnormal ending or ABENDing the sprint. This is borrowed from the language of software crashes. Some teams even call it “blowing up” the sprint.

There are good and bad reasons for blowing up a sprint. A few of the bad reasons to blow up the sprint have to do with challenges the agile team had to face. Maybe the team was terrible at estimating, or sometimes people get peeled off the team for emergency projects. Other times the team runs into an obstacle they can't overcome.

Some of the better reasons for blowing up a sprint have to do with the product owner and the backlog. Maybe the highest-value work suddenly changed. When that happens, the product owner doesn't want the team delivering something that the customer no longer wants.

Breaking the sprint takes away some of the predictability from the project. The lost time causes a chain reaction that pushes all the future work forward.

On this project, the team committed to delivering in 20 sprints. That means the stakeholders were expecting a product in 40 weeks. When the team broke a sprint, there was a new chunk of missing time. The team will either have to scale back on the deliverable or add time to the delivery date.

On this sprint, the product owner was responsible for the mistake. The product owner recognized the gap and quickly moved to make changes.

Other times, the development team pushes to end the sprint. It's a lot more treacherous when developers want to blow up the sprint. It is the ScrumMaster's responsibility to determine if they're working within the framework.

There are a few common reasons why the development team would want to blow up the sprint.

When the team is just starting out, they will most likely be very bad at estimates. They may have underestimated some of the highest-value stories. There may have also been some unforeseen event. Maybe the entire development team ate at the same restaurant and all got food poisoning.

In general, bad estimates and unforeseen events are not good reasons to blow up the sprint. Often the development team is really trying to avoid an embarrassing demo. The team can only show their finished deliverables at the end of the sprint. It would be awkward if the team can't show any deliverable. Even worse, they may try to create a smoke-and-mirrors demo with slides and screenshots.

When that happens, the ScrumMaster should try to keep the developers from blowing up the sprint. That would be cheating the framework. The development team is trying to put their thumb on the scale. They're giving themselves bonus time for bad estimates. As the protector of the framework, this is the only time the ScrumMaster should weigh in on this decision.

All other times, it's solely the product owner's decision whether to blow up the sprint. The development team is delivering the highest-value stories for the product owner. It's ultimately the product owner's call whether there is enough to demonstrate.

It's the ScrumMaster's roll to guard the framework, but the team still works to deliver value for the customer. It's not realistic to try and force the product owner to demo something that isn't ready. The ScrumMaster can make the case, but ultimately it's the product owner's decision.

---

²⁰ “Individuals and interactions over processes and tools,” from The Agile Manifesto

²¹ The Effective Executive by Peter Drucker (1993)

²² “Responding to change over following a plan,” from The Agile Manifesto

²³ “If you chase two rabbits, you will not catch either.” – Russian proverb

²⁴ Quality Software Management: Systems Thinking by Gerald M. Weinberg (1991)

²⁵ In some countries, it refers to the potential mistreatment of children.

²⁶ Unfortunately, they were awful.

²⁷ The Agile Manifesto Principle 2 is: “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.”

²⁸ The fourth value in The Agile Manifesto is responding to change over following a plan.