The Scrum Master’s Guide to a Better Scrum

History

I’m old mature enough to have worked for companies that used a Waterfall methodology to deliver their software. There was always something nice about having time to figure out problems on your own with a longer time frame, and I liked reviewing a pile of documents (honestly).  Back in the day, I would walk across the street to a restaurant and review the documents that were related to my task at hand. Then, I’d begin coding, knowing we had a once-a-month show-and-tell of our progress, just to keep our contracts. New requirements? Another lunch-and-learn.

Most companies have moved to an Agile approach to Software development, and after operating two start-ups with daily changing requirements, it’s clear to me why this approach works.

However after working for several different companies, I’ve realized there is a plethora of companies that consider themselves agile, but they’re not Agile. Sometimes, they claim to be somewhere in the middle of Agile and Waterfall, which is one way of saying, “We’re still trying to work it out.”

These companies often have a Scrum which isn’t a real Scrum. For simplicity’s sake, we’ll call this the “Artificial Scrum”.

For all of those companies that are still trying to make Agile work, I’m going to help, by introducing this blog post, which we’ll call, “The Scrum Master’s Guide to a Better Scrum”, to help understand how to turn an Artificial Scrum into an Authentic Scrum.

How different companies approach Scrum

A “Guide” isn’t complete without some real-life examples, so I’ve included a few approaches to Scrum I’ve seen over the years to give a better sense of the various styles.

Company A

• Media: Excel Spreadsheet / Overhead Projector
• Approach: Everyone gathers in a board room for an hour. Project Manager asks each developer about their current assignment. Developers aren’t allowed to break-down their stories. Developers can’t add stories when they stumble upon a new impediment when someone added a story called “As a user, I want to submit one million fields of data”. We just skipped the conversation about impediments. Our impediments just became “phantom” impediments. Most important piece of “Scrum” is reducing hours on the Spreadsheet.

Company B

• Media: Agile Software / Overhead Projector
• Approach: Everyone gathers in a board room for an hour. We’re standing, because the meeting is “Agile” and in “Agile” you don’t sit. After a few minutes, people start gathering chairs. After 45 minutes, 1 guy always leaves while shaking his head. Most people in the back of the room are playing Words with Friends. Project Manager asks each developer about their current task. People put their phones away only long enough to explain their task. One guy continues to answer questions while deciding if he can actually score more points on the triple-word spot, or if that is just going to set his opponent up for too much success. A task has an estimate of 120 hours. If you never broke your stories into tasks, you never actually came up in the discussion.

Company C

• Media: A man gathers information on a clipboard. No one ever sees the clipboard.
• Approach: Company doesn’t believe in online meetings. Everyone gathers in the manager’s office to discuss what they’ve done. The manager is never on time. People linger and wait, which is awkward, because no one really talks to one another. The manager shows up and closes the door. There are no stories, no tasks, just a man with a clipboard. The manager yells at each developer for 3-4 minutes, because the scope keeps changing. The person who keeps changing the scope is a very nice, elderly consultant in his mid 70s who lives in Canada. He only attends Scrum when he’s in town.

I’ve only worked for one company that was truly agile, and this article is a chance to share with you the differences between what made that team truly agile, versus the other companies which had meetings called “scrums” that weren’t actually “scrums”. We’ll call this company, “Company D”.

Company D

• Media: Storyboard Software / Online Scrum
• Approach: Everyone joins an online meeting room for no more than 15 minutes, answers a few short questions, and then goes about their work. Project was delivered on-time and on-budget.

Retrospective

Company D had an agile team that produced quality software, with 100% code coverage. They had the highest morale of any group I’ve worked with over the years, and they really seemed to do everything by-the-book (and when I say “by-the-book”, I’m referring to “Code Complete“), not just the idiom. I really liked working with this team because you spent most of your day writing code, uninterrupted, and your metrics for progress were simple:

1. Write code so you can close a very tiny task in a Story
2. Add a unit-test with 100% coverage
3. Commit code to the repository with the associated story ID and story description
4. Add at least 4 reviewers to the commit

The first day of the job, Company D told me their Scrum time began at 11:30am.

