Beware of the Evil “85% Done”

By Marko Majkic

Years ago, in the dawn of my Scrum voyage, I was asked by my colleague from the sales department to estimate a project. The situation was kind of complicated; I would say kind of weird from the beginning.

The project was a web application, which was supposed to service about a thousand simultaneous users. The client was in another country, so we communicated only over Skype and e-mail. I got this estimation task in late January and was told that the application should be finished in a beta version by February 1, and a final version should be released on March 1. "Tight schedule, very tight," I thought. And we didn’t even have the team assembled because our developers were on other projects and pretty busy. So, we needed to gather the team, to find developers, and to finish the project (beta) in two weeks. "Pretty challenging," I told my colleague. He already had some contacts with a recruiter and told me that finding a "few programmers" wasn’t a problem. "Ok, let’s have an online meeting with the company owner," I suggested. So, we had the meeting. Apparently, they had started this project six months prior with just one developer. I thought this was interesting. A few days prior to our meeting, the developer told the client (“Jack”) that he had to leave the project for personal reasons. “Even more interesting,” I thought and smiled to Gary (my colleague from sales department). Now, the Client had promised the stakeholders that they would deliver the beta version in two weeks and the final version after a month. If they couldn’t deliver, they would have to refund money with penalties. So, Jack was ready to pay big money to have this project finished on time, and Gary saw a nice opportunity for our company. I saw an opportunity to show the power of Scrum, but I was a little worried that the team didn’t exist at that moment.

"Hey Jack," I asked, "do you have an idea what has been done and what is supposed to be done by our team?"

"No problem, I have an online demo," answered Jack, "and I reviewed the application thoroughly with our developer. He told me that application was 85% finished."

"This is great!" I said, "Why don‟t you release this version with all the completed functionality, and we can work on the remaining 15%! This way you and your partners would have a faster return on investment."

"No, no, you don’t understand," Jack told us, "We have all the functionality developed. The developer told me that each feature is 85% finished."

I was speechless. "Ok," I said, "so, you have a definition of done with seven items, and for each functionality, six items are finished and one remains to be finished, correct?"

"Errr…sorry, I didn’t hear you well,” answered Jack. "You were talking about some, definition of done,‟ right? What is the definition of done?" At this moment I was almost terrified. He didn’t have any idea what was done on the project.

I tried to be calm. "Ok, but how do you know that the project and each functionality was 85% done?"

"Well, the developer told me so," he said.

The good thing was that he had full confidence in this guy. I was pretty skeptical. I was interested to see what was really done on the project.

"Ok," I told Jack, "would you send to us some online demo info and a list of requirements, please? We will analyze this and get back to you with our estimates."

"Great," Jack said. I suppose that he was thinking we were already on the project. The work day was almost over and Gary and I decided to work until we had some estimates for Jack. So, we worked hard for the next four hours. I did estimates for programming work and Gary was testing the "almost finished" functionalities. I did optimistic (but still realistic) estimations. Gary was working on the functionalities list, comparing it with the online demo.

After the job was finished we had a conversation. Gary showed the functionalities to me, one by one. After each one, we were more and more worried. At the end we did a draft estimate of the developers‟ work needed for finishing the project. The best-case scenario was that, with a good team of experienced (read: more expensive) developers, the beta version could be deployed on March 15 and the production could start on May 1. This was an optimistic estimate. Jack’s (or developer’s) "85%" wasn’t 85% - but actually between 15% and 50%.

I told Gary, "Let’s drop all of it. We should do everything from scratch and do it right. Let’s suggest this to Jack." And by "right," I meant "in Scrum way." I knew that we couldn’t do a good job by continuing to work on the existing code. It was pretty messy; no tests, no code documentation, no basic documentation at all. And I was sure that we couldn’t commit to finish a beta version in two weeks. Not to mention that we didn’t have the team yet.

After four hours of working on the estimate and analyzing the project, we got back to Jack. I suggested to him to start from the beginning right away and told him that he needed to speak with the stakeholders. He didn’t like what he heard. “Hey, we need to go beta in two weeks. I don’t care how much it will cost. Add ten developers if needed!” he was upset; I could hear it in his voice.

I didn’t know about Brooks‟ law at that time, but I had some experience with adding more developers to a project, and I did explain to him that it would probably not solve the problem.

I suggested that the only way to make the project healthy and avoid failure was to get real, to present the stakeholders with the real situation, to accept responsibility, and to deal with it. We would help this project to succeed at a lesser cost than what they already had spent, and produce it three times quicker than they had planned at the beginning.

"No," he said, "my project is 85% done. I will find some other team that will finish it in time. Thank you for your time."

I was amazed. He was hypnotized by the evil magic of "85% done." I knew this project was doomed. And very soon, unfortunately, we could see that I was right. The website has never seen daylight.

Years after this experience, I faced the "evil magic of 85%" several times. We didn’t get this job, but I gained great experience from it. Whenever I heard that I should join/save a project that was in trouble and "85% done," I knew that something was wrong. Some of those projects I finished successfully and saved them. Some of them failed. But almost every time when failure occurred, people (top managers) were seemingly hypnotized, repeating "we‟re almost done!" I like Scrum, among other things, because it emphasizes a clear definition of done. A story is done or not done. There is no such thing as "almost done." There either is or isn’t business value, no matter what tasks developers have finished. There is no such thing as "85% done." And once again, I don’t mean 85% of all user stories. I mean 85% of each user story. By Scrum criteria, this means 0% of project. With 85% of all user stories "done done," I would probably go live with my application and would be very happy about that.

I was thinking about this evil magic of "85% done." Why is it so powerful? Here are some of possible reasons.

First, it makes us think we‟re almost there. “Hey, just one small effort and we‟re there.” This number gives us a comforting feeling that we can relax, because the job is almost done.

Second, this number is ideal, because it’s not too big – so in case someone wants to check the work, the missing 15% can be always be blamed on something not working – even if it is at the very beginning. This number is not small either, preventing someone from saying you are far from finishing the job. This evil number is perfectly chosen for its evil purpose – to keep us from establishing a definition of done and really finishing the story/project.

Third, this number is not quickly verifiable. You can say it and nobody could check if it is true, without getting deep in the code.

All in all, don’t trust a manager or developer who claims that 85% of a story is done. You can run away from these situations or you can use Scrum and a definition of done as powerful tools for fighting this evil and save the world (of the project at least).

And to all of you Scrum guys – don’t measure progress within the story. A story is done, or it is not done. Please, make a definition of done suitable for your project with your Scrum team and stick to it. Make your user stories small and doable in a Sprint. A user story is a measurement for the business value of your software. So, deliver done user stories, deliver complete business value, and, of course, don’t forget; beware of the evil “85% done.”

Scrum In A Nutshel

By Dan Rawsthorne and Douglas E. Shimp

Scrum is about Teams producing Results in an agile way. Scrum Teams achieve results anyway they can by using a simple set of rules to guide effort. We will describe Scrum as a simple applied model so that a central understanding of Scrum can be built. Other complexities of applied Scrum such as scaling, distribution, etc. will be explored elsewhere.

The Team

The fundamental element of Scrum is the Scrum Team (or "Team"), which is a small (usually fewer than ten) group of people that provides useful Results/Products for Stakeholders.

Arguably, the most important role involved in Scrum is the Stakeholder, as the Stakeholders are the ones who have desires, wants, and needs, and are the reason the Team is developing the software in the first place. Often, there is a special Stakeholder called the Business Owner, who actually controls the budget for the Team. The Business Owner is often the one who called or asked the Team to form.

While the Stakeholders are the most important source of validation for the project, the most important person on the Scrum Team is the Product Owner (PO). The Product Owner works with the Stakeholders, represents their interests to the Team, and is the first person held accountable for the Team’s success. The Product Owner must find a result that will satisfy the Stakeholders’ needs and desires. The Product Owner provides direction and goals for the Team, and prioritizes what will be done.

The Scrum Team Members, including the Product Owner, are the people who actually do the work that satisfies the goals and priorities the Product Owner has set for them. The Product Owner must work with the Team to find a rate and direction that the Team can go, to achieve a desirable result. Each Team Member is accountable to the rest of the Team for his/her performance, even as the Product Owner is accountable to the Stakeholders for the Team’s performance. The Scrum Team is cross-functional; that is, people on the Team (collectively) have all the skills necessary to do the work (analysis, design, code, test, documentation, marketing plan, drawings; whatever is required for the desired outcome). The Team is self-organizing, self-managing, and constantly trying to improve; they work on the priorities the Product Owner has set. The Team Members commit to the amount of work they can do without undue influence from the Product Owner.

In order to aid the Team (Product Owner included) in doing its work, there is a role on the Team called the ScrumMaster (SM). The SM's responsibilities are to be a facilitator, moderator, and coach, with particular emphasis on helping the Team mature its self-organization and management. The ScrumMaster manages the relationship between the Product Owner and the rest of the Team, and facilitates removal of impediments for the Team, often working with the Product Owner, the Business Owner, and other Stakeholders to do so. Impediments can come from within the Team and outside the Team. The ScrumMaster understands the Scrum process and how the Team is using it, recommends process improvements, and assures that the Team is following the process they have agreed to. If the Team does not follow its process this becomes an impediment. Most impediments can be addressed by simply causing them to become a center of focus. The SM stimulates that center focus by calling attention to the impediment. Creating a smart center of focus is the art of being a SM.

The Backlog

A Scrum Team's work is managed with a Product Backlog ("Backlog"), which is a prioritized list of Product Backlog Items ("PBIs," "Backlog Items,” or simply "Items"). When the list is small it is just a straight list of things, but as it grows we add grouping mechanisms to organize many little things and help us keep track.

