Scrum Masters: Don’t Tell Development Teams How to Do Tech Work

My latest blog post for agile training provider Front Row Agile: “Scrum Masters: Don’t Tell Development Teams How to Do Tech Work.”

The Scrum Guide states that “no one (not even the Scrum Master) tells the development team how to turn product backlog into increments of potentially releasable functionality.” There is a good reason for this: The developers are the ones closest to the code, and are usually in a better position than the Scrum Master to understand what low-level decisions should be made and why. […]

This can be a challenge when the Scrum Master is in a hybrid role that requires being at least somewhat hands-on technically…

Read the whole thing on the Front Row Agile blog, and leave a comment.

Part of a Scrum Master’s Job is to Lose It

My latest blog post for agile training provider Front Row Agile: “Part of a Scrum Master’s Job is to Lose It.”

The Scrum Guide states that one of the Scrum Master’s responsibilities is to “[coach] the development team in self-organization and cross-functionality.” Implicit in this statement is the notion that a Scrum Master should work him or herself out of a job. […]

Of the three roles in a Scrum team, arguably the one you could most easily do without is the Scrum Master…

Read the whole thing on the Front Row Agile blog.

Don’t Skip Your Recommended Daily Dose of Scrum

I am happy to announce my first blog post for agile training provider Front Row Agile: “Don’t Skip Your Recommended Daily Dose of Scrum.”

Daily scrums are like food: they play a vital role in keeping your team’s development process healthy. But, for some people, the daily scrum is an acquired taste. Sometimes it can feel burdensome, unnecessary or un-delicious, and you would rather skip it altogether. Resist the temptation.

Here are some objections you might hear from developers, product owners or even management regarding the daily scrum. Perhaps you have even felt this way yourself…

Read the whole thing on the Front Row Agile blog.

Just Say No… To Customer Satisfaction?

Most of us genuinely care about doing quality work and want our customers to be satisfied with our work. When we receive customer requests that are questionable or even ill-advised, we are usually not happy about having to sacrifice craftsmanship for customer satisfaction. But as agile practitioners who strive for customer satisfaction, we can offer our opinion and feedback, but at the end of the day we need to deliver what the customer wants. Right? Or are there times when flat-out saying no is the right thing to do?

My company maintains a complex stack of applications, and the dependencies between layers sometimes leads to bickering between teams over who is responsible for implementing X or Y functionality. Our team was recently asked about making a change in our application to accommodate a certain quirk in one of the lower layers. Normally, we would just grumble about cleaning up another team’s mess and get on with our lives. But this particular quirk wasn’t just inconvenient, it was non-compliant with an industry specification, and our external customers would notice. Implementing a workaround at our level of the stack would have left our customers with a defective product and a long release cycle to wait before they could receive a fix. And less importantly, but still relevant, that workaround meant adding unnecessary cruft to our application that would increase the maintenance burden on our team.

I felt that was unacceptable and firmly explained to the product owner why the defect should be fixed at the source instead of asking us to implement a workaround. When he brought up the workaround again, I explained it again. When he tried to justify the workaround, I explained it again. And a few days later, the product owner told me that the other team had accepted responsibility for the defect and would be handling it.

Even though the very first principle behind the Agile Manifesto says that “our highest priority is to satisfy the customer,” we need to remember that that is not our only priority. Or put another way, sometimes you need to consider customers beyond the immediate ones whom you deliver software to. Sometimes pushing back on a request, even if it was properly channeled through the product owner, is the best thing to do.

Now, I’m not saying that challenging your product owner should become your usual way of interacting with them. There should be far more collaboration than clashing within a scrum team. But knowing when to step outside the lines a little bit is, itself, an agile virtue. And I believe that being able to make those (hopefully infrequent) calls is one of the things that separates those who strictly follow agile “rules” from those who are truly agile.

Scrum Master Wanted: Competence Not Required?

A recent thread at Workplace Stack Exchange about managing developers who are more talented than you contains a comment that neatly sums up how to lead subject matter experts:

You don’t even need to be competent, as long as you listen to competent developers and don’t claim to know better.