“11:30am?”, I thought, “That’s right around the time I see most of the staff exiting the door for the cafeteria. That’s lunch-time for me these folks!”

The Guide

Most Scrums are actually meetings, and by meetings, I don’t mean a collective gathering of people with the same department head. I’m talking about meetings that actually last longer than my last car-negotiation. Longer than the last time a home-repair contractor told me he was almost done.

The right-before-lunch-time-although-this-may-actually-be-lunch-time Scrum worried me. For a lot of companies, Scrums were a way to ensure everyone got to the office by 9:00am. Scrums were a way to loosely verify through an oral summary that work was being done. And then, the hour + countdown began. I was afraid we’d be sitting at our desks as some form of collective punishment, hungry, but too weak to be engaged in conversation.

However, the conversation was in the Scrum was pointed and fluid. We were usually done with Scrum well before lunch, and I attribute the efficiency to “The Hawk”.

Step #1: Release The Hawk

Company D had a woman whose only job, as far as I can tell, was to ensure the meetings never went off-topic. She was, for lack of a better name, “The Hawk”. If anyone ventured off-topic from “The 3 Questions”, if someone else chimed in with their two cents, she cut them off mid-sentence like a hawk swooping down and carrying away an innocent field mouse basking in the morning sun. She would impale each out-of-bounds comment, question or answer, with her talons. She would always stop a tangent with a few canned phrases:

• “This is irrelevant to the Scrum. Let’s move-on!”
• “This is a round II discussion. Stay on after the call. Let’s move-on!”
• “This is irrelevant to the Scrum. Meet at ________’s cube after the call. Let’s move-on!”
• “This is something we need to address right now. Why don’t you drop off the call and _________. Let’s move on!”

You wouldn’t want her as your self-esteem coach, but she was ruthlessly effective.

She wasn’t the PM or the project owner. She wasn’t the Scrum Master. I don’t even know if the Hawk worked in the same group, but she was very good at ensuring this 20-member development team had a very efficient SCRUM that never lasted more than 15 minutes.

For comparison, I’ve had a lot of PMs who wait until a Scrum delivery is over and then add a nice, “Human Resources Approved!” comment, such as, “That’s interesting, Gary. Very interesting. Thanks for sharing.  Maybe we can discuss how difficult it is to sharpen your pencil given the sharpener’s proximity to the water cooler, after…”, only to be interrupted by Gary again, as Gary’s protest continued.

Needless to say, thirty more minutes passed, and umpteen people were still standing around, wondering how to account for a an unscheduled, hour-long meeting in the company time-tracker (hint: always choose “department meeting”).

Nomination vs Designation

Whatever you do, don’t “designate” the Hawk. The Hawk has to be “nominated”. Everyone already knows who the Hawk is on your team. The Hawk will have honed their craft over many years. The Hawk probably grew up in a home where the first question she asked about Santa at the age of 2 was met by her mother with a quick, dry, “There’s something I want you to share with your classmates about this Santa Claus fellow. Get a piece of paper, a pen, and prepare for a new lesson, Susie.”

You may have spent time with the Hawk. The Hawk is the same person who, after hearing the man at the checkout thinks he might need  to go out to his Subaru to find the coupon for the Fiber One bars that “probably fell between the console and the seat.”, promptly takes all of his items and puts them back in his cart.

Your Hawk was born and groomed for this one, dedicated role. The choice should be a natural one, instead of an appointed one. Remember, their role doesn’t matter. The Hawk can be the receptionist, a developer, a tester, or someone from another team. If someone made you cry for wasting time pushing the button for the elevator, or wrote a scathing email to your boss about how inefficient you are and copied you on the email; you have a potential front-runner.

Action Items:

1. If you don’t already  know who the Hawk is, set-up an online poll (hint: Google Docs allows you to set-up an online poll for free).
2. Choose 3 people who can dedicate 15 minutes to your team each day, whom you feel are the most ruthless, no-bullshit folks in your organization.
3. Ask your team to rank each nominee for their ruthlessness and efficiency.
4. The highest ranking nominee is your winner.

Step #2: Announce the Delta