These Items represent the Stakeholder's needs and wants – each of them is a request for something of value from the Scrum Team. These requests can be for anything, including software functionality, marketing, non-functional requirements, technical and infrastructure requests, business support, maintenance of existing systems, and so on. It is a rule of Scrum that the Team shouldn't do anything for any Stakeholder unless it's on the Backlog. The Team will be actively working on the top few Items of the Backlog during the Sprint; this part of the Backlog is called the Sprint Backlog, which is often thought of as a separate list of its own. The Product Owner is responsible for prioritizing that Backlog and thus, creating a distinction between the Sprint Backlog and Product Backlog. From the Team’s perspective, the Product Backlog is work that we might do some day, and the Sprint Backlog is work we are committed to doing.

The Backlog contains Items at all levels of fidelity, from vague wishes/wants/needs to finely detailed requirements. The higher the priority of the Item, the more detailed the request should be, so that it will be ready for planning and execution. Note: “ready” does not imply excessive detail but, instead refers to enough detail. The Team working with the PO will determine what “enough detail” is.

When a Scrum Project starts, the Product Owner should initiate the Backlog by working with the Stakeholders and other Team Members and capturing their needs, wants, and requirements as Backlog Items. As the Project progresses, the Product Owner and the Scrum Team should continuously work with the Stakeholders to (re)prioritize the Backlog, identify new Backlog Items, eliminate noise, and refine and generally clean the items list to get it ready for planning. The project effort will result in product that will often clarify and identify Backlog Items. This process is called Backlog Grooming, and is a continuous process throughout the Project.

Now that we have the notion of the Backlog to work with, let's describe the process, which involves discussion of both Releases and Sprints.

The Release

The goal of a Scrum Team is to produce and release results that meet the goals and priorities that have been set down by the Product Owner (hopefully as a result of working with Stakeholders).

Typically, before a project formally begins, there is a Visioning phase (this could also be the first phase in a project), when the Business Owner, Product Owner, and the Stakeholders produce a Product Vision and a Product Roadmap. The Vision provides the overall focus for the Project, while the Roadmap gives guidance about Releases and their Goals.

The Scrum Team’s purpose is to create a result that satisfies the Stakeholders’ needs, wants and desires, often so that more demand for their services is generated. This production is done through a series of relatively short, fixed-length iterations, called Sprints, in which results are produced by working on Items. The Sprint length can vary, but this requires more discipline on the part of the Team and is not advisable for new, less mature teams. The steps of a Release are relatively simple, and I'll describe them here.

Usually, the first thing that happens in a release is Release Planning. The Stakeholders, the Product Owner, and possibly other members of the Team, get together and negotiate what will be accomplished in the Release. This negotiation considers the Product Vision and Roadmap, balances the needs and wants of the Stakeholders against the abilities of the Scrum Team, and results in a set of Release Goals and a Release

Strategy to achieve them. The Product Owner and Team must update the Backlog so that there are prioritized Items on the Backlog that support the Release Goals and Strategy and are ready for planning.

Once we have a Backlog that supports the Release Goals and Strategy, the Team starts sprinting. The idea is for the Team to do as many Sprints as the Release Strategy calls for, and then Release the Results. Each Sprint looks basically the same, with the Release activities as part of the last one.

The Sprint

The fundamental process flow of Scrum is the Sprint, which is a relatively short period of time in which Backlog Items are converted into Results.

The first thing to do in a Sprint is Sprint Planning. In Sprint Planning the Product Owner works with the Team to negotiate what Backlog Items the Team will commit to for the Sprint in order to support the Release Goals and Strategy. Each of these Items has an agreed-upon definition of "Done," and collectively these Items are called the Team's Sprint Backlog. It is the ScrumMaster’s responsibility to ensure that the Team commits to a realistic amount of work, and that the Product Owner does not unduly influence this commitment. Often, the Items on the Sprint Backlog are tasked out in order to give the Team confidence that it can complete the Item, and thus commit to it. The tasking of Items can help the Team mature by paying attention to the work agreements they make with each other. The tasking can also help the SM detect when the Team is working well.

Once Sprint Planning is over, the Team begins work in the Sprint. The Team self-organizes to do the work and self-manages as it does the work. The Team’s work pattern is described as a swarm to get the job done. Team swarm is a pattern of performing Teams that looks like a swarm to an observer. While the Sprint is in progress, the Team will have Daily Scrums in order that each Team Member understands what the Team's status is. This allows the Team to detect when to adjust in order to be as effective and efficient as possible. These adjustments often take significant time and occur after the Daily Scrum.

During the Daily Scrum, and continuously throughout the day, the Team Members notify the ScrumMaster of any impediments they encounter. It is the ScrumMaster’s responsibility to facilitate the removal of these impediments. Often, this requires working with Team Members, the PO, the Business Owner, and other Stakeholders.

The ScrumMaster must also ensure that the Team does enough Backlog Grooming in order to be prepared for the next Sprint's planning meeting. The Backlog Grooming is a strategy to prepare enough work to begin next so that a rhythmic flow of work can happen.

When the Sprint is over there is a Sprint Review, when the Product Owner and the Team show the Team's Results to their Stakeholders. This is done for two reasons: to prove to the Stakeholders that the Team is moving in the right direction, and so the Team can get feedback on what they've done. If necessary, the Release Goals, Release Strategy, and Backlog are updated as part of the Review (or soon thereafter), considering the Review and any "business reality" changes the Stakeholders may have. When Teams are small they can rely on more intuitive reasoning to determine what the "right direction" is. As a Team grows they will see a need for more sophisticated techniques that use metrics to help them answer what the "right direction" is.

After the Sprint Review, the Team has an internal retrospective to analyze its performance and process. The Team decides what changes, if any, they wish to make to their process as a result of this analysis. These changes will be "enforced" by the ScrumMaster in future Sprints. To enforce something the SM will need to shift the focus to the issue at hand and then let the Team react. Telling the Team what to do is not desirable. Shifting the Team focus and thereby enforcing change is an art of the SM.

At this point the Sprint is complete, and the Team either begins the next Sprint, the next Release, the next Project, or disbands, as appropriate.

Quick Summary

Team of 7±2 does the work
PO provides the work requests
SM provides care for the whole team (PO/Team)
Team swarms on the work
Team is cross-functional
Team owns its process
PO provides validation for each work request
Work is done in short bursts < 30 days each (Sprints)
Work starts and stops with Planning and Review
Review demo for product; Review retro for process
Daily Scrum detects any adjustments needed
PO determines priority as a flow of work requests
SM observes and helps the whole team adjust
SM tunes the whole team for maximum performance

Manager 2.0: The Role of the Manager in Scrum

By Pete Deemer

When an organization starts to explore Scrum, there’s often an uncomfortable moment early on when someone points out that the role of "manager" seems to be missing entirely. "Well I guess we’ll have to just get rid of ‘em all!" wisecracks one of the developers, and all the managers in the room shift uncomfortably in their seats.

Scrum defines just three roles – Product Owner, Team, and ScrumMaster – and the basic direction given to others in the organization is to "support them, or get out of their way." This is not very detailed advice, especially if you’re a manager expected by senior management to ensure everything goes well.

The traditional role of the manager in the corporate world is based on a model known as "command and control." Here, the job of the manager is to identify what needs to be done, to issue detailed instructions to the employee, and then to ensure the employee completes the work according to the instructions. The role of the employee in this model is simply to follow the directions as given, trusting the judgment and wisdom of the manager to ensure that the right work is being done in the right way.

In complex, dynamic environments such as software development, this approach tends to break down. First, it is difficult and time-consuming for a manager to understand every requirement in full detail and issue precise instructions to guide the work of every employee. Within a software development Team, the work is highly interconnected, with intricate dependencies, and frequent change and surprise. To expect a single manager to do all the basic thinking for his or her team is unrealistic, and it often constrains the Team’s productivity to the manager’s ability to give instructions. In addition, this approach tends to be demoralizing for employees; their role is simply that of "order follower," and they often feel little sense of ownership of their work. Accountability is limited to answering the simple question, "did I complete the orders I was given?" If the answer is "yes," the job has been done – regardless of whether the right thing was built, built well, or built to satisfy the business goals of the customer.

Scrum is based on a different approach: The Self-Organizing Team. The difference is apparent from the first steps the Team takes. In Scrum, the Team decides how much work to commit to in a Sprint. Experience has shown that when Teams themselves decide how much to commit to – and when this commitment is realistic and achievable – the Team’s focus, motivation, and drive is significantly higher, and they produce better results. When managers first learn of this practice, they often voice the concern, "What if the Team under-commits?" This is typically not a problem, since the process of deciding the commitment is very transparent and open. Indeed, it’s much more common in the early Sprints for Teams to significantly over-commit; most Teams have very little experience doing their own estimation, and it takes a number of Sprints before their optimism is tempered by experience. Moreover, in the event the Team does wind up under-committing, they will either finish the Sprint early, or they will start work on the next item on the Product Backlog. No harm, no foul.

Team Tango had just completed their first Sprint Planning Meeting, for a two-week Sprint. They brought in their manager, Jason, and walked him through the work they'd decided to commit to in the Sprint.
Finally, they asked Jason, "Is this a good amount to commit to?"
Jason turned the question around to the Team:

"Do you truly believe you can finish this work, at a high level of quality, by the end of the Sprint? Do you really feel committed?"

The Team members all nodded to him, looking quite convinced.

"Then it's a good amount to commit to," Jason replied. "And if it turns out to be too much or too little, you'll know two weeks from now, and you'll have learned something about how much you should commit to in the following Sprint".

The next aspect of self-organization happens during the Sprint, when the Team works together closely to decide who will perform which tasks and to make sure all the work is completed. When the Team is responsible for this decision-making, they remain focused on the fact that they own the commitment – and if the commitment is to be completed, they are the ones who must do it. When someone outside the Team is responsible for deciding what needs to be done and by whom – for example, a manager – the Team receives a subtle but real signal that they are not responsible: it’s the manager’s job to worry about how to meet the commitment, not the Team’s. This does not mean that managers are not providing support during the Sprint – on the contrary – but managers are careful not to send any signal to the Team that would reduce their sense of ownership of the goal, or responsibility for managing themselves during the Sprint.