I have written previously about being careful not to get stuck in your previous mentality as an individual technical contributor. Technical skill is often one of the factors considered when deciding whom to appoint as a team lead, and it is tempting to act like your leadership in scrum is still based on technical merit. But what happens when you’re assigned to lead people who are much, much better at something than you are (like at my current job)?

In scrum, this is a non-issue. The Scrum Guide clearly says,

No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality

Their skill level in relation to yours is completely irrelevant. A large part of your job is to foster a work environment where the development team can do their best work. You do this by listening to the developers’ needs and then working to remove any obstacle that keeps those needs from being met. Your ability to do that is not principally determined by your knowledge of object-oriented programming or web services.

Does that mean that a scrum master is not allowed to talk shop with the developers? Not at all. But if you’re going to talk with them in technical terms, and the developers really are in a different league than you in terms of skill, then you need to realize that almost any technical conversation you have with them will be for your own benefit more than theirs. One could argue that you are wasting their time by doing so. Be appreciative when they take a few minutes to explain something to you.

It is always helpful for a leader to have some understanding of the work done by those he leads. It increases your empathy with them, which helps you understand their challenges and what needs to be done to resolve them. But being good at what the developers do is not required (maybe it’s not even a significant plus) as a scrum master. I continue to be humbled in my job as I keep realizing how little my technical background actually matters. As we more deeply internalize the fact that our job is to help others do their job, any arrogance or intimidation we feel from comparing our technical skills with theirs will be replaced by the security that we are providing far more value to the organization by making their job easier than by trying to do it ourselves.

Why “Don’t you Have Anything Better to Do?” Should Be Your Mantra

As agile practitioners, we need to focus not just on delivering value, but on delivering the most value we can within a given time frame. But precisely defining “value” can be challenging because what a person considers to be valuable might depend on their job title, social status, time of the year, and many other variables. Identifying that value, and then working relentlessly to deliver software that meets the customer’s current definition of value, is at the core of agile development. The Agile Manifesto mentions several processes and artifacts in software development, and divides them into two short lists: those that have value, and those that have more value. (If you haven’t read the Agile Manifesto, go read it now. It will take you 15 seconds.) This means decisions need to be made between what we can do and we should do.

It took me some time to realize this. I remember telling my boss when I was a new scrum master (-slash-product-owner) that we had a large backlog for several applications. My thinking was that if an item was on the backlog, it should get done at some point. He said that we should work on those items if there was value in them. Another time, we had scheduled time during the sprint to develop a custom module for an open source application that we used. This was a nice-to-have, but far less valuable to our customers than most of the other items we had in our backlog. My boss quickly shot that down and said we should only work on that kind of thing if we had nothing else to do. I resented his “meddling” both times, but eventually realized that he was right.

We generally use the phrase, “Don’t you have anything better to do?” as a way of blowing someone off. But in agile development, that should be our guiding mantra every day. It is another way of asking, “Is this the most valuable task I can be working on right now? Am I doing this just to feel the satisfaction of checking off an item on the list, or am I doing this because it is what the customer most wants to see in the next release? When I am done with this feature, will the customer be disappointed that I wasn’t working on a different one instead?”

So every day, ask yourself, “Don’t you have anything better to do?” Encourage the team members to ask themselves that. It will help them hold themselves accountable. And don’t be offended when they ask you that question, because it will help you remain focused on customer value as well.

A Scrum Master in Hand is Worth Several Other Roles in the Bush

Conventional wisdom says that a scrum master should not also be a product owner because the inherent tension between the two roles leads to a conflict of interest. Being a scrum master and a developer at the same time is at least implicitly acceptable, as the Scrum Guide says that scrum masters are not included in the development team’s head count “unless they are also executing the work of the Sprint Backlog.” Being a scrum master and a traditional project manager at the same time seems to be somewhat common in organizations that still have one foot in waterfall, and Sally Bommen has an article at where she shares her experience in that dual role. But a scrum master that develops, owns, and manages?

I have written previously about how my technical background has been both an asset and an obstacle to being an effective scrum master. I tried to keep both my developer hat and my scrum master hat on. Since not all of our applications have a dedicated product owner in the business, I was asked to take on that role as well. And since our organization is still fairly waterfallish, I get to produce slide decks and charts like a traditional project manager. (Oh, and most of the data that feed the charts come from a data mart that I implemented. Dev hat.)

I don’t resent being in this multifaceted position. It’s educational and mostly fun to wear all the different hats. But it does have real drawbacks. As a jack-of-all-trades, you don’t have the time to really master any one of those roles, and it’s difficult to really understand the history and future of any of the applications you semi-own. You end up fulfilling all those roles well enough to keep the fires under control, but you’re not a rock star at any of them, and it is difficult to drive real improvement in any one area. Maybe even worse than that, carrying such a combination of roles also leaves the team unclear as to which methodology they should be following. It is easy to have friction if, for example, you tell the team to be self-organizing but you keep trying to direct the work. And anything that hurts team cohesion needs to be fixed quickly to keep avoid hurting the products’ quality.

I’m not providing any real new insight here, just reaffirming that trying to do too much leads to less-than-stellar performance in any of those areas. A scrum master in hand is worth a development team/PO/PM in the bush. Worth how much? That’s for you and your organization to decide. But resist the temptation to give one person, perhaps yourself, too many hats. It’s not a good look for you, and it’s not the best way to grow an agile culture.

Don’t Let Your Technical Background Hurt You as a Scrum Master

It took me over a year after I became a scrum master to learn to stop making technical decisions. (I still do it sometimes.) This is a common pitfall for former individual contributors who are placed in a leadership position: they focus too much on what they used to do as individual contributors, and not enough on the big picture. It’s natural — that’s what you spent years doing and perfecting, and what you feel most comfortable with — but that doesn’t mean it’s right. Especially in a framework like scrum, where the team members’ roles are specifically designed to keep them from overstepping their bounds with one another.

One of the teams I worked with had a project that involved a lot of Python. Despite my having only a few months of experience in that programming language, it was still more than the rest of the team had and I was excited at being able to contribute my knowledge. I pushed for coding standards, participated in code reviews, discussed how the documentation should look, debated the use of third-party modules, encouraged the use of Git over SVN, and tried to understand in detail what the developers were working on. I felt proud of myself for providing some of the technical leadership on the project.

Then one day, an issue I had raised in a code review was rejected.  Had I been more familiar with the code, I wouldn’t have incorrectly pointed out what was really not an issue at all. Then it happened again. I found myself flip-flopping on dependency management because I didn’t fully understand the ecosystem the library would be used in. I started asking more “how” and “why” questions. There began to be some friction between the senior developer and me. My technical advice soon began reaching its limit, even though there was plenty of work left to do on the project. I started to get self-conscious and wondered if I was making a fool out of myself. (The team was nice enough not to say so directly, but I’m sure I did.)

My technical participation did have some benefits, but I insisted on continuing to do it even when it should have been clear that there were diminishing returns. I was not adequately fulfilling my role as a scrum master because, even though I was helping the team to create a high-value product, I was telling them how they should do it instead of letting them self-organize and decide on their own. And even worse, I did not have the necessary knowledge to continue providing useful guidance more than a few months into the project. A better way to help the team would have been to organize an overview of some practices I thought would be valuable and then let them decide if/how they wanted to adopt them, rather than practically dictating how they should do things. This would have allowed them to be more self-organizing, and possibly increased their sense of ownership and accountability for their work. I’m sure you can think of other ways that I could have handled those interactions better.

A lot of scrum masters come from a development background. They bring knowledge and experience that can help their teams produce high-value software. But as scrum masters, we need to remember that our role is not one of technical leadership, but of servant-leadership. Our mindset must shift from helping the team to helping them help themselves. Keeping this in mind and acting accordingly with our teams will help them do better work and foster a better working relationship with them, as we “respect each other to be capable, independent people.”

Being Transparent with our Customers Is Like Getting a Haircut

Scrum relies on transparency. All parties must be able to see what is being currently worked on and, as far as the product backlog is defined, what other work is planned for the future. Any decrease in transparency decreases the customer’s ability to inspect the product and adapt it to changing conditions (e.g. market demand), and can lead to diminished trust between the team and the customer. Transparency can be an intimidating concept for some people, perhaps because they are afraid that their mistakes or any hidden agendas will be exposed. But that is precisely why transparency is so critical to a culture of continuous improvement: you cannot improve what you cannot measure, and you cannot measure what you cannot see.

Think of a situation where you might get frustrated while waiting for something, like waiting for a meal at a restaurant. In that case, part of the frustration probably comes from not being able to see the work that is taking place. You know that something is happening — you know the chef must be mixing some ingredient with another, or perhaps the chef is still working on the previous customer’s order and hasn’t started on yours, or any number of other things — but you do not have any more detailed information than that.

Contrast that with how you feel while waiting for your barber or hairdresser to finish your haircut. You can see in real-time which part of your head is being cut, how your cut is looking so far, and you have a fair idea of how much is still left to do. If at any point during the haircut you change your mind about how you want your neckline to look or you remember that you wanted your sideburns a little higher, you can ask the barber to make the adjustments right there. The sense of frustration while waiting for the haircut is greatly diminished and you might actually be willing to wait a little longer so the barber can get your look just right, as you requested.

What is the difference between those two cases? The amount of transparency in the work that is being done. When the work is a black box that you can’t understand or control, it is easy to feel frustrated and even helpless. But when you can see the individual steps that are being taken to carry out your request, and you have a say in how they are done (to a certain extent; you wouldn’t tell your barber which scissors to use, because that’s his domain of knowledge and not yours), you feel more comfortable with the process and are more likely to be satisfied with the final outcome.

That is the importance of transparency in scrum. Our ability to interact and collaborate with our customers, and respond to changes in their needs, depends largely on how transparent we are with them regarding the work we are doing. That transparency can be achieved in many different ways: burndown charts, kanban boards, letting stakeholders listen in on our daily scrums, traditional status meetings, and other methods. As we strive to maintain a high level of transparency, we should remember (and teach our teams) that doing so is critical not only to our customers’ success, but to our own.

Just Calling it Agile Doesn’t Make it Agile’s Scrum Open Assessment includes a question on what would happen if an organization tries to adopt scrum processes without changing their traditional terminology. One correct answer is that management may feel less anxious. While I don’t doubt this is true, my experience suggests that the converse is also true: management will feel less anxious if they start using agile terminology but do not change their processes accordingly. This can leave the teams in limbo as to which methodology they should follow, and lead management to believe that the organization is practicing agile when it really isn’t.

I once attended a meeting with other scrum masters where we were told that management wanted us to sync up on how we were going to do estimates; e.g. whether we would all be using the Fibonacci sequence. It seemed that management wanted to be able to compare apples to apples when viewing charts for the different teams’ work. This would be a sensible request if we used absolute time units like hours or developer-days to estimate work, but story points are a relative unit of measurement with a completely arbitrary scale. The definition of what a story point represents is unique to each team, so point comparisons between teams are useless at best and misleading at worst. The managers’ request also did not take into consideration alternative sizing methods like t-shirt sizing, which are not number-based and would be an even worse idea to try to compare with another team’s story points.

This is an example of management’s trying to shoehorn the traditional way of doing things into agile terminology. Without a proper understanding of how estimates and velocity work, as was the case above, it is easy for them to think that the traditional way of generating and reading metrics, and comparing performance across teams, will continue to work in an agile environment. This reveals a gap in their understanding that we, as agile practitioners, have the responsibility to address. Even though the final decision on how to run the organization is not ours, if we do not give managers correct information on how agile processes work and why, then we become part of a problem that could lead to disillusionment with agile and make it harder for the organization to reap its benefits, thus decreasing or removing value from the organization instead of adding it. In this case, we needed to help them understand that comparing estimates across teams is an apples-to-oranges comparison, and that’s okay.

More broadly, managers need to understand that agile adoption will change not only the developers’ way of doing work, but also theirs. And they need to be at least cautiously comfortable with that. Agile development is a very different paradigm than what many companies were built upon, and it requires a correspondingly large change in managers’ mindsets for it to be executed properly. As we patiently and clearly explain agile principles to decision-makers in our organizations, we will be more likely to gain their support for the change. And even if we don’t, we will still have added value to the organization by helping them make the most informed decision they can.