If you’re running a Scrum, it should never last more than fifteen minutes. If every developer is on-topic, and the meeting still runs over the 15-minute limit, something is seriously wrong.  A Scrum that runs over 15-minutes is a symptom of a deeper problem.

Let’s talk for a minute about some of the issues that pop-up which delay a Scrum, and prevent the Scrum from being on-time and on-point.

Symptoms of the Artificial Scrum:

• You have more than one person per minute allocated to the Scrum
• Your questions and answers go off-topic
• There are too many jokes or there’s too much commentary
• You’re discussing technical issues
• You’re waiting on people to leave the shared conference room
• You’re waiting on people to show up before starting Scrum
• You’re holding up the Scrum because you didn’t log-in ahead of time
• The projector isn’t plugged in
• The screen-sharer isn’t sharing
• Some really nice developer is offering to help another really nice developer and they’re discussing how much help the other developer needs and when the right time would be to stop by and offer that help and no one wants to stop this type of feel-good-moment.
• Someone who clearly dialed into the Scrum has just spent 3 minutes on mute, reciting all of their accomplishments from the previous day

You should be proud of every single minute you saved your development team by keeping the Scrum on-point. If your Scrum is over 15 minutes, even by just a little, tiny bit, there’s something wrong with the team size, focus, or the moderator. As the Scrum Master, the delta is how you should measure your efficiency.

As the Scrum Master, you need to end each meeting by letting the team know exactly how many minutes the Scrum is under the 15-minute limit. You should be announcing the delta as if you have just climbed Mount Everest, because any delta shows that you ran an efficient Scrum, and it keeps you accountable on a daily basis to running a Scrum which allows the team to do actual work, instead of attending meetings.

Action Items:

1. Tell everyone the meeting is over
2. Subtract the total number of minutes (always round up to the whole minute) spent in the Scrum by the number 15. This is your delta.
3. At the end of every Scrum, tell everyone the delta (and do it with with some enthusiasm, because you’re proud of the efficiency you’ve bestowed upon your team).

Step #3: Move your Scrum online

When my clients hire me to do UI work, I’m only concerned about the server-side piece if we’re talking about stories that concern the work I’m doing on the UI. When I’m building an API for REST services, I’m only concerned about the UI developers waiting on me to finish my job, and perhaps someone else who is working on a story related to the work I’m doing.

If I’m performing a re-factoring of a Maven configuration, I’m not really concerned with the either the UI work or the REST API development, so Scrums are more of a hassle because I have to spend 14 minutes standing in a room, listening to people talk about stories that have nothing to do with my work at the moment.

The nice thing about an online Scrum is the work continuity. The team can continue to work, listening in on the very few developers, designers, testers, or analysts whose work is relevant to their own.

If your developers are actively working on tasks during Scrum, it doesn’t mean they’re disrespectful. It doesn’t mean they’re leaving the office each day and sticking pins into voo-doo dolls who eerily look like some of your staff. These developers are probably very engaged in the task they’re working on, and this makes for an interesting twist: if the developer arrives to Scrum engaged with the day’s tasks because he was just working on those tasks a few moments earlier, the developer knows what needs to be done, and it’s easier to get a feel for his frustration levels.

As a Project Manager or Scrum Master, listening to the emotion in someone’s voice helps you get a better sense on whether or not they have a handle on the issue, and you are then in a much better position to offer to send in a heavy-hitter. Likewise, developers are more likely to respond to raw emotion and they are more likely to offer up some assistance.

I’ve heard some very smart people ask for help in the middle of their Scrum delivery, when it’s clear based on their long, drawn out pauses that they’re actively coding and very confused. These calls for help only happened during the online Scrum. Once a developer or designer has left their workstation, the emotional engagement lessens and it’s harder to get a real feel for frustration levels or even enthusiasm.

The truth is, lots of people are good multi-taskers and you don’t have to be actively engaged during a Scrum since 90% of the conversation has very little impact on your tasks for the day. How often do you go to Thanksgiving dinner and watch everyone give their full attention to Aunt Judy as she discusses how difficult it is to find the right Gravy seasoning packets at the Save-Rite? People are half-listening as they scoop piles of Stuffing onto their plates which they’ll surely regret the next day, while they check their iPhones for the latest Celebrity news. Still, they hear everything mentioned at the dinner table. Aunt Judy isn’t being ignored. You can run a very effective online Scrum with developers actively working in the background.

Note: If you work in an open floor-plan, where you have constant distractions on your right, left and behind you, the online SCRUM is less effective because you can’t focus on the minutiae that leads to good decision making, and it’s the minutiae that matters. If you have a cube-farm or your company loves developers enough to actually invest in tall dividers or private offices, please contact me right away with a job description, salary range, benefits, and relocation package consider an online Scrum.

Action Items:

1. Sign up with a company offering online meeting software
2. Send an email letting everyone know the meeting is now online
3. Make sure developers can see their stories so each developer knows when his or her turn to speak is approaching

Step #5: Move Your Scrum to 11:30am

Problem 1: The Early-Morning Scrum adds to your employee’s stress levels

I try to be in the office at a reasonable hour, but all sorts of events happen in the morning that affect what time I arrive. I’ve got an old house. People often come over and say things like, “What wonderful charm this home has.” and “These built-in cabinets are just the kind of craftsmanship you don’t see anymore”. People with new homes say these kinds of things, because they have either owned an old home and want to remind you what a terrible mistake you made, or they are actually thinking about buying an old house because they are optimists who believe their contractor will one day send them a bill that is not the highest end of the original estimate. I have regular obstacles that stop me from getting to work at 9:00am, from home repairs, a hungry kid, a diaper gone terribly wrong, traffic, and the security guard stopping me to let me know someone stole homemade honey from Mark’s desk.

Then, when I sense we’re about to do a roll-call after I’ve just had a guy in a sports car with faded paint and double-dipped-chrome wheels traveling at 15mph yell at me for trying to merge into traffic, I’m not really myself just yet. I need some time to compose myself, so my coworkers don’t see me in the same way most of the Democratic party saw Howard Dean’s Iowa’s speech.

Problem 2: Your 9:00am Scrum stops your most focused employees from focusing

Some of the most productive people I’ve worked with get to the office well before everyone else. These are the people who get into work around 6:00am, 7:00am, or 8:00am. They beat all the traffic, they get to write code, uninterrupted with serious momentum, and then they leave at 3:00pm, missing traffic AGAIN. I envy these people, and I’m determined to become one of them when the kids have moved out of the house and on to to college, sometime around 2030.

When I have some momentum, I can get done in an hour or two, what might otherwise take me 8 hours to finish, and I figure most developers have a similar mentality. There’s a point in every developer’s day when they’re focused, hammering on the keyboard like Ben Folds in a live concert. During this moment, the boss is getting three developers for the price of one. They’re finally about to save some of that VC cash they’ve been burning through. They’re about to finally resolve that major bottleneck in the platform that has prevented them from moving into production for 3 months. Everyone get ready, because amazing things are about to happen and most people are still eating breakfast.

Instead, these developers are spending their morning looking down at the clock. They are nagged by the looming deadline of the early morning Scrum. They keep looking at the shifting minutes, thinking about the impending distraction. Their momentum grinds to a halt. They are now consumed by the inevitable obstacle fast approaching their most productive time: Scrum. The constant nagging prevents them from focusing. A non-developer might say, “They have three hours to do the work”, but the constant nagging in the back of their minds prevents them from ever being fully engaged.

And it’s not just me who thinks this nagging is a major obstacle. I recently read Willpower by Roy F Baumeister and John Tierney. The book’s premise is based on the idea that everyone has a finite quantity of Willpower. Different factors deplete your reserve of Willpower, and once it’s gone, it takes awhile to build back up. Willpower cites as a prime solution, David Allen’s Getting Things Done lecture series. The Getting Things Done Lecture Series helps people prioritize tasks and complete tasks, so they can avoid the constant nagging that prevents focus.

Think about how important Willpower is when it comes to getting a development task done. On an average day, I need Willpower to do more than write code. I need Willpower and discipline to ignore the barrage of emails I get asking me very important questions, like, “Can you complete a survey about your favorite reasons for working at our company?” and, “Do we need to buy any vegetarian meals for the lunch-and-learn next month?”

I need Willpower to avoid staring at the toasts that appear on the bottom right of my screen, announcing department-wide show-stoppers about Gretchen’s upcoming retirement party and Phil’s new twelve-pound baby. I need Willpower to keep focused on the IDE, and not the weird guy I’ve never seen at the office who doesn’t have a badge and is walking past my desk down a cubicle row where all of the other desks are unoccupied (should I call security?).

It’s hard enough to focus on the work you’re doing and to keep a reserve of metal stamina because of the constant distractions in the “modern” workplace. Having an additional distraction, where you’re forced to watch the clock and are nagged by the constant reminder of an approaching cold-hard-stop is a major problem. If you, as a developer is suddenly making major progress with the kind of momentum and velocity that makes you feel like a Super-hero, the kind of productivity that will last an hour or two at best, and then disappear for days or weeks, your kryptonite is the 9:00am Scrum and it’s abrupt halt to your fluid workflow.

Problem 3:  No one knows what stories they’re really working on until 10:30am

The day before, I was probably working on five different tasks. I may have one story assigned to me, about “User Authentication”, but I was honestly working on helping Gary fix an issue with the build configuration, or I may be helping Susan look into an issue with the session timing out too soon, but I don’t know what I’m really going to be working on the second Scrum begins.

Gary may need me to look into the issue with the build again, or I may be asked to go to a meeting with Susan to look at the authentication problems. By 10:30am, I have a better understanding of the most pressing issues I’m facing, and the issues my team is facing.

If you want to plan a Scrum effectively so other developers can pick-up stories that are more pressing than others, as people move around based on changing needs, it’s easier if you provide enough breathing room to let the real problems organically present themselves.

Problem 4: The Escape Hatch is the lowest common denominator for when to Swarm

First, we need to discuss how you point your stories. If you’re pointing a user story above 3 points for anyone but the Principal Architect who has worked on the system since the first line of code was written, you’re doing it wrong. Stories should rarely be pointed above 3 points, because it becomes too difficult to create granular tasks for a story beyond the three-pointer. I’ve seen a lot of companies write user stories without developer input. For example, the developers aren’t allowed to modify user stories created by the business, they can’t add user stories, and the task estimates are done solely by the PM. The most effective teams I’ve worked on, the ones with 100% coverage and a defect log that looks like a shopping list for 7-11, are the ones who have maximized their developer involvement and input, and the developers own their stories, through and through.

That being said, when I own a story, I’ve estimated the tasks without anyone questioning those steps I’ve outlined. I feel responsible for getting each task done. Between the time I get to work and the 11:30am Scrum, I feel I have a window to finish a small granular task. I never estimate a task above 4 hours, and if someone does estimate the task above 4 hours, you can obviously break it down into smaller components. If a 4-hour task is stuck in limbo for a couple days in a row, I start to look at the Escape Hatch as the one additional chance I have to make progress and complete a step. There are a few moments in each Sprint when developers get stuck, and when it happens to me, I’m in the moment between the time I get to work and the 11:30 Scrum time. That’s when I don’t take phone calls, I’m not opening my favorite car blog memorizing APIs. I’m in the zone, and I’m giving the task my all. If I can’t complete a task after two days and one major effort at blowing through the Escape Hatch, then I’m ready for some pair-programming, swarming, or story swapping.

The escape hatch, for properly pointed stories and tasks, is the single most  important milestone in helping to determine if a developer can finish a task.

Problem 5: Swarming is easier after lunch

Each time I attend a Scrum and hear that someone is stuck on a task, I wait to see if the Scrum Master is going to ask if the developer needs help. In the right environments, most developers are willing to say “Yes”, or the Scrum Master just assigns someone to help after a few missed deadlines. There’s always an awkward tension when someone is stuck on a task, and I think most fiercely independent developers would rather solve the problem themselves. That’s why, when a developer is stuck on a task and the Scrum Master decides to assign someone to assist, lunch-time is a nice chance to step away from the problem, take a deep breath, think about where you are, what went wrong in either the development, the pointing of the story or task, or the communication between teammates, and then to prepare a short, succinct summary of the problem for the person coming to assist in an hour and a half.

If you have SCRUM at 11:30 and take a pulse of the project, and decide to Swarm on tasks after lunch, then there’s a break when important events unfold.

Some developers are going to resent saying, “I couldn’t finish my task”, and then having someone show up in their cubicle eight minutes and twelve seconds later. The lunch-time delay is a chance to cool-off and to accept that someone is coming over to help you work through the problem. Over lunch, ego subsides and it’s a nice chance to change frame of reference for who is responsible for working through the task, or to prepare for a collaborative solution.

Next, the lunch-time gap provides a chance to prepare an explanation of the problem for the developer coming to assist. The task owner can study the problem a little more, and understand the mechanisms which take place, what the outcome is supposed to be, and the delta between the two.

Lastly, when I know people are going to swarm on my story or task, I’ll usually begin a massive clean-up. I’ll start refactoring code based on my knowledge of the problem, quickly trying to convince anyone headed to my desk that I was working on something so organized and orderly, that I probably lost most of my time to over-engineering the solution, making the underlying logic easier to understand through better naming conventions and organization.

Action Items:

1. Open email client
2. Change time of meeting to 11:30am
3. Select “Yes” when prompted to update all occurrences

Step #6: Keep the vocabulary limited

If you’re the Scrum Master, you have one job: To steer the entire Scrum toward a logical ending.

Each person on the team should know what to expect from one another, the Scrum Master, and himself or herself. They should be prepared to deliver a one minute summary of their status because the Scrum repertoire is familiar, and any deviation from the normal range of questions contains language that is familiar.

To keep the meeting focused and razor-sharp, your Scrum needs a vocabulary that is simple and familiar. Anyone new to the team should be able to pick-up on the new language after a week or two. Developers, designers, testers and analysts should feel comfortable knowing the boundaries of questions they may or may not be prompted with when it’s their turn to speak.

Limit your questions to known constants. When you ask questions, don’t deviate from a few canned questions. Otherwise, you risk your team becoming confused by the different types of answers seemingly similar (but very different) questions might ask.

For example, there are multiple ways to ask the same question. You might ask:

• Is this task done?
• What is the status on this task?
• Where is this task in terms of completion?
• What’s the ETA on this task?
• When is this task going to be done?

A Scrum Master might use each of the questions above to try and figure out if a Task is going to close, to gauge if the story is going to close before the end of the Sprint. However, each of the above questions has a different implication and it’s inferred differently by each person on the team.

Q: Is this task done?

This type of question is often asked in a Scrum in lieu of, “This task had an hourly estimate of 4 hours and you’ve had 4 hours, so it surely must be complete and you didn’t update the story board”.

Q: What is the status on this task?

This type of question is open to more interpretation than any other. The word “status” could easily be interpreted to mean, “is it being worked on”, to which, the answer is almost invariably going to be, “Yes. Yes it is being worked on [It’s being worked on as I sit in the pool with a beer in my hand and think about the task number]”. Questions about “Status” are very subjective, and they don’t provide anyone with a a clear understanding of the question or progress being made. So the answer is often:

Look at the vocabulary for the questions you ask during the Scrum, and limit those questions to the ones that are effective in terms of clearly communicating what is expected in terms of an answer. Then, once a question works, don’t deviate from the question. Make it a boiler-plate question.

Action Items:

1. Using an old-fashioned pen and paper, write down a range of questions and responses regarding stories and tasks
2. Over 45 days, add, subtract and refine the questions and responses

Step #7: Focus your language on progress, not completion

The great thing about Agile is that you, as the Project Manager, have a chance to take the pulse on the overall project regularly. You get a chance to look at the progress each developer is making with their stories, by getting a snapshot through task progress. However, your frame-of-reference for success should never be the completion of a task or story, but rather, if your team is moving toward the project’s overall completion?

Years ago, I used to workout at a gym. I went to the gym regularly and I did a pretty aggressive workout, going from machine to machine without any pauses. After 40 minutes, I left. Each time I left, the trainer at the counter would always make a snide comment such as, “That’s it? You’re done already?”

15 years later, I haven’t forgotten the snide comments, because they ignored certain realities. I was eating well, riding my bike for an hour at lunch (up a hill), and then going to the gym in the evening. I lived across the street, so I would walk to the gym, so I didn’t change or shower in the locker-room. And more importantly, I lost 30lbs, but it wasn’t due to a single activity. It was a combination of activities and discipline that brought about the overall goal.

When it comes to understanding the bigger picture (getting the project done), it’s important to focus on how each task, story and sprint affects the project goal. When you focus your questions on progress, and not completion, it’s easier for you, and your teammates, to take the emotion of ‘failure’ or ‘insufficiency’ when the developer’s delivery begins.

If a developer is asked about a task with an impediment no one saw coming (a daily occurrence), it’s easier to explain the task’s progress relative to the impediment, instead of the task’s overall state of completion.

You should never ask questions which suggest you measure the success of a story by the completion of each task. Why? Because, how you view success dictates the language you use, and the language you use plays a crucial role in how your team views their contributions.

Repercussions are long-lasting

If your team believes you only value completion, then they’re going to take short-cuts which you will pay for in technical-debt. Even if you make it into production with Spaghetti-code, it is hard to attract and retain talent with undesirable code-bases that prevent learning opportunities, pride of ownership, pride of participation, and regular work-hours.

You want each individual to know their contributions are valued based on quality and collaboration.

There are infinite variables that prevent tasks and stories from closing. Often times, new-hires and overly zealous developers try too hard to give an hourly estimate that seems inline with other time estimates. Developers without experience writing Unit Tests may give a time estimate that suggests they’ll come up to speed mocking objects very quickly, which is never the case. Developers without domain knowledge might give a time estimate as if they have domain knowledge, because no one likes looking slow.

Still, you must focus on the bigger picture.

Keeping in mind your new found frame of reference for “success”, let’s talk about all the ways you can keep “progress” moving forward.

You can:

• swarm a task
• swarm a story
• designate someone to help pair-program a task
• swap tasks
• swap stories

As a PM, you aren’t beholden to any one developer completing a given assignment (unless, of course, you have a team of one developer, in which case, treat that person very, very nicely). Your Scrum can and should be devoted to understanding if developers are progressing on their stories.

When you’re stressed out and worried, remember, you have options to keep development moving forward. Your diction should reflect such options.

Step #9 Developers should never work on Scrum outside of Scrum

1. Ensure the first 2 people have updated their tasks before the Scrum by sending out an email on a person-by-person basis (if you’re sending out a team-email and distracting 12 people because 2 haven’t updated their tasks and hours, you’re distracting and confusing about twelve people).
2. Ask everyone else to start updating their tasks at the start of the Scrum. If you expect your team to spend time working on updating their tasks, their hours, their stories, and to track their hours after the Scrum, your team is going to be spending a lot of time interrupted with management tasks. A good manager always tries to spare people from doing jobs that aren’t part of their job description.

Closing Thoughts

As my time at Company D came to a close, I commented to someone how much I admired their Scrum process and culture. The person I was speaking with said to me, “It wasn’t always like this. It used to be much worse.”

What they provided was an office environment which was a pleasant place to be; where you knew the code you wrote had been reviewed and revised so often, it had a stamp of approval by a larger group. Code was well mocked and unit-tested, and you slept well knowing you didn’t risk an elevation with a critical flaw. The culture was one where hostilities didn’t bubble to the surface, people worked normal hours, and their morale was high and employee attrition was low.

I wish I knew what mechanisms were involved in their refinement and presumably, their culture change. It may have been a new manager, it may have been a new team lead, or it may have been a long, slow, gradual change instead of a single catalyst. It may have started with the Scrum, or the Scrum may have been itself, a product of refinement.

Creating an altogether better organization probably requires a lot more than a Perfect Scrum, but it’s a good place to start.

The post The Scrum Master’s Guide to a Better Scrum appeared first on David Buhler.