On the first day of their first Sprint, the Team called their manager Sanjay over to join them for their Daily Scrum Meeting. Sanjay, wanting to be helpful, agreed to the request. He stood just outside the circle as the Team gave their reports to each other. Sanjay noticed that people seemed to be emphasizing how much they got done the day before, and weren't spending very much time reporting the blocks they were hitting. And after each person gave their short report, they looked over to Sanjay expectantly, hoping to catch a glance of approval. By the end of the Daily Scrum, Sanjay noticed that the entire circle of people had shifted, so they were now facing him.

After the last report was given, a Team member raised his hand, and asked "Sanjay, do you have any feedback or guidance for us?"

Sanjay knew that he had to take action.

"Guys, I'm really concerned. I feel like this meeting was for my benefit. I feel like you‟re still looking to me to make sure everyone's doing the right thing. Here's the deal: I'll give you any help you need, at any point in the Sprint. If you hit a block and you're not able to resolve it, I'm here to provide any assistance I can. But at the end of the day, you are responsible for doing what's necessary to meet the commitment you've made. So from now on, I'm not going to join this meeting. This is your meeting, to manage yourselves, to meet your commitment. If I'm here, I'm afraid I'm just going to undermine that."

The Team was silent. Then Victor, a Team-member, spoke up.

"So let me get this straight. We are the ones responsible here? We really do own this…?"

A subtle jolt of realization passed through the Team, and at that moment, they took their first step towards truly becoming a self-organizing Team.

One of the biggest challenges in successfully making the transition to self-organization is that the Team will not begin to self-organize until everyone outside the Team stops micromanaging them. Teams are so conditioned to follow orders that they will often not begin to self-organize until there are no orders available to follow. This requires a leap of faith for the manager, and it can be scary. This is not to say that the manager abandons their Team – rather, the manager needs to change their style of interaction, and constantly signal to the Team that they are now the ones responsible.

Eileen was an Engineering Manager at RedAlpha Systems, working with a Team of seven relatively junior developers. During the first Sprint Planning Meeting, she sat at the back of the room working on e-mail, as the Team completed the task breakdown for a big feature at the top of the Product Backlog.

When they finished, they turned to Eileen and said "How does this look to you?"

Eileen could see immediately that the Team had overlooked several important database tasks. It would be very simple for her to simply point out the tasks they’d overlooked, and the problem would be solved. Or would it?

Eileen decided to try a different approach. She stood up and announced, "Guys, you've done a pretty good job, but you're not quite done. There are a couple important tasks that you've overlooked. I'm not going to tell you what they are. But I will give you a hint: think more carefully about the user session data. Now I'm going to go and grab a cup of coffee, and I'll be back in about 5 minutes. See if you can figure it out before I get back."

And at that, Eileen strode out of the room.

The Team looked at each other, slightly bewildered. Eileen had always been quick to point out what they'd missed; they depended on her for that. But this time, she was making them figure it out. They stood in silence for a moment at the whiteboard, then slowly discussion began. They went through task by task, looking at each from different angles. Then, after a few minutes of discussion, Tony spoke up.

"Wait a minute… where are we going to store the user session data? We‟re going to have to set up a new table in the database for that, right?" There was a round of forehead slaps from the other Team-members.

"Of course! How did we miss that!" several people murmured. There was a chuckle of embarrassment, and Sam started writing yellow Post-It Notes for each of these new tasks and putting them on the white-board. A few minutes later, Eileen returned with her cup of coffee. She looked at the white board, and nodded in agreement.

"Good job, guys. Now why don't you all continue with your meeting, I've got a bunch more e-mails I need to get through."

Eileen sat back at the end of the table, satisfied that she'd done her job well.

In this example, it would have been faster and easier for Eileen simply to tell the Team what to do. But had she done that, she would have encouraged them to wait for solutions from her, and not think for themselves. Instead, Eileen did something harder, but ultimately much more valuable: she placed the responsibility on the shoulders of the Team to figure out what they had forgotten, and provided just enough help to enable them to get it done. Had Eileen returned to find the Team still struggling, she could have provided another hint or asked another probing question, and continued to do so until the Team finally figured out the missing tasks. Eileen could even have let the Team proceed, and discover their oversight during the Sprint; mistakes often produce the most powerful learning experiences.

In simplest terms, the manager in Scrum is less of a "nanny" for the Team and more of a mentor or "guru," helping them learn, grow and perform. This is the shift from "Manager 1.0" to "Manager 2.0."

In order for managers to be effective in this new mode, the organization must redefine the role and expectations of the manager. For example, in Scrum, the Team is responsible for completing their commitment in the Sprint, and for this to work, it must be clear to all that the manager is not responsible for this. Similarly, in Scrum, it is the Product Owner’s responsibility to deliver the release on schedule, not the responsibility of engineering management, and the organization needs to make clear to everyone that this is the case. Problems occur when the organization “talks the talk” on the new role of the manager, but does not “walk the walk” when things get difficult.

The Galaxy Team had been doing Scrum for several months, and the Team was well on its way to being truly self-organizing. Their motivation was high, they were focused, and after a few Sprints of under-delivery, they were now showing a pattern of making reasonable commitments and delivering those 100% each Sprint. Morale was high, and there was a real sense of “flow” in the work they were doing. The engineering manager Francis had come a long way – once a habitual micromanager, he was now acting like much more of a mentor and coach for the Team. Unfortunately, though, in the eighth Sprint, the Team encountered some unexpected difficulties, and about halfway through the Sprint, they were significantly behind in their progress. The VP of the group, Simon, had ventured into the Team’s work area to see their Sprint Burndown Chart, and called Francis to his office.

"Francis, it looks like this Sprint is a disaster. What’s going on?" he asked.

Francis responded, "Well, the Team hit some bumps along the way, and they're trying hard to get everything done that they committed to, but it's a bit touch-and-go right now."

Simon grimaced.

"Francis, this project is critical, and we can't let it fall behind. I'm counting on you to make sure the Team finishes what they commit to, this Sprint and every Sprint. As a manager, your job is to make sure the Team gets it done; if things are going well, then you can back off a bit, but the minute the going gets tough, I want you in there making sure that no time is being wasted, and everyone is doing exactly what needs to be done."

Francis was exasperated. Simon had been too busy to attend the in-house Scrum trainings, but Francis had emailed him a PowerPoint presentation about self-organizing Teams and the new role of the manager, and Simon hadn't voiced any disagreement. Francis spoke up:

"But what about the self-organizing Team, Simon? What about our shift away from micromanagement?"

There was a glimmer of recognition, as Simon recalled a PowerPoint he'd seen a few months before.
"Yes, the Team is responsible, but when they start to fail, I hold you responsible. We want maximum accountability, so I'm holding them accountable and I'm holding you accountable. In our department, everyone is accountable! Now make it happen."

At that, Simon spun his chair around and started typing. Francis took the hint and left the office.

The next day, Francis showed up at the Daily Scrum Meeting.

"Guys, we're going to do a different format for the meeting today. Due to the criticality of this project, Simon has instructed me to more actively… uhhh…, facilitate' your self-organization during the Sprint. So what I'd like to do this morning is get a status update on each of the features you've committed to – whose done what so far, and what's left to be done – and I'm going to be giving some more detailed feedback so hopefully we can get everything 100% finished by the end of next week."

The Team looked at each other. Philip, the ScrumMaster of the Team, spoke up. "Francis… uhhh… does this mean that the Team is no longer responsible for managing itself?"

Several Team members nodded in agreement.

Francis replied, "Guys, we're all responsible. You're responsible for managing yourselves, and I'm responsible for making sure you get everything done. We're all responsible together!" Francis didn't see the eyeballs subtly roll.
As the Sprint proceeded, Francis was more and more involved. The Daily Scrum became an update meeting for the Team to tell Francis what they'd been able to complete, and for him to assign them the next day's tasks. The mood of the Team shifted; motivation seemed to go down, and Team members seemed to be reverting to their previous role, what they used to sarcastically call "servants-of-Francis-the-Great." By the end of the Sprint, the Team was fully back into "order-following" mode, and Francis was directing their efforts task-by-task.

At the Sprint Review, the Team was surprised when Simon joined the meeting just as it was starting.
"So…" Simon announced, "Did we get our commitment done?"

The Team looked at each other. Francis answered.
"Simon, unfortunately there are a couple backlog items that weren‟t finished." There was a flash of anger in Simon's eyes.

"How did this happen? Who is responsible for this?" The Team was silent, but their heads all turned slowly to Francis.
Simon continued. "Francis, I told you to get it done. Next Sprint, I don't want to see this happen again. If it does, there will be hell to pay…"

Upon hearing this, everyone on the Team made a mental note to think very carefully about just how much to commit to in the next Sprint. The last thing they wanted was to get shouted at again two weeks from now.
As the Sprints passed, Francis became more and more involved in directing the Team at every stage of their work. Gone was any semblance of self-organization, and with it disappeared the improved motivation, drive, and focus that the Team had started to display. Morale had plummeted, and so too had productivity. Lunch breaks were getting longer, coffee-breaks more frequent, and Francis felt like he was spending more and more of his time just making sure people were at their desks working. Those amazing few Sprints, when the Team was truly self-organizing, and performing at the level they were really capable of, were becoming more and more of a distant memory. The return to micromanagement was made all the worse because they'd had a taste of the self-organization "good life."

here were errors of judgment at every step of this situation. The ScrumMaster didn’t protect the Team from Francis’s micromanagement, or call Francis on the "double-talk." Francis didn’t make any effort to reason with Simon, or help him see the consequences of his actions. But perhaps the biggest mistake was an early mistake: Simon was never properly educated about the shift in the management model that Scrum requires to be successful, and how this applies not only in good times but also when the going gets tough; and this shift was never made "official" in the form of a change to Francis’s job description. And as a result, a successful, high-performance Scrum Team rapidly deteriorated back to its previous under-performing state.

The above scenario is extremely common and is a frequent point of failure for Scrum transitions. Furthermore, in an organization where this scenario plays out, word spreads very quickly, often causing other managers to proactively return to micro-management as a self-protective measure.

So how does one prevent this kind of failure from occurring?

First, one has to make a clear-eyed assessment of management’s willingness and ability to change, at every level. If there exists a fundamental belief in the effectiveness of the "command and control" approach within the management and executive ranks, and a heavy dependence on intimidation, threats, or punishment (such as shaming or humiliation) as a management tool, it is going to be particularly difficult to make the transition to a new way of thinking. As a result, an adoption of Scrum risks being incomplete and dysfunctional, producing little if any improvement for the organization.

However, if there is an openness to change, and a recognition that the existing command and control habits may possibly not be the most effective approach, then there needs to be education and coaching at every level of management; in practice, this means high-quality Scrum training for all managers, from the lowest functional manager all the way up to the senior (VP-level and above) members of the organization.

The final necessary step for completing this redefinition of the role of the manager is to “make it official” within the organization. One option is to use the pre-written job description included below as guide. The other option is to complete the interactive exercise that follows with managers in the organization, to break down their existing job descriptions and rebuild them to be compatible with Scrum values and practices. With either of these approaches, it is critical to get formal approval of the manager’s new job description from his or her manager (for example, the Engineering Director, or department head). Without a clear, "official" approval from senior management, the manager’s new role will be more difficult to protect when difficulties arise.

THE MANAGER AS SCRUMMASTER

Another approach to redefining the role of the manager is to convert them into the ScrumMaster for their Team. This has a poor track record of success. When the manager plays the role of ScrumMaster, it’s highly unlikely the Team will ever begin to self-organize. The previous habits of "order-giver" and "order-follower" are very difficult to break, and what will likely happen instead is that pre-existing command-and-control values and patterns will be transplanted into the heart of the Scrum practices. As a result, the benefits that flow from a self-organizing Team – ownership, focus, drive, pride in quality, improved morale, and better productivity –will likely not be realized. It would be better in most cases to have a Team-member play the role of ScrumMaster, even if they must do this in parallel with development responsibilities.

HANDS-ON: REDEFINING THE MANAGER’S ROLE

People needed: Manager, Exercise Facilitator

Step 1. Ask the manager to write down all of their current job responsibilities on Post-It Notes. The manager should try to be as comprehensive and complete as possible, including both official and unofficial responsibilities and things they should be doing but haven’t had time to do. Most managers should be able to come up with at least 20-25 items. Here’s a sample list:

Step 2. Draw two columns on the whiteboard: "Fine in Scrum" and "Conflicts with Scrum / Not Needed in Scrum." Ask the manager to go through the Post-It notes one by one, and place them in one column or the other.

Step 3. Take all the items in the “Fine in Scrum” column, and turn them into a new job description for the manager. (Getting help from HR may be useful at this stage.)

Step 4. Ask the manager, "Will you be more useful or less useful to the organization in this new role?" and “Will this role be more interesting or less interesting for you to do?" In most cases, the immediate response will be "more useful" and "more interesting."

Step 5. Get formal approval of the manager’s new job description from his or her manager (for example, the Engineering Director, or department head). This is a critically important final step. Without formal agreement, the manager’s new role will not be considered "official," and there will be an even greater risk of falling back into prior patterns of micromanagement and command and control.

EXPLANATION

Fine in Scrum

1. Help remove blocks that the Team is not able to resolve by themselves While the ScrumMaster does this hour-to-hour / day-to-day, managers will need to focus on removing more systemic or companywide blocks. These are often the most vexing problems in the organization, and will require the management’s influence, authority, or spending power to overcome. In The Enterprise and Scrum, Ken Schwaber recommends creating an enterprise transition team of managers and executives who are responsible for evolving the organization based on a backlog of impediments.

2. Provide advice and input to the Team on technical difficulties that come up Managers should be available to give advice or assistance whenever the Team asks for it.

3. Do regular 1:1 meetings with Team-members, to provide coaching and mentoring. Managers should spend 1:1 time with Team-members, at a frequency that feels right. This is not a task update meeting – this is time for coaching and mentorship. Some managers like to do this sitting side-by-side, writing code!

4. Give input on how to make features better.
This input goes directly to the Product Owner, typically during the Sprint Review.

5. Stay abreast of developments in tools, technologies, and techniques the Team is using.
A very important and often neglected activity. Managers are can sometimes be "frozen in time" at the technology and development practices that were current when they were last doing actual development themselves.

6. Plan training and other skills development for Team-members.
Managers should think carefully about areas where the Team’s skills could use development, or capabilities the Team will need to have to handle upcoming Product Backlog items.

7. Stay up to date on industry news and developments.
Again, an important and often neglected activity.

8. Anticipate tools, skills and other future needs.
Another important and often neglected activity. Be sure to get input from the Team.

9. Plan and manage budgets and financials.
Another important and often neglected activity. Be sure to get input from the Team.

10. Give input on what features / functionality the Team should build.
This input goes directly to the Product Owner.

11. Do performance evaluations and provide feedback to Team-members.
This is a necessity within most organizations (despite well-documented flaws in the methodologies typically used). Managers should base their evaluations on their own observations and well as on feedback from the employees’ fellow Team-members.

12. Do career-development and career planning with Team-members Career.
opportunities are one of the most significant valuable forms of compensation people receive from their employer.

13. Recruit, interview and hire new Team-members.
Some of the best – and in other cases, worst – management actions are hiring decisions. Great hires pay dividends every single day they are employed – and poor hires are an invisible daily “tax” on the Team’s ability to deliver business value.

14. Remove Team-members who are not able to perform well within the Team.
If even after extensive coaching a Team-member is not able to contribute, work harmoniously with other Team-members, or perform at the level required, they may need to be moved off the Team, or out of the organization. Typically managers will need to guide this process, in coordination with HR.

Conflicts with Scrum or Not Needed in Scrum

15. Decide what work needs to be done.
The Product Owner decides the features and functionality that needs to be built, and the Team determines what tasks are necessary to deliver this.

16. Assign the work to Team members.
The Team does this itself, during the Sprint.

17. Keep track of what everyone on the Team is doing
The Team does this, using the Daily Scrum Meeting and the Sprint Backlog.

18. Make sure the Team gets their work done.
The Team is responsible for this.

19. Make commitments to management about how much Team can do by a certain date.
The Product Owner measures or estimates the Team’s velocity, and makes forecasts of how much of the Product Backlog the Team can complete by a specified date. If the Product Owner makes a hard-date release commitment, the Product Owner is responsible for including the necessary scope and schedule buffer to achieve it.

20. Be responsible for the Team meeting the commitments I’ve made to management.
The Product Owner is responsible for making decisions about what to do if velocity is lower than anticipated – either moving the release date, removing Product Backlog items, or simplifying Product Backlog items.

21. Do weekly status update report for management.
Not needed in Scrum. If management wants to know how the project is going, they ask the Product Owner for the Release Burndown chart.

22. Do weekly Team staff meeting.
Not needed in Scrum. The Team updates each other daily, and managers can get an update on the Sprint in the Sprint Review Meeting.

HANDS-ON: SAMPLE JOB DESCRIPTION FOR MANAGER

• Lead the recruitment and hiring of new Team-members (with the active involvement and input of the existing Team-members)
• Provide input to the Product Owner on the product strategy and vision, and give feedback to the Product Owner on the content and prioritization of the Product Backlog.
• Provide support and assistance to Teams and their ScrumMasters. Be prompt and proactive in helping remove impediments that are harming Teams’ ability to be effective.
• Actively support ScrumMasters’ efforts to protect Teams from disturbance, disruption, or outside interference.
• Be available to provide advice and assistance to Teams on technical difficulties that arise in the course of doing their work.
• Identify issues to Teams that they might overlook, such as scalability, performance, security, etc.
• Provide mentorship and career development advice and guidance to Team-members. This mentorship should include technical mentorship, as well as soft-skills and other aspects of being effective and successful in a development organization.
• Plan and manage skills development and training for Team-members. Think carefully about areas where their skills need greatest development, or where the most opportunity for improvement exists; work with the person to identify appropriate training; and obtain budget and time allowance to complete it.
• Stay abreast of developments in the tools and technologies that Teams are using. Solicit input from Teams and other stakeholders on tools and technologies that could be useful. Spend time getting hands-on familiarity with these tools and technologies.
• Stay up to date on industry news. Be knowledgeable about developments from our company, our competitors, and our largest customers, including financial performance, marketshare, product roadmap, and overall business strategy.
• Remove Team-members that are not able to perform well within a given Team, work effectively with their fellow Team-members, or perform work at the level of expertise or quality required. This should come only after coaching and training has failed to correct the under-performance.
• Do financial planning and budgeting for Teams, including anticipating future people requirements, skills development and training needs, tools and technologies required, hardware, travel, and any other resources that people will require.
• Provide performance feedback and complete performance evaluations for Team-members. Informal performance feedback should be provided on a frequent basis, and should include feedback from fellow Team-members. Feedback should be focused on recognition for achievement, and opportunities for growth.

Cargo Cult Agile

By Manoj Vadakkan

We have been saying "there are no silver bullets" over and over again. But do we really believe that? In some ways, it is like the disclaimer we add to the end our e-mails. Nobody reads it, but the legal department makes us put it there. Aren’t we (the IT industry) treating Agile like yet another silver bullet? Everyone wants to "adopt" it! Everyone wants to say that we are Agile! It is becoming more like a "Cargo Cult" (See Notes 1).

During World War II, materials such as food, clothing, and tents were airdropped to equip the soldiers and the natives in the Pacific Islands. At the end of the war, the soldiers went home and the air cargo stopped coming, but by then the natives were used to the airdropped materials. Soon, they dressed themselves as ground controllers, wearing carved wooden head sets and waving landing signals in the hopes that these activities would attract those cargo planes.

In some cases, it seems like we just have a need to say we’re using Agile practices, even if we’re really not. We don’t use those old school requirements documents anymore, instead we create user stories. We estimate in story points; Fibonacci series is fun, and so are poker cards! Sure, we do release planning. We also do a Daily Scrum; well, we cannot really do it daily because our team members already have too many projects and meetings, so we just meet twice a week. Regarding user stories, we have to write them down in the form of detail specification because our testing team is busy with other projects and not available for the first few months to really participate. Additionally, we are required to have those documents signed by all parties, scan them, and upload them to the document management system. Otherwise, how would we know what we agreed to?

So if we think adding a daily (or mostly daily) standup meeting, estimating in story points, and implementing a few other things we find in the Agile/Scrum books will save us, well, good luck! Like the Cargo Cult, we can keep wearing our wooden head sets, lighting those run ways, and hoping for the planes to land.

Like the Cargo Cult, we are getting some of those superficial elements correct. But can we really attract the cargo planes with those elements alone? Do we really know what problems we are trying to solve? Do we really understand what we are doing and why?

In order to solve problems in your organizations, you need to look inside, not outside, to adopt yet another practice, process, or tool. You need to look at what problems you need to solve and identify solutions to those problems. Certainly, Agile/Scrum practices are proven in the industry. So bring that knowledge to your organizations in the form of training, coaching, or hiring. They can seed some of the options to get to your solutions. However, the solutions need to come from within the organization. That should be what "adopting" Agile/Scrum means. These practices need to solve the problems and achieve your organization’s goals.

Here are some activities that will help you identify problems and move towards a solution.

1. Do some soul searching: One way of doing this is to have an open space meeting. (See Notes 2)
• This will help you identify some of the problems you are trying to solve. (e.g. concept to cash takes too long)
• Help identify some of the possible solutions. (e.g. remove some of the communication barriers)
• Bringing people together will help the team take ownership of these problems and solutions instead of yet another mandated process that comes from upper management
2. Create a Product Backlog of concepts that the organization wants to try to solve the problems.
• Break those into tasks and assign resources.
3. Get senior management sponsorship.
• There comes a time when you will have to rethink the organizational structure in order to solve some issues. You can remove some of the organizational barriers only if you have senior management/leadership support.
4. Consider getting a coach, advisor, or someone who has done this before.
• A good coach will be able to guide you to possible solutions for your issues. Instead of just "adopting" some of those silver bullets like daily meetings and iterations, they will be able to guide you to solutions to the problems. A good, experienced coach can reduce the costly expense of experimenting.

There are a lot of articles out there that will help you in this transition. A comprehensive analysis can be found in Succeeding with Agile, a new book by Mike Cohn.

Have you seen Cargo Cult Agile in action? Tell us about your experience with Cargo Cult Agile.

Notes

      1. About Cargo Cult: http://en.wikipedia.org/wiki/Cargo_cult
      2. More about open space: http://www.openspaceworld.org/cgi/wiki.cgi?AboutOpenSpace

Smarter Than the Smartest: The Wisdom of Teams

By Sanzio Casto

Despite clichés of modern business theory, teams have a remarkable role in Scrum, not because of their power to define, arrange, distribute and perform the methods of work into a Sprint, but because of the frequent and present values in the diversity of a group.

The idea is that a collective can solve problems better than most individuals within the group, including experts. A group's intelligence depends on a balance of autonomous information that each member holds - not necessarily specialist knowledge - and common information that every team member shares. This combination of independence, decentralization, diversity of opinion, and aggregation helps to keep the group smart.

In which fields do the skills of the group stand out from the experts'? The problems that require cooperation are the most susceptible to a set of issues inherent with the wisdom of crowds. Cooperation challenges involve organizing individuals' self-interested actions in a way that creates mutual gain. It's counter-intuitive but groups are typically smartest when the people in them act as much like individuals as possible, with no directive leadership, and the independence to carry their own sources of information and analysis. But how do teammates foster mutual cooperation instead of selfish behavior? Robert Axelrod in his classic The Evolution of Cooperation, argued that the key to cooperation is "the shadow of the future," i.e. decisions have future consequences and do indeed affect the decisions of others. When colleagues repeatedly deal with each other over time a stable pattern of direct reciprocity is developed. This cooperative approach allows the team to accomplish the tasks in a Sprint regardless of its differences.

So, does a team with members who divide the same perspectives, motivations, and purposes facilitate reciprocal collaboration? Not necessarily. "Work force" is far different from groupthink, which is "a type of thought exhibited by group members who try to minimize conflict and reach consensus without critically testing, analyzing, and evaluating ideas." As Lu Hong and Scott E. Page perfectly state, a team seen as a collection of agents "outperforms individuals partially because people see and think about the problems differently. Additional people create the opportunity for more potential solutions. These additional solutions are only possible if people differ. If all people encoded and solved problems identically, multiple heads would be no better than one."

In a team consisting of a heterogeneous mix of members' social background and ideology, it is a good idea to quickly reflect on the strategies that should guarantee effective communication for collaboration, especially in the Daily Scrum meeting:

• Each member must see value and should be able to identify real benefits of engaging in the collaboration;
• Each member ought to be able to modify his own behavior to adapt to changing situations;
• The practice of listening to others should be promoted;
• Multidirectional communication where one speaks and others listen and respond must be encouraged;
• Knowledge and information exchange should be supported;
• A synergy must be generated by synchronizing the actions, optimizing use of resources, and leveraging the actions of others.

The estimation technique of planning poker assures the benefit of the team's collective intelligence. The standard example is a jar of pennies. When guessing how many pennies there are inside, the average of all the guesses is often more accurate than any individual guess. So, how often has estimation felt like guessing how many pennies are in a jar?

REFERENCES

James Surowiecki, The Wisdom of Crowds: Why the Many Are Smarter than the Few and How Collective Wisdom Shapes Business, Economies, Societies, and Nations (Anchor Books, 2005).

Scott E. Page, The Difference: How the Power of Diversity Creates Better Groups, Firms, Schools, and Societies (Princeton University Press, 2007).

Robert Axelrod, The Evolution of Cooperation (Basic Books, 1984).

Lu Hong, Scott E. Page, Problem Solving by Heterogeneous Agents (Journal of Economic Theory, 1998), http://www.cscs.umich.edu/~spage/jet.pdf

Definition of groupthink on Answers.com

Five Scrum Short Stories

By Marko Majki

When I was first introduced to Scrum, I thought "What an easy and beautiful way to be efficient!" After years of doing Scrum, I found that it’s not that easy. It was easy to learn. And, as many times before, “easy come, easy go” was true. It was very easy forget easily learned facts of Scrum. I’ll tell you about some of the traps me and my friends experienced during Scrum implementation. Solving these was more or less successful, but if you recognize at least one of them in your environment, which you weren't aware of before, my article was a success. I will tell you five real stories about people who were on the edge of Scrum and how they succeeded in avoiding Scrum traps. My Scrum heroes' names have been changed to protect their identity. Let's begin.

Proxying Product Owner

"Beware of the ScrumMaster who thinks that he can permanently assume the Product Owner role," I would say. I've heard a similar saying before, "A good ScrumMaster can handle two teams and a great one can handle only one." If you try to do the ScrumMaster and Product Owner role at the same time, you're doomed. You won't be able to perform both roles correctly – that’s certain.

One day, Scott was told at the very end of a Sprint that the Product Owner on the project had to move to another project that had stalled. He was told to act as Product Owner proxy for some time. Scott and the team were in a highly dynamic and quickly changing business, and it was a pretty tough period for the team. The first issue Scott was facing was time. The Sprint was one week long, and he did partially succeed in resolving impediments and barely succeeded in preparing acceptable user stories during the first Sprint. The second Sprint was a total disaster. Impediments started to pile up, and Scott didn't succeed in preparing acceptable user stories. The Product Backlog was filled with a few essays, without good, smaller user stories. And Scott was a pretty good problem solver. He would have certainly been a great Product Owner, if he was focused only on this role. Simply, Scott didn't have enough time to do both roles well for the team. Another issue Scott experienced was context switching, but maybe this is the wrong term. A better term is perspective switching. That was very stressful. At one moment Scott was trying to solve impediments and at another trying to figure out which story would return the investment in the best way. How did Scott deal with this? He didn't. He told the stakeholders to delegate a new Product Owner. Even a non-experienced Product Owner is a better solution than a ScrumMaster acting as Product Owner proxy. Luckily, Scott's Product Owner returned and he was able to keep Scrum on the track.

ScrumMaster as a Team lead

Claire had a pretty strong technical background on system administration, networks, and Java software architecture/development. Top management considered this to be a great asset to the team she was supposed to serve as a ScrumMaster. Because top management had a foggy understanding of Scrum, Claire was considered to be a “Team Leader.” Claire was the most experienced programmer in this team, but didn't even have the role of developer. The other team members were really great developers and quick learners, but new to Scrum. They didn't quite understand the nature of her engagement in the project, even though she had tried to be pretty clear about her role. They knew Claire before this project and had respect for her as a developer. I suppose they expected her to deal with technical issues using her remarkable experience. This asset started to become a great burden for the team and for Claire personally. She knew that if she got deep into coding she wouldn't be able to act as a good ScrumMaster. The first Sprint Planning Meeting started, but when technical debt was discussed, everybody looked at her, expecting her valuable opinion. She remembered something that she heard once from a more experienced Scrum Coach. She asked the team to excuse her for some time and to continue the technical discussion without her. They were surprised, but after she left, they did continue. After some time she returned and they barely noticed her. She was satisfied with the result. When the meeting was finished, she asked the team if everything was ok and how they decided to address technical solutions. Everything was fine and the team was satisfied because they handled everything themselves. She suggested that they would feel better if they made decisions on technical stuff, and that they were very good developers. “Of course,” she said, “I'll give suggestions if needed, but I'm not supposed to make decisions. The team has the power to decide. My job is to serve the team and to be sure that the project and work are running smoothly.” Claire made an "impediment list" sticky note on the wall and asked the team to give her tasks whenever they wanted, no matter what issues they might have. Then they really understood her role on the project.

Support Departments Don’t Use Scrum

Robert was a Scrum Coach for a software department that developed in-house projects. They had used Scrum for almost a year, and were doing a great job. When Robert came to the company, the department was pretty messed up, but in a few months everything fell into place and the teams became hyper productive. This was recognized by top management, teams were regularly awarded, and everything was fine. But Robert was a little worried. At first, he was focused on the teams, and wasn't able to see the whole picture. Using Scrum, real issues were surfacing, but he was focused on the issues he had influence over, and the team was solving them. So, when impediments inside the department were minor, other impediments became visible. The first sign of trouble was that the Product Backlog was pretty empty. He talked with Product Owners and discovered that they couldn't get enough information to create acceptable user stories. “Why?” he asked. Simply put, nobody from other departments had the time to define what they needed, and when they needed some functionality, they needed it immediately. From his perspective, communication with other departments was an impediment, but he felt responsible to initiate the solution. Now, because teams were pretty self-organized and doing well, it was time to spread Scrum to the other departments. First he talked to top management about the situation in other departments and presented the idea about introducing Scrum. They hadn’t originally considered it, but were pretty satisfied with the re-organization of the software department, so they agreed. Robert explained that he didn't want to make this transition top-down, but would try with volunteers. He invited heads of each department to a working breakfast and explained Scrum, presenting potential benefits for the department using its principles. He asked them to bring a few team members to the next three meetings about Scrum. They were pretty shocked when he introduced some of the Scrum games, expecting a PowerPoint presentation. “Hey, you didn't even bring your laptop,” they said. “I don't need it,” Robert replied. After playing two games, he conducted a practice retrospective meeting, allowing the teams to reach their own conclusions. Then he helped them to make parallels with real situations that they were dealing with. It was quite refreshing and revealing for most of them. Then, he explained that Scrum was not a silver bullet, but a tool that could help them to understand the impediments and to enable them to work better. He asked them to consider it and to let him know if they would like to try Scrum in their environment. The next day, the chief of the technical support department contacted Robert, claiming that his team was overwhelmed and eager to try Scrum. "Great!" Robert said. "Let's start preparations for our first Sprint."

Disputed Definition of Done

Ulrich was a pretty experienced Scrum Practitioner. He knew that coaching a new team was going to be tough. They were all experienced programmers, but new to Scrum. Initially, coaching was tough, with much resistance and conflicts; a bumpy road that was now almost behind him. Eventually, things were much smoother because he knew the team's velocity and the team knew their velocity, which was much more important. Velocity was regarding to “DONE DONE” user stories. He remembered the issue the team had with this, their definition of done (DoD). As he explained at the very beginning, the team and the Product Owner had to reach an agreement on this. One of the guys came up with a DoD proposition, and the team and the Product Owner were ok with it. One of the items in this list was "unit test coverage of 80%." After the first few stories were "done," he asked the Product Owner to test the items from these stories. With the tool they had, it was easy to see a unit test coverage of 23%. Ulrich asked the Product Owner what he thought about that. He answered that he wasn't satisfied with that the result. "Why?" asked Ulrich. "Because these stories are not done," replied the Product Owner. "Do you need a unit test coverage of 80%?" asked Ulrich. "No, I don't know why they chose these figures, but if the team defined these, I expect them to meet these criteria," answered the Product Owner. And he was right. The Sprint ended the next day, and during the Sprint Retrospective, Ulrich announced that the Sprint had failed, which provoked a very emotional response from the team members. He explained the reason and showed them real figures on test coverage. "But why is this important? We did all the necessary tests. We didn't want to waste time unit testing trivial methods, such as getters and setters, and we didn't want to test something covered in integration testing," screamed the guy who purposed the DoD criteria. "Yes, you are completely right, but you promised something about unit testing and this was not accomplished. Could you tell me how you determined the proposed DoD?" Ulrich asked. "Well, I didn't know what criteria to propose, so I copied some from a Scrum blog, which looked great at this time." "Ok, guys," Ulrich said, "this is my failure as Scrum Coach as well and it's my fault that you didn't understand the meaning and importance of DoD. DoD is different from team to team and project to project. This is not a general standard that should be implemented in all situations. And Scrum is not a standard that can be implemented the same way in all situations. Those are tools, which help you make better software, but you need to involve your intelligence, energy and creativity to make it happen. Ok, let's do the job. Let's create a DoD acceptable to us and our Product Owner. You are experienced developers and you know everything about good programming practices. You've seen one of many possible DoD's. Let’s make new a DoD we can commit to."

Estimations in hours

Marianne was inexperienced, but passionate about Scrum. She started her first Scrum project with the team and was thrilled, anticipating her first ScrumMaster job. The team knew about Scrum and was interested in trying it. Before the first Sprint Planning Meeting, the Scrum team agreed on some conventions and one of them was estimating user stories and tasks in hours. This was the natural choice for the team and Marianne agreed with that. Estimating in user story points was awkward to the team, since they couldn't figure out how to correlate this to some real measurement unit. So they started their Sprint meeting and started estimating. They estimated all user stories and chose ones they could commit to finish until the end of Sprint. Then, the Product Owner stood up and spoke. "Well, guys, you just committed to finish user stories worth 230 hours and you have 400 working hours in your Sprint. Even if we add 30 hours for the meetings during the Sprint, still there's 140 hours in the Sprint you should commit to. Is my math correct?" "Yes, you're right," said the senior developer, "but a working hour cannot be equal to a development hour. We have to have time to think about the story, business process, architecture etc. So, coding functionality is not the only job we're working on. Development is the intellectual process, not an exact, simple operation. We really didn't underestimate, in my opinion, and we didn't want to „steal‟ some time. I just feel that we cannot commit to more than we already did." "Ok guys," continued the Product Owner, "I believe you were honest with the estimations and I think that this is a fine velocity if you meet those commitments with your definition of done. I just can't figure out this difference and it would be difficult for me to explain this to the stakeholders." It was good timing for Marianne to do some facilitation work. "The way I see it," she said, "we have a problem with the measurement unit. The Product Owner is satisfied with the features to be developed in this Sprint, but somehow user stories measured in hours don't provide the real information, correct? Furthermore, this difference in time is causing confusion. If developer hours cannot linearly correlate with real time, why don't we say points, not hours? After a few Sprints, we will be better in our estimations in these points, correct? And there will be no confusion with working hours and time. After a few Sprints, we will know our velocity in these points and will have more experience in estimating work. Stakeholders will get their graphics in these points and will be able to monitor progress daily. What do you think?" The Product Owner was delighted with this idea, knowing that he'd be able to show diagrams to the stakeholders in real time, and the team was relieved from the pressure they felt after Product Owner's speech. Marianne scored her first small victory helping her team to overcome its first impediment and potential conflict. After a few Sprints, they got used to estimations in user story points, so it came naturally to them.

I hope that you enjoyed these real Scrum stories and that you can recognize some of the situations in your everyday Scrum practice. Please comment on them and comment on how you would deal with these situations.

The top six technical practices every Product Owner must know about

By Mikael Boman

So, you have made it. You are the Product Owner of the company's flagship product. Now you will spend your days thinking about business value and customer satisfaction, and leave all that technical stuff to the development team - you never understood it anyway.

Unfortunately, you're not off the hook so easily. In order to correctly prioritize the product backlog, you need to be aware of some of the technical items that will need to be included there. You need to understand the value of these items and recognize the terms the development team throws at you. Or worse, if the developers do not throw these terms at you, you will need to demand that they start using the technical practices you deem most valuable to your product.

If you recognize yourself in these first two paragraphs, this article is for you. I will explain the most important software development practices that you should know about. You need to know them, so you can understand their value when the team asks to take time in a Sprint to work on some of them, or you might need to put demands on the teams to introduce one or more of them to make your product even better.

This collection is by no means complete, but it includes the things I have encountered the most often in my career when working with development teams and Product Owners. The list of practices is highly influenced by the Extreme Programming (XP) practices, but the practices are presented and grouped a bit differently to reflect my view on them.

Practice #1: Version control system

This is something that almost every project team already has in place - if they don't, your product is probably in big trouble. What a version control system (VCS) provides is a place to store all versions of all files in the project, which in turn gives you an easy way to go back in time to previous versions of files when the need arises. It is, to use another common term, a system for source code management (SCM).

A VCS gives you an opportunity to, among other things, maintain a current and future release in parallel and keep track of who has changed what in the project files. It also enables you to use continuous build (more on that below).

There are several systems for handling version control, and which one is the best for your organization is a question that you, the Product Owner, probably do not need to worry about. A few examples of systems that are being used are Subversion, CVS, ClearCase, Team Foundation Server and Git.

Practice #2: Continuous integration

If you have a version control system (VCS) in place, your team should consider taking this step. A continuous integration (CI) system takes the code that has been submitted to the VCS and automatically builds a new version of the product.

The value of doing this is that you always have the latest version of your product built and ready, which allows for (more or less) immediate testing, manual or automated. You also get very fast feedback on any build-stopping problems that have been introduced with the latest code. Often the system is set up to report, via email or some other more immediate form of feedback, to the submitter of new code if the build breaks. If you have several teams working in parallel on the same product, you should have them make every effort to have the continuous integration build the entire product from its subsystems.

Another value of having a CI-system is that it forces the team to create a fast and automated build process. You will no longer have to be in the situation where the team says it cannot release the product because "only Ron knows how to system, and he is out with a cold for the week" or "sure, we can build a new release for you to test, but you have to wait for three hours because of all the manual steps we have to take to build the product."

Finally you should look into automatically deploying the built product as well - most CI systems will have support for that.

There are several systems for doing continuous integration. A few examples are CruiseControl, Hudson and Team Foundation Server.

Practice #3: Automated testing

Manually testing the product usually takes a lot of time. In fact, for larger systems it is not uncommon for the testing to take longer than the development of new functionality. So to improve this common situation, we introduce automated tests.

Automated testing can be introduced at several levels of development. Closest to the code is unit testing. This is a technique where the developer writes a few lines of code that tests other pieces of the code. These tests can be written before writing the source code (called Test-Driven Development, TDD) or after writing the source code (unsurprisingly called Test-After Development).

We can also introduce automated smoke- and integration-tests. These are especially useful in conjunction with a continuous integration system - after building the product automatically you run a few quick tests to make sure the product seems to work - at least enough to start and be ready for more serious testing later.

Going further, it is of great value to introduce automated regression and acceptance tests. This is, in many cases, the most challenging thing to accomplish. But the payback can also be a lot bigger if you put in the initial effort of getting this in place. This is where most of the manual testing is usually done, and as mentioned earlier, it can take weeks and months to do this in a larger system. The regression testing is focused on ensuring the new code has not broken any old functionality, at least not any old functionality that is covered by the regression tests that are in place. The acceptance testing is done to ensure the product adheres to the requirements.

One major objection usually used by teams is that it is hard to automatically test graphical user interface (GUI) applications. It is to some extent true, but it is today quite doable in most modern software development environments. A couple of tools to have your team consider, if they are up to the challenge of introducing this, is Selenium and Marathon.

The biggest gain in quality is achieved if your team can manage to introduce automated tests at all levels. But introducing it at just one level is much better than having no automated tests at all.

Practice #4: Refactoring

Refactoring is the art of rewriting the source code so that it does exactly the same thing, but in a different way. This may sound a lot like waste, and something the developers would love to do for the fun of it, but is in fact a requirement for being able to work in an agile way with software development. You need to take some time to rewrite things that are already working, to accommodate for new functionality. The alternative would be to try and anticipate every possible functionality that may be introduced in the product, and this has been proven again and again to be a futile task - there will always be changes in the requirements while working on a product.

Refactoring also takes into account that the developers learn while building. So after building something, they will know a lot more than when they started, and can, with a little extra effort, make the code more maintainable, less error prone and more agile in the sense that new functionality can more easily be added to it.

To not continuously do refactoring, is to risk building up what is called technical debt. This means that if we just keep adding new functionality, sooner or later (most likely sooner), the team's progress will slow down due to technical limitations in the code. To be able to keep a steady, possibly increasing, pace of delivered functionality, the team needs to continuously work with refactoring.

To be able to do this without introducing a lot of bugs in existing functionality, automated testing (unit and/or regression) is almost a requirement. There is a lot of support for refactoring in today's development environments, but to do it efficiently is an art that the developers will need to learn. All you have to do, as the Product Owner, is to allow them some time to do this.

Practice #5: Simple design

Designing a software system entails deciding how different parts of the system should collaborate and how responsibilities should be divided between them. This can be done in (almost) as many ways as there are developers, and there is rarely only one correct choice. All too often the design ends up being the work of the smartest developer or architect on the team, using all the latest trends (oh yes, there are trends) in software design. Most often it is also a big up-front job, meaning the design of the whole system is done before the work of implementing any part of it has started. This leaves the more inexperienced developers more or less clueless about how things fit together, and they end up able to contribute less to future design discussions. Also, if/when the smartest developer, the one brain smart enough to comprehend the superb design of the system, leaves your company or moves on to a new product within your company, the rest of the developers are left feeling very confused and lost. They then start having a really hard time implementing new functionality within the framework of the design they do not fully understand.

To counter this problem, and to work more agile with the software development, we want to avoid doing a full design of the system up front, and instead let the design evolve while implementing functionalities of the product. To be able to do this, the team needs to keep the design simple. A simple design is more easily improved when the team learns more about the product they are building. A simple design is also easier to modify when requirements change mid-project. Additionally, a simple design is more likely to be understood by all members of the development team.

One technique that aids in making the design simple is to keep the domain model, the software implementation of the world your product will live in, defined in terminology that can be shared by everyone involved with the product - the developers, the domain experts, the Product Owner and the end users. This allows for much easier discussions - everyone can use the same terms for the same things. A lot can be learned from the area of Domain-Driven Design (DDD) about how to actually do this.

Practice #6: Collective code ownership

A quite common problem in software development is that without conscious effort, there will be parts of the code that no more than one of the developers dare touch for fear of breaking something. This makes the product much more vulnerable to that developer leaving the company or being on sick leave for an extended period. To avoid this, the team should make an effort to introduce collective code ownership.

In practice this means that there should be no parts of the code that only one developer knows. Every developer on the team cannot, in most instances, know exactly every part of the product, but all developers can be familiar with all of the code, and you should make sure to always have at least two developers that know more about each specific part. To accomplish this spreading of knowledge we can use several methods. One way is to have code design discussions and reviews at regular intervals, where developers present parts of the code to each other and discuss the chosen solution and possible refactorings. You can also make it a requirement for a developer to discuss a chosen solution with at least one other developer before it can be submitted to the version control system. A way of making the knowledge transfer automatic is to introduce pair programming. This entails two developers sitting at one computer, solving a problem together. This may sound like a waste of resources, but those who start using it often find that the quality of the code produced, and the reduced cost in time for knowledge transfer, more than make up for the time "lost" when two developers work on one task.

To make it easier for the team to actually do this, I recommend you have two things in place. The first thing is a common coding standard, to ensure developers write their code in the same way. It need not be extremely detailed, but it should at least have some commonality in how the code is structured regardless of which developer has coded it. The second thing is the simple design I discussed as practice number 5.

Final words

So now you know my top priority practices. My suggestion to you is to spend time and effort implementing them; if not all at once, start trying to implement at least a few of them. The aim of these practices is not to make the developers happier because they get to use them, which they very well might be - developers most often want to create better code - but rather to make your product better. ‘Better’ in this context meaning more maintainable and more easily changed when you have changes in your requirements. Best of luck to you!

Daily Scrum: Merely a status report?

By Vinay Krishna

Introduction

One of the important, key Scrum practices is the Daily Scrum. It happens daily during each Sprint and the entire team participates.

During this Daily Scrum everyone answers the following three questions:

1. What’s been accomplished since the last meeting?
2. What’s going to be done before the next meeting?
3. What obstacles are in the way?

Often people treat it as a typical status meeting and behave very casually, which eventually could lead to bad results.

This is not a mere status update meeting where one person (Project Manager or team lead) collects information about who is behind schedule. Rather, it is a meeting in which every team member makes commitments to each other. This has the wonderful effect of helping all team members realize the significance of these commitments and that their commitments are to each other. The meeting is not used for problem-solving or issue resolution. Issues that are raised are discussed offline and usually dealt with by the relevant sub-group immediately after the meeting. The Daily Scrum should not take more than 15 minutes.

It requires that team members are disciplined and do not discuss impediments in detail during this meeting, only ensure others are informed. If needed, they can discuss it with concerned team members separately.

Significance

One question may arise here, why are only these three questions important and not discussion about what’s new?

High visibility of progress

It’s a place where each day, team members can see the progress of a project and easily see their contributions.

Improve estimation

By focusing on what a team member accomplished yesterday, the team member gains an excellent understanding of flaws in his estimates. Gradually, it improves his estimation skill.

Self-organization

Team members select their daily tasks and they are responsible for deciding the requirements for the Sprint. This helps them to understand their daily responsibilities. Thus, it aids team self-organization, and slowly team members gain the maturity necessary to commit to something appropriately or to handle impediments efficiently.

Increase the quality

Daily communication helps to refactor the work as well as improve the turnaround time required to remove impediments. It builds knowledge and helps to quickly apply and reuse the knowledge.

Common Problems

Below are common problems that negatively affect the Daily Scrum:

Lack of a clear understanding of Scrum practices

If the team doesn’t have a clear understanding of Scrum practices, then the Daily Scrum takes the wrong shape and also takes much more time to complete. Very soon the team loses the positive effect of a Daily Scrum, it eventually becomes a status update meeting, and people change its frequency from daily to weekly.

Old mindset/habit

It’s very common hurdle. A lot of people answer these questions like they were providing their status to the PM or Team Lead and not the ScrumMaster. Sometimes team members only address the ScrumMaster while providing answers during the Daily Scrum, as if they are providing a typical status report. It has also been observed that team members often provide very generic and high-level answers that cover more than one person’s task.

Faced critical problem

This happens when a team member has faced some critical problem that has a direct impact on his current or upcoming tasks. Most of the time people start explaining the problem in great detail, which consumes lots of time.

Communication problem

Sometimes people aren’t able to concisely explain technical stuff. This is another type of communication problem.

Information about barriers shapes the discussion

It’s a common practice to engage in a discussion about barriers if someone is talking about it. That causes the Daily Scrum to change into a discussion, and others slowly become a part of it.

Start requirement/design clarification/discussion

People start clarifying the requirement or start discussing design during the Daily Scrum, because they find it very valid place to start and want to spend more time discussing.

Team is too big

If the team is big then it takes more time to complete the Daily Scrum. In this case people complain that the discussion doesn’t pertain to their tasks and want their turn to speak to come quickly so that they can leave early.

How to handle problems

Below are some ways to handle such scenarios:

Proper team training on Scrum

Plan proper training for team members or provide occasional, small Scrum awareness sessions with the team.

Reiterate the three questions

Reiterate the three questions as many times as possible to remind the team until the team reaches that maturity level.

Avoid a lengthy technical discussion

If someone tries to explain the technical problem or if it's taking the shape of a technical discussion, the ScrumMaster must stop them politely and ask to have this discussion offline. Always focus on the current Sprint Backlog while discussing tasks.

Scrum of Scrums

In the case of a big team, consider a Scrum of Scrums. It is more effective for large or distributed teams.

Conclusion

The Daily Scrum helps to improve the individual’s commitment within the team, and the team’s maturity level and self organization. Eventually it creates a self organized team with positive team vibes.

Remember: The Daily Scrum (daily stand up meeting) must finish in 15 minutes, and everyone must answer the three questions to the team.

What Would Gordon Ramsay Do? Or How I Learned to Stop Worrying and Love Difficult Coaching Assignments

By Jan Beaver

A quick Internet search turns up a large number of blog posts comparing and contrasting the approach of Scottish chef Gordon Ramsay’s restaurant management philosophy to Agile software development practices. There are certainly some parallels, although the comparisons break down when one considers Ramsay’s command-and-control philosophy in his own restaurants.

A better analogy is to compare his approach in the restaurants of struggling restaurateurs to coaching Scrum teams and the organizations in which they live.

In case you are not familiar with Gordon Ramsay, he is a highly successful chef, restaurateur, and television personality. Of his three television programs, the one I will focus on here is “Kitchen Nightmares,” a situational reality show in which Ramsay spends a week at a struggling restaurant in an attempt to transform it into an efficient, effective, and profitable enterprise. Aside from the part about spending just a week on-site, this is an adequate description of the daily life of an Agile coach.

As with most successful business people, Ramsay has a formulaic approach, but one in which the areas of nuance are nearly endless and therefore lends itself to just about any situation. His formula echoes many of the principles we Agilists hold dear: do the simplest thing that will satisfy your customer; never, ever compromise quality; work as a team; deliver in small increments, frequently; and finally, give people the environment and support they need and trust them to get the job done.

The typical setup for an episode of “Kitchen Nightmares” goes like this: Gordon arrives at the struggling restaurant around lunchtime, meets the owner or owners, orders some food and delivers his critique to the kitchen staff, observes an evening service in both the kitchen and the dining room, and finally interviews the staff and owners to find out just how close to emotional and financial collapse they really are.

After Gordon has all of the information he needs, he makes a series of recommendations, generally focused on simplifying the menu, reducing prices, changing staff relationships or, surprisingly rarely, changing the staff, updating the décor, and most disturbingly, cleaning the kitchen. While he rarely gets too much pushback on the cleaning angle, most of the staff, from the chefs to the wait staff to the owners, simply balks at changing any of the other items on his list. How much does this sound like certain coaching engagements? They know that they are failing; yet the chefs and owners refuse point-blank to embrace changes that have an excellent track record in delivering success.

At this point, Chef Ramsay uses his powers of persuasion to convince or cajole the owners or chefs or both into adopting his proposed changes. Ramsay is famously profane, which makes for entertaining television, but upon closer examination, his approach is far more subtle than simply dropping a flurry of F-bombs every ten seconds (which he does). First, if he encounters arrogance, he does everything he can to confront and overcome it. This is where the great entertainment lies. As Agile coaches, we confront arrogance regularly. Unfortunately, we cannot look to Chef Ramsay for our techniques. Maintaining the highest levels of professionalism is not optional. That being said, however, we can follow his example by working assiduously to overcome arrogance that blocks necessary change.

Another subtlety in Chef Ramsay’s approach is that he frequently encounters chefs or owners who have simply lost confidence or are so close to the precipice of financial disaster that, paralyzed by fear and uncertainty, they find it impossible even to think of changing anything. With these people he takes a much kinder and gentler tack. In the case of one struggling chef/owner who was about to lose both his prized Michelin rosette and his business, Ramsay offered encouragement, emotional support, and practical guidance based on his long experience as a chef. He uses the same approach with owners for whom it had all somehow gone terribly wrong. Nary an F-bomb drops during these encounters.

So how can we apply Chef Ramsay’s approach to coaching Scrum teams? Easy – follow his program.

First, Clean Up the Kitchen

It is truly shocking how filthy some restaurant kitchens are. A dirty kitchen simply cannot produce quality food. Scrum teams suffer from a similar malady. If the team’s work area is poorly organized or if the team is not at least mostly co-located or lacks high-bandwidth communication, it is very unlikely that they will be able to deliver a quality product. If the team lacks adequate hardware, monitors, has no team room, tries to function without collaborative tooling including information radiators, does not have automated build, test, and continuous integration infrastructure, or does not follow sound engineering practices, it is almost impossible for them to meet customer expectations. So, clean up the kitchen! As a coach, help the team work with facilities and management to get the necessary physical infrastructure in place. Be creative, particularly when budgets are tight. Many of the infrastructural impediments teams face can be overcome without breaking the bank.

Build the Team

Most restaurants that call for Chef Ramsay’s intervention suffer from severe team dysfunctions. Often there are conflicts between members of the kitchen staff, between members of the front-of-house staff, and also between the two groups. The intra-team dysfunctions make it impossible for the kitchen or front-of-house to get organized so that they can deliver quality products to the restaurant’s customers in a timely fashion. The inter-team dysfunction prevents the restaurant from operating as a cohesive organization. Ramsay’s approach is typically to attack the dysfunctions of each team first, so that both the kitchen and front-of-house work cooperatively internally, then he tackles the points of friction between the two teams.

Ramsay always assumes that the people currently working in the kitchen or front-of-house will continue to do so, but as two unified teams working in parallel to delight the restaurant’s customers. He occasionally uses external team-building exercises, but most often works with the two teams in-house to build their sense of team, mutual trust, and inter-team cooperation.

Within each team, Ramsay works to break down arrogant behavior and build individual and team confidence. While restaurant teams are less self organizing than Scrum teams, the idea is much the same, with each team member contributing whenever and wherever possible to complete and deliver each order quickly and with the highest possible quality.

Most episodes end with the staff intact on both teams after Chef Ramsay has done his work. Sometimes, however, the restaurant owner ends up sending one or more individuals packing, either on Ramsay’s recommendation or as a result of team decisions. As with Scrum teams, an individual or two who are unwilling to work in a team environment will derail the entire effort. Ramsay only has a week to rescue a failing business, so he has no time to fool around with people who are disruptive, unmotivated, or otherwise unwilling to invest themselves in the project.

The payoff, for those team members who choose to remain, is a healthy and vibrant work environment in which everyone’s contribution is vital and appreciated.

Work With Your Customers to Determine What They Want – Do the Simplest Thing That Will Work

Once the kitchen is clean and the teams are formed and beginning to understand what it means to work collaboratively, Ramsay turns his attention to the product – the menu. Most restaurant owners think they know instinctively what their customers want and express bewilderment or disbelief at the cold, hard fact that no one is buying what they’re selling. Despite his record of success, Chef Ramsay never assumes that he knows anything about the local market and, like any good Product Owner, hits the pavement to find out what potential customers want and what they’re willing to pay for it, as well as to scope out the competition. The inevitable result of his research is that market doesn’t want the elaborate, stuffy, complex – or just plain awful – and expensive fare the restaurateur has been offering, preferring instead simple, local, fresh foods, simply prepared, served in a timely manner, and at a fair price. A simple menu offering five starters, five main courses, and five deserts seems to be the sweet spot. Maximizing the amount of work not done is clearly a virtue beyond the software industry.

Deliver Early and Often to Delight Your Customers

Now that there is a quality product on offer to the market, delivery becomes the key. The food can be exactly what the market wants, but if it is delivered late and cold the outcome is certain – the business will fail. This is the point at which Chef Ramsay tunes the performance of the teams by helping with everything from kitchen workspace location and layout to front-of-house décor and design. The physical environments in which both teams operate must be tuned to ensure that there are no major impediments to product creation and delivery.

Ramsay frequently coaches the teams to communicate continuously, both internally and with the other team. He always seems amazed at how team members think they can get anything done without continuous communication and collaboration.

Never, Ever Compromise on Quality

One of the usual suspects whenever Chef Ramsay visits a troubled restaurant is the quality of the food. Most failing restaurants have severe quality issues, which of course drive customers away. Poor quality is almost always the result of several factors in combination: a dirty kitchen, poorly equipped or badly organized work areas, antagonistic intra- and inter-team relationships, lack of motivation or commitment, an excessively complex menu, use of inferior quality ingredients (although even top quality ingredients can be used improperly), and poor customer service.

With such a maelstrom of dysfunction swirling around him, how does Ramsay even begin working on quality problems? The answer is simple: start in the engine room (the kitchen) and work your way out, as described in the previous sections.

At Regular Intervals, Reflect on Your Process and Plan Improvements

At the end of the first successful evening service, which usually occurs on the last day of Ramsay’s week on site, he facilitates a retrospective session. He is much more directive than a good ScrumMaster would be in a Sprint retrospective, but the idea is very similar. He reviews with the teams what went well and encourages them to do more of those things. He also reviews difficulties and problems, congratulates the teams on overcoming them, and encourages everyone to work to improve both their own work and the collective effort every minute of every day. It turns out that continuous improvement is a priority in the restaurant business every bit as much as it is in software or any other industry. If we try to rest on our laurels, we’ll find them brown and dead before we even know what happened.

The next time you find yourself facilitating a particularly difficult retrospective, Sprint planning meeting, or any of the myriad other situations that face Agile coaches on a daily basis, take a deep breath and ask yourself: What would Gordon Ramsay do?