Dan Devlin arrived at the coffee shop an hour before his appointment with Kate. He had email to do, and he wanted to be sure he was there when Kate arrived. Dan got his coffee, selected an out of the way table, and moved one of the chairs away to make room for Kate’s wheelchair. Then he set to work. About fifteen minutes before Kate was due to arrive, Dan made a quick pit stop and went to the counter for a refill. Glancing over at the table, he saw Kate, sitting there, smiling and giving him a wave. He pointed at the barista to see if Kate wanted something, and she pointed at the iced drink already in front of her.

Returning to the table, Dan greeted Kate and asked her “How do you do that?”

“Do what,” Kate said.

“Always arrive at meetings without anyone seeing you coming and going. And with your drink, even!”

“Well, I don’t always do that. I guess sometimes people just aren’t very observant, though with my red hair, robust figure, and sparkling attitude, you’d think I’d be hard to miss. Maybe I’m part ninja.”

“Robust, is that what you call it? Anyway you’re not my usual image of a ninja,” Dan said.

Kate laughed. “Some kind of bust, anyway. Thing is, I’m in disguise. What good is it to be a ninja if you look like a ninja?”

The chat continued for a while. Then Dan got down to business. “Kate, you’re doing a wonderful job at Oak River. Things are turned around there, and I’ve been able to put most of my attention on other matters. One of those is that I’m looking at acquiring another company in our line of work. They have a good customer base, but haven’t released much at all in over a year. I’m thinking a bit of your magic might help them out.”

Kate said, “It’s not magic, but it might help. I think what we’re doing will help any organization that does what we do. And, by the way, it won’t help anyone who doesn’t do it, the same way that a diet won’t help people lose weight if they don’t live by it.”

“That makes sense,” Dan said.

“You’d think so. But I read every day about teams who say these things won’t work, but have never really tried them. I wonder how they know.”

“What are you doing, anyway, Kate? Is it Scrum? What is Scrum, anyway?”

Kate took a sip of her drink and thought a moment. “We’re doing something like Scrum, which I’ll describe. Let’s start with what Scrum is. I’ll blather on a bit but feel free to stop me with questions if you need to.

“Scrum is a framework, a way for people to work, a style, you might say, for building products. I think of it as a beginning, a good starting point for building something. If a team will start with Scrum, and pay attention, they’ll see the things that are in their way and be in a position to improve. Naturally, some of the things that are in a team’s way are outside their direct control, and in those cases, management and the organization have to be responsible for removing what Scrum calls the ‘impediments’ that are in the way.

“There are just three ‘roles’ in Scrum: the Product Owner, who determines what the team will build in the next short interval or ‘Sprint’; the Team, who build it; and the Scrum Master, who facilitates the process and makes sure that the process, and the people, continually improve. There are four meetings, Sprint Planning, Sprint Demo, Sprint Retrospective, and Daily Scrum. And there are just three artifacts, the Product Backlog, the Sprint Backlog, and the Increment.”

Dan said, “So the Scrum Master is the manager, and the Product Owner is an analyst?”

“No,” Kate said, “Not at all.

“In a Scrum project, the Product Owner is responsible for delivering the best possible product within time and budget. The team builds what she says to build, and her job is to get the best possible results. She can do this because the team shows her real running product every Sprint. That is, every couple of weeks, thirty days at most. She’s in a good position to see how fast things are going, and to make the big decisions as well as the smaller ones.”

“So the Product Owner is the manager, then,” Dan said.

“No, Kate said, “Not at all. In fact, a Scrum team need not have a manager at all. In Scrum, the team is ‘self-organizing’. To as large a degree as possible, they manage themselves. Naturally, in large companies, or companies with a lot of ‘managers’ running around, it is common for a Scrum team to have a manager. Frankly, this is often harmful and it is a common cause of Scrum not working very well.”

“But who decides things,” said Dan. “Who decides who to hire and fire, how much to pay people? Who disciplines the bad people and encourages the good ones?”

Kate smiled. “Good questions, and questions that Scrum really does not want to answer. Yes, in a real organization, there will be some connection to personnel, to some kind of technical management, and so on. Scrum, to me, is defined as if those things were not needed, or as if the team could do all those things. What’s interesting, of course, is that in a startup situation, the team really can do all those things. What was it like when you started Oak River Software?”

Dan thought back. “Well, I made some final decisions about hiring and firing. Certainly I set the budget, because it was my money. But mostly, Art Givens, who was my marketing and domain guy back then, decided what we needed to do. And I had a lead developer who decided who to hire and fire, within budget. I’d counsel with him when there were issues, and I often had to get involved because his people skills weren’t the best. But we didn’t do a lot of what I’d really call management. We worked together, figured out what had to be done, and did it.”

Dan paused. “You know, maybe this is the entrepreneur in me talking, but I think things were great back then. It was only later, when Art left, and I had to hire marketing and sales managers, and a real technical manager to drive the programmers, when things started to go bad. I supposed it was just part of how a startup company becomes a grownup company. Honestly, I liked the old days best.”

Kate said, “Let’s get back to Scrum. We’ll leave it that Scrum doesn’t talk directly about conventional management, and that it sounds a lot like what a team-focused startup might do. We can come back to what larger companies need to do after we get the full picture.

“Let me say a few more words about the roles. First, the team. Since the team is responsible for doing what the Product Owner asks for, the team needs to have all the skills to make that happen. It wouldn’t make sense, for example, to have a software team without testing. We couldn’t rightly hold them responsible for producing working tested features if the testing was done separately.”

“Wait a minute, Kate,” Dan said. “Everyone knows that developers don’t make good testers.”

“You might be surprised,” said Kate. “But the team isn’t just developers. The team in Scrum must have all the skills necessary to produce an increment of potentially shippable software in every Sprint. That means everything.”

“What if the product needs a manual,” said Dan. “Do they have to write a manual every Sprint, and keep it up to date?”

“In a word, yes,” Kate said. “The Product Owner determines what kind of documentation the product needs, and the team is responsible for producing it. And there are Scrum teams all over that include tech writers, who produce a draft of the manual every Sprint, just like the developers and testers produce a draft of the software.”

“How is that even possible,” Dan said. “They’d have to revise the manual every Sprint.”

“Yes, they would. However, the devs and testers have to revise the actual software every Sprint. Their stuff has to be usable, actually work, get correct answers, and so on. That’s actually harder to do than writing a manual. If a programmer leaves out a semicolon, the program won’t work. If a writer leaves one out, the document still works rather well.

“The proof is in the doing. As I say, there are teams all over who do this, producing more and more refined documentation as the team produces more and more refined software.”

Dan looked confused. “What if the Product Owner changes her mind about what the product has to do? The writers would have to change everything.”

Kate said, “If the PO changes her mind in some major way it is a big deal. Frankly it’s a bigger deal for the developers and testers than it can ever be for the writers. Anyway, Scrum requires the PO to decide what the product is and how to deliver working bits of it over a number of Sprints, and requires that the team be cross-functional enough to do what is needed.”

“What about resources,” said Dan. “Isn’t it wasteful, putting a documentation person on every team, and so on?”

“The team can change over time, depending on need. What is really wasteful is giving the team half a writer and two-thirds of a tester and seven sixteenths of an analyst. Scrum asks that we make some hard decisions about how to staff our projects, and our organization. Frankly, I think that’s a strength of the method: it requires us to make real decisions, not load-sharing everyone gives up fifteen percent kinds of decisions.”

“OK,” Dan said. “I think I’m getting the idea. You give the team everything they need, including someone who can actually decide what needs to be done, and set them loose with a budget. Seems like anyone could succeed if they got everything they needed.”

“Exactly!” Kate said. “Scrum starts with everything you need. A wise project creator would fund his most important projects fully, then work down the list until he ran out of people or money. Let’s face it, starving all our projects can’t possibly be a good idea. Anyway, let’s move on.

“Scrum relies on a fundamental notion, ‘Inspect and Adapt’. The whole team inspects what happens, using day-to-day events, and Sprint-to-Sprint events, to see clearly how things are going. When they see opportunities to improve, they put improvements in place. As we’ll talk about later, this is one of the places where Scrum can fail or go poorly: if you do not observe problems, or do not or cannot fix them, you can’t possibly prosper. It’s surprising how many organizations seem to forget this, instead just telling the team to soldier on.”

Kate made a note on a card: “How Scrum Fails,” then went on.

“Scrum defines four meetings. Each of these offers opportunities to Inspect and Adapt. They all fit within the big time box, the Sprint. Ideally, I think a Sprint should be no more than a couple of weeks long.

“Anyway, the meetings. First, there’s the Sprint Planning Meeting. At the beginning of each Sprint, everyone gets together and works out what will be accomplished in the upcoming Sprint. The PO provides ‘backlog items’, the things she wants, in the order she prefers them. The team considers these, and the technical means of accomplishing them. There can be some give and take, and at the end of the meeting, the team all understand what will be undertaken, and how they plan to accomplish it.

“Note that this is a conversation. A negotiation, if you will, but I prefer to think it’s a conversation with everyone on the same side. The team can’t do more than they can do, and it would be counter-productive if the PO were to demand more. Two weeks later, she’d get what they could do and frankly if the PO and team continue to forecast more than is accomplished, it’s evidence of undue and unrealistic pressure from somewhere.

“Again, at the end of this meeting, which should take a morning for a two-week Sprint, everyone on the team knows what’s going to be undertaken, why it’s the thing to do, and how they plan to get it done. Capisce?”

Dan said, “I think so. It seems simple enough. Every couple of weeks, they all get together, look at what the PO needs next, and figure out how much they can do and how to do it.”

Kate said, “Right. Now let’s look at the other end of the Sprint. The Sprint has two meetings at the end. The first is the ‘Sprint Demo’ or ‘Sprint Review’. In this session, the team demonstrates to the Product Owner what they have accomplished. Everyone discusses what happened, what issues were encountered and resolved, and so on. They do a little looking into the future, based on a fresh understanding of what has just been done, preparing for the next Sprint Planning Meeting. Here, we are inspecting the product and adapting our expectations of what is to come.

“The second meeting is the Sprint Retrospective. Here, we look at how we worked as a team and how our process and tools supported us. We brainstorm ways to improve, and agree to specific actions that we will take in the next Sprint to improve things. Often these changes are inside the team. Sometimes, they require someone outside to take some action, in which case we plan how we’ll influence them to do what’s needed. This meeting is an inspection of the process itself, and a determination about how to adapt to improve it.

“All three of these meetings are mandatory in Scrum. It would be extremely unwise to drop them or give them short shrift. Are you with me so far?”

Dan said, “Let me refresh the drinks and get my thoughts in order.”

“Sure,” said Kate.

Dan returned with drinks and a summary. “OK, so Scrum has these Sprints, a couple of weeks long, where the Product Owner and the team get together to plan what has to be done and how, then to see how well it went and figure out how to improve. The team has all the abilities they need, and they produce a bit of product every Sprint. Right? But you said there were four meetings, didn’t you?”

Kate looked happy. “Yes, I think you’ve got it so far. And the fourth meeting occurs daily. It’s called the “Daily Scrum’, I guess after some ritual that takes place in a sports event. It’s very simple and very brief: in fact, usually, it is done standing up, although I choose not to do that.

“Basically, every team member says what they accomplished yesterday, what they will accomplish before the next Scrum, and what, if anything, is standing in the way. They don’t try to solve the issues during this meeting, but if there are issues, most teams meet together or in small groups to address them right after the Daily Scrum. So what are the Scrum meetings?”

Dan said, “No one told me there would be a kind of inquisition.”

“No one expects the inquisition but I’m sure you’ve got it,” said Kate. “Go on.”

Dan said, “OK, there’s the planning meeting, the daily meeting, the demonstration and the – what did you call it, retrospective.”

“By Jove, I think he’s got it. What else is there, Dan?”

“You’re asking me? I don’t know. Do they do anything besides meet? Do they build anything, write reports, or the like?”

Kate said, “Yes. Yes, they do. There are what we call ‘Scrum Artifacts’. The most important of these is what Scrum calls the ‘Increment’, and what I call ‘What have you done for me lately’.

“At the end of each Sprint, we demonstrate an increment of software. This software is required to be ‘done’, by our then-current ‘Definition of Done’. The definition might start out simple, such as ‘able to be demonstrated on the development system’. But over the course of a good project, the Definition of Done itself gets more and more stringent. ‘Demonstrated on the PO’s system’, ‘documented and demonstrated on the production servers’, and so on. Some teams actually call things done, every two weeks, only when a customer has actually paid money to use it. That’s impressive, and Oak River isn’t there yet. Our definition of done is pretty strict however. Let me quote it:

“An increment is done when all the PO’s defined acceptance tests run, when the system is fully integrated and running on the production servers, when all the manual pages are up to date, the code is clean and well-factored, and all the programmer tests are running green.

“Our Product Owners do not accept anything that doesn’t meet those criteria, even the technical ones. They don’t inspect those criteria: the development team certifies that those criteria are met. But we are all serious about meeting them, and we’ll call a feature ‘Not Done’ before we’ll slack on them.”

“Wait,” Dan said. “Are’t there times when you’d prefer to get a feature out without clean code or some such techie concern?”

Kate said, “You’d think so, at first. Emergencies arise and so on. Truth is, if a team can release what looks like a feature faster by writing poor code, that’s major evidence that they have important things to learn about how to write software. A good professional produces software at the best pace by working clean.

“This means that every time we feel we ‘need’ to push something out that isn’t really ‘Done’, we inspect what’s going on and decide how to improve. So if we do have to rush out a defect fix, we are all committed just as much to fixing our process to make that unnecessary. It doesn’t take long until we are able to build increments that meet our Definition of Done fully, nearly every time. And if we do stumble, we go right back to inspect and adapt and work to make sure it won’t happen again.”

“That seems incredibly idealistic,” Dan said. “Things never go that well. Even if you tried, it would cost a fortune to be that good.”

“They can, Dan, and they do. In the early days of manufacturing, products were built, inspected, and sent back to be redone if things were wrong. Manufacturing people learned that inspecting earlier and more often meant that fewer products had to go back to be redone. Small inspections and small fixes to process are immensely less costly than reworking the whole product item.

“Similarly for software. Debugging a fully integrated system is difficult and costly, especially if it is made up of components that are not all individually nearly bug free. So we save time and money by testing at every level. We have automated checks that things work, and we run them all the time, and add to them all the time. The result is that things almost always go well, and we get very clear indications of where we’ve messed up when we do.”

Dan said, “But I have been reading Eric Ries book, The Lean Startup. He makes the point that it can be best to go out with far less product, even with a facade, rather than build out for perfection. You learn faster.”

Kate said, “Yes. But the thin character of such a product should be chosen. When we write code badly, we don’t get to choose where the problems are: they show up where we least expect them and where we don’t want them. So even when we’re building a minimal product experiment, we do best to work clean. We’re not gold-plating, but we are working clean. Anyway, from the Scrum viewpoint, this is all part of the Definition of Done. If a PO wanted the Definition of Done to include “code is the most rag-tag crappy code that will barely carry the load”, that could be the definition. Scrum doesn’t care. I care, and I wouldn’t work that way. But Scrum doesn’t care.

“But we’re talking about the artifacts. The main one is the increment. Without the increment, we have no product. But as the man says, ‘Wait, there’s more’.”

Kate went on. “There’s the Product Backlog. That’s just the Product Owner’s current list of things that she might want in the product someday. It’s kept ‘ordered’, generally speaking in the order that the PO would like to have things done in. ‘Order’ can consider a lot of concerns: how much we need to learn whatever that item will teach us; how much revenue we’ll get for it; how much pressure some stakeholder is putting on us to show him some results; and so on. What matters is that the PO and team considers and defines the order of the items.”

Kate took a breath, to the delight of observers near and far. “The Product Owner monitors progress in completing backlog items. She uses whatever means she finds useful, from comparing stacks of done and not-done cards, to charts showing the growth of features, even to Earned Value kinds of calculations if they’re into that sort of thing. She and the team continually ‘Groom’ the backlog, refining items, adding new items, removing items that no longer seem important. With me so far?”

Dan, recovering, said, “Yes. The Product Backlog is all the stuff that needs to be done, or might need to be done. I suppose items soon to be done are well fleshed-out …” He coughed, then went on “better understood and defined than things that are further down in the order.”

Kate feigned confusion but couldn’t suppress a grin. “Consider it a little treat. Anyway you’re right. Then there’s the Sprint Backlog. That’s just the list of things agreed to be done in the current Sprint. and the plan for getting them done. Just as the PO monitors overall progress in terms of the backlog, the team monitors progress toward attaining the Sprint goal. And, again, this can be done in any number of ways. My favorite is to have all the items on cards, and show them moving through whatever work stages they go through, so that I can see how many cards have arrived at the ‘Done’ station every day.”

Kate continued, “And that’s Scrum. Three roles, Product Owner, Scrum Master, and Team. Four meetings, Sprint Planning, Daily Scrum, Sprint Demo, Sprint Retrospective. And three artifacts, Product Backlog, Sprint Backlog, and the Product Increment. What have we missed?”

Dan thought a moment. “You haven’t said much about the Scrum Master, just that he facilitates and helps the team improve.”

Kate said, “And that’s about it. It seems like a simple job, and in sufficiently effective teams, it might even be absorbed into the team’s general operation. But truth is, there’s a lot to do and a good Scrum Master is priceless. Let me count some of the ways:

“The Scrum Master helps the PO do her job. He helps everyone understand how to create good backlog items, how to communicate them, how to plan an adjust in as dynamic an environment as most projects are, how to do all the things Agile teams need to do, and so on. He helps the team do their job, coaching, leading, even teaching them how to do things. He ensures that impediments are removed. He serves the organization, helping them understand Scrum, their role in it, and the impact of the things they do on the success of the Scrum team or teams. He works throughout the organization to help Scrum work. Best of all, he does this with no formal management authority.”

Dan said, “Sounds like a hard job.”

“It is,” Kate said. “Especially when you consider that you can become a Certified Scrum Master with two days of training. The range of things that may need to be done to help a team become really good, and the breadth of the organizational reach involved, can be immense. Scrum Master is either a very hard job, or perhaps not a person’s job at all. All those things need to be done, so doing them is surely a ‘role’. But whether that work can be done by a single person, I seriously doubt. Whether a person can be trained to do them … well, I don’t doubt. I know they can’t be. Doing everything that it takes to make a Scrum team effective requires so many skills and so much skill, that it’s a lifetime’s work.”

“But wait,” Dan said. “Are you saying that Scrum basically can’t work, because the Scrum Master role is too much for a single person?”

“Not at all,” Kate said. “Scrum can and does work just fine. Most Scrum teams get at least a reasonable amount of benefit, and teams that pay attention to removing their impediments can absolutely fly. Our teams are beginning to show that now. What needs to happen is that the team must pay attention to the Scrum Master role, and the company must pay attention to it as well. There needs to be continuing attention on improving the effectiveness of that role, and there needs to be recognition that sometimes parts of the Scrum Master role need to be done by other team members, or even people outside the team.

“So there’s your quick overview of Scrum. There’s much more we should talk about before you decide what to do with these new people you’re looking at. I’d suggest we get together again over the next few days to talk about how Scrum and Scrum teams can fail, about whether we at Oak River are actually doing Scrum, about other Agile approaches that are not like Scrum, about all the important technical and related practices that need to be in place, and more.”

“Thanks,” Dan said. “I think I’ve heard about all I can absorb for today. Let me check my schedule for the test of the week and drop you an email proposing another meeting. We can do it at the office if you like, of course.”

Kate reflected for a moment. “We might do that. There might be some things to talk about where some other people might be helpful. Otherwise, I like meeting here. The buzz of activity is energizing. Either way, let me know when you’re available and we’ll pick a time and place, and I’ll see you then.”

“Thanks, Kate,” Dan said. “I’ll just clear the table.”

When Dan returned from the trash bin, Kate was gone. Not even her smile remained.