What Four Months Without Electricity Can Teach Us about Agile

On September 20, 2017, Hurricane Maria made landfall in Puerto Rico as a category 4 hurricane. It has been called the worst natural disaster ever to hit Puerto Rico. Six months later, over 100,000 utility customers don’t have electricity, and over 17,000 utility customers still don’t have running water. (I was fortunate to have my power restored in February, just shy of the five-month mark.)

But, as always, there are positive things we can learn from this disaster. Some of them can even be applied to agile development. I would like to share them with you.

Preparation is essential

During the days immediately following the hurricane, there was an extreme shortage of food, potable water, and fuel. I saw a line more than half a mile (0.8 kilometers) long at one gas station. Many people desperately awaited supplies from the government, some of which had to be delivered by air because the roads were impassable. But there were also people who managed to make do for a few weeks while the situation stabilized. They were, in large part, people who had stored at least a short-term emergency supply of food, water, and other essentials in their homes because they knew that someday they might need them.

A core tenet of agile is that we expect and embrace change. We know that things will change before we finish a project, even though we don’t know exactly what or how or when. And although this ambiguity might not allow us to make detailed plans for more than a few weeks out, we can prepare for those inevitable changes by doing things like the following:

  • Delaying major decisions until the last responsible moment to avoid being locked into a design that can’t accommodate new requirements
  • Monitoring our team’s velocity or throughput to know whether we will be able to handle a sudden surge of work
  • Getting feedback early and often from our stakeholders in order to minimize the amount of rework needed when requirements change
  • Not setting unrealistic expectations by committing to a project that has a fixed schedule, scope, and cost

Doing those things might not provide an immediate benefit. They might even feel like unnecessary work or impediments to good relationships with stakeholders, just like putting away a little extra food and water might seem pointless at the time. But when the storm — or changes in requirements — comes, you will be glad you did.

You are more flexible and adaptable than you think

While running water was restored, many people resorted to washing laundry by hand and using rainwater for flushing or bathing. I put together a few PVC pipes to redirect rainwater from a roof gutter to the window above my shower. (Friendly advice: It’s a good idea to add a valve so your bathtub doesn’t overflow if it starts raining when you’re not at home.) Those who could run their refrigerator with a power generator for a few hours a day had to be careful not to open the refrigerator too often while it was turned off in order to keep the cold air inside. We all had to make adjustments, but we figured things out and got through it.

During one of my first projects as an inexperienced developer, I was struggling with loading some data sets into a database. My team lead told me that there were many ways of doing it and that I should “push the envelope.” I couldn’t see many ways of doing it at the time. But bit by bit, even after the project ended, I realized he was right. And I am sure that whatever difficult requirements you have in your own projects, there is at least one way (and probably more) to meet them, and you can figure it out.

One of the beautiful things about software development is that you are dealing with, as Fred Brooks put it in The Mythical Man-Month, “nearly pure thoughtstuff.” We talk about “building” applications, but we’re really just moving bytes around that are almost infinitely malleable. Whatever requirement you are dealing with, there is almost always a way to do it. The solution to the requirement might not always be elegant or efficient. It might be throwaway code that no one will ever use again a month from now. But when changes and challenges inevitably come, trust in your ability to adapt and find creative solutions.

And, above all, focus on solving the customer’s problem rather than making sure the solution fits some pattern or best practice. Did I like taking a shower with yellow water that left me itchy? Would I recommend it as a best practice to anyone? No. But I was able to take a bath, and that was the important thing.

Resources are of little use without a plan

This is related to the “Preparation is essential” point above. For several years before the hurricane, I had been stocking up on what I thought were essential items. I had loads of pasta, rice, canned food, and hygiene items. But soon after the storm, I realized I had overlooked one simple, critical thing: water. I had enough water stored for drinking, but I had not considered the water required for cooking and washing kitchen utensils as well. I had a barrel of water in my yard that collected rainwater from a gutter, but that water was greenish, moldy, and probably had bugs in it. Useful for flushing the toilet, but not safe for human consumption. I tried filtering it with kitchen rags like the survivalists say, but all I ended up with was green water and wet kitchen rags. If I had done more thorough planning, and even practiced living off my storage for a few days, I would have realized what I was missing and could have prepared better.

Due to our focus on “responding to change over following a plan,” agile has been accused of not planning enough. We cannot allow that misconception to be true in our teams. We cannot just improvise our way through a project because we think we have talented developers or because agile says so. Planning is how you ensure that you have the right resources — whether it be information, developers, development tools, anything you need to be able to do your work — before you use them. Planning is how you mitigate risks. It is what lets you be proactive even in a changing environment.

Of course, we won’t try to make detailed plans about requirements a year ahead of time, just like I won’t plan today which box of matches I will use when the next hurricane hits. But I will plan based on what I know, on reasonable assumptions about the future, and on information I receive from subject matter experts like meteorologists. We need to do the same thing in our development teams and with our customers. (Except that your subject matter experts probably aren’t meteorologists. But if they are, that’s awesome and I would love to hear about it.)

 

If you follow these principles, you and your team will be in better shape to face whatever challenges, weather-related or otherwise, that you encounter.

My life is mostly back to normal, but many people are still struggling with the consequences of Hurricane Maria. If you would like to help, you can donate here. The donation is tax-deductible in the United States.

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 ProjectManagement.com 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.