"Four"warned Is Forearmed

By Mitch Lacey

You are on a team that is both newly formed and new to practicing agile. Your daily Scrum meetings (standups) appear to be going well. You can see the trust building and are looking forward to your team’s first demo. The big day comes, you get in front of the customer and then the floor drops out. Your app starts acting in a way that is definitely not as intended—all because of a hidden blocking issue.

You wonder to yourself, “Didn’t we do everything right? Didn’t we ask all the right questions?” The team dusts itself off and gets ready to start the second sprint. How do you ensure that going forward the team drives out those blocking issues in the daily Scrum?

Add the fourth question.

The Story

My team, we’ll call them Eagle team, had all been individually burned on projects in the past; we were looking forward to working together because we saw Agile as a way of alleviating pains and creating a killer work environment.

On the second day of our first Sprint, we had our first team daily Scrum meeting. Our plan for the Sprint had been solidified in the planning sessions the previous day and we were ready to rock! Unfortunately, it turned out that we were about to get rolled.

We did not have formal training at the time on Scrum or XP, so we weren’t quite sure what we were supposed to do at these standups. One of the team members, Robert, asked, “OK, so now what?”  The project manager on the team, Steve, looked around sheepishly and then began fumbling through Ken Schwaber’s Agile Project Management with Scrum looking for the guidelines at the back of the book (Ken calls them rules; I like guidelines).

After two embarrassing minutes, Steve found what he was looking for: The Three Questions of Scrum. Steve said to the team, “We need to go through this list of questions.” He rattled them off:

• What did you do yesterday?
• What will you do today?
• What blocking issues do you have?

“Who would like to start?” asked Steve. The team jumped right in. Each person answered what they did yesterday, the work they wanted to accomplish today, and stated their blocking issues.

These blocking issues ran the gamut from “waiting to pair program” to things we never would have brought up in the past, such as, “It’s too hot in this little space.”  It was hot, about 80 degrees Fahrenheit. There was a lot of hardware in the little team space, so this was going to be a recurring issue—and it was one Scrum let us do something about. The team was pleased with our first daily Scrum meeting and immediately felt good about ourselves. We were communicating!

The daily Scrum meetings continued to go well as the sprint went on. The team held itself accountable and the blocking issues that were being raised, even the heat issue, were being addressed. Our happy little ship was moving in the right direction, never mind that monster iceberg on the horizon—the iceberg that only one person saw but didn’t say anything about.

The first demo meeting could not come fast enough. The team behaved like kids on Christmas Eve. We had accomplished a lot of work over the first thirty-day sprint and wanted to show it off. We prepared a slide deck, a mandatory element when presenting at this company, listing out the accomplished work, the work that was not accomplished and what it meant for the team to be done.

One of the stakeholders, Thomas, was also the executive sponsor of the agile experiments the team was running. I noticed him throughout the meeting, perhaps because his face lacked the emotion that the other stakeholders exhibited. It was as if he almost knew what was about to happen.

The team was demonstrating the last component when suddenly the system crashed; well, crash may be too strong a word, but it definitely behaved in a way they did not intend. This caught the team and the stakeholders off guard, but not Thomas. He sat there, watching the team flop around like a fish out of water, looking for answers. One of the team members, Marcelo, said to himself under his breath, “I knew this was going to happen.”

The team was astounded!  Steve looked at Marcelo and asked, “What do you mean? How did you know this was going to happen?” Realizing the entire room had heard what he had said, and hearing Steve’s response, Marcelo became quite embarrassed and looked away, not making eye contact or speaking with anyone while the rest of the team fumbled around trying to save the demo.

The stakeholders let the team off the hook and in the end, everyone had a good chuckle. The team was building a mission-critical system to support an online business for millions of subscribers. They were expected to find issues like this, early, and address them. Plus, the team was also experimenting with agile, so the communication breakdown was accepted as an early failure, but one that would not be tolerated by the stakeholders again in the project. Our failure to communicate was as critical to fix as the bug that surfaced in the system—Thomas thought it was the most important thing for the team to address to date, bug be damned!

After the meeting, I grabbed Steve and Thomas to talk about what had happened. The first question out of Thomas’ mouth was not about the system. “What happened with the team?” he asked. This clearly caught Steve off guard. Steve was confused and asked for more clarification.

“You clearly had some blocking issues that were not being addressed throughout your Sprint, why weren’t you resolving them?” Thomas said.

Now Steve was even more confused. The team had been answering the three questions of Scrum. They had raised blocking issues and addressed them. Heck, even the heat issue was resolved after $5,000 of duct work to pump more cold air into the space! Steve was convinced that Thomas didn’t know what he was talking about, and challenged him. “Thomas, I’m not sure you have all the data you need to say that.”  Steve went through the Sprint backlogs with him, showing him the work being done daily. He walked Thomas through our risk and issues log, highlighting the fact that the issues were being resolved.

Steve thought he was making a pretty good argument. Thomas held his ground, “I’m not talking about the issues that are being surfaced by the team; I’m talking about the issues that are not being surfaced by the team. Those are the real issues you need to look for; they are the ones that will cause you to have more demo meetings like you just had.”

Steve and Thomas spent the next two hours analyzing what happened. They discussed the importance of recognizing nonverbal communication and discussed techniques that would help to address it. They discussed the personalities of the team members and most importantly, tied them together. This was the “ah-ha” moment for Steve.

One of the team members, Marcelo, is very introverted. He does not like to make eye contact, often goes out of his way to avoid small talk with people and likes to keep to himself. Yet, here he was working with four other people that he had no history working with, in a team workspace, pair programming no less! He had signed up for this project based on the hope that it would go well, that it would deliver value and that it would stretch his skills. What the team had failed to realize was that it would also stretch his personality and working style habits.

Marcelo knew the team was going to see an issue in the demo, yet he never raised the concern during the Sprint. He was the proof that the team had missed rooting out the real issues that most teams encounter, like communication.

That was when Steve came up with “The Fourth Question.”

The Fourth Question

What is the fourth question in Scrum?  Its simplicity is embarrassing, but it is a valuable tool to ensure that the team is on track—especially for new teams. In the daily Scrum meeting, start with the three questions as you normally would:

• What did I do yesterday?
• What will I do today?
• What blocking issues do I have?

Now add the following:

• What is your confidence, on a scale of one to ten, that the team will accomplish the goal of this Sprint?

That’s it. Why does this work?

In the story above, what Steve and Thomas theorized, and later validated, was that Marcelo was not comfortable with conflict. He was going through the motions in the daily Scrum meeting, but he was not yet vested in the team. The trust among the team was not as well established then as it was as the project progressed.

Another factor why Marcelo was not stating what he truly felt was that other team members were strong extroverts. These people were very comfortable with conflict and, in the beginning, dominated the daily Scrum meetings. This behavior caused introverts (and sometimes the rest of the team) to agree despite their misgivings because the strong personalities would not back down.

In these scenarios, team members do not state the real issues, only surface issues. I have witnessed the implosion of teams because they were not able to root out real team issues. They stayed focused on the software, not on themselves. When they failed, and they all do, they blamed the process, not themselves. The teams that succeed are the ones that are open to change, to experiments, to trying new things. It is these teams that realize they need to improve to succeed, so they remain focused and disciplined.

The fourth question gets past surface issues and carves right down to the core issues—the ones that have long-term (and negative) impacts.

As the Eagle project progressed, and the team bond and trust became stronger, the team found that the fourth question was not needed. Individuals became comfortable with conflict, and those extroverts with strong personalities learned to “tone it down.”

Keys to Success

So, when should you use the fourth question of Scrum? I recommend using it at the beginning of any new project. Even if people know each other, they may not have built the trust required to have the open and honest conversations that ensure project success.  I’ve made it a required element for any team that is either new to itself or agile practices and principles. Eventually, the team will grow to a point where the fourth question is no longer necessary. The team will know when it is no longer needed, so the team should decide if and when it should be dropped.

When using the fourth question, look for the following:

• Nonverbal communication. What is being communicated through body language is often as important as what is being said out loud. Being aware of it and monitoring for it is essential.
• Project issues that are not surfacing. If you are going through your daily Scrum meeting without uncovering many impediments, yet during the Sprint, issues “keep cropping up,” you need to add the fourth question of Scrum. This also applies to stakeholder demonstration meetings.
• People who are not comfortable with conflict. This closely relates to nonverbal communication; however, the ScrumMaster or project facilitator may not be skilled in identifying nonverbal communication. Seek out the advice of others that have worked with the members on the team in past projects to better understand how people work.
• Opportunities to practice continuous learning. Two elements that have helped teams that I have worked on and coached are the Myers-Briggs assessment and workshop and Bolton’s People Styles at Work. Providing the team with the tools needed to stretch themselves personally and to develop their competencies will have a lasting impact on the current project and all future projects.

A Balancing Act

By Andy Brandt

A certain level of discipline is necessary to achieve organized progress. Too much discipline, on the other hand, can hinder both the progress and the quality of the results delivered by the team. This is especially true for creative work such as software development, in part because of the personality traits of people doing it. Software development attracts a certain kind of individual: somebody with above-average intelligence, an above-average ego, a few weird interests and personality quirks, an obsession with tools, and a love for the art and craft of building software. It’s no wonder that managing a team of developers has been jokingly compared to herding cats. The manager constantly has to strike the right balance between discipline and freedom, separating what is crucial and must be monitored closely from what is incidental and can be left up to the team.

Agile processes, which make visible what is most important and truly necessary for orderly progress, can help with achieving this balance. Scrum’s “daily scrum” instills discipline by requiring a fifteen-minute daily meeting where each team member shares what they have completed, what they are working on, and what obstacles they are facing. Other than that constraint, though, Scrum grants the team the freedom to decide how they will work to achieve the goals they committed to during the sprint planning. The tight pressure of a release date being no more than three weeks (the length of one sprint) away is usually enough to ensure people organize their work day in a most productive way. Technical-level agile practices such as XP or TDD are strict about how the code is being built or what it should look like but are flexible about the what and when—decisions of this nature are left to the team and to the individual developers.

This is how we work at Code Sprinters. We maintain a highly disciplined process but allow plenty of freedom, both in choice of tools, office rules, and in adding project-specific guidelines to our universal standards.

Tool Choice

I've seen comments that “lack of unity in tools” is a bad thing; I strongly disagree with that. Diversity in tool choice is a sign of a good, creative team that focuses on what is important rather than trying to appear organized by standardizing the incidental. We don't force our developers to use the same tools. They can use Windows or Linux (I wish we could afford to give everyone a Mac as an option too, but this is not possible yet) -- whatever distribution of Linux they want. They can use a company laptop or their own. They can use an IDE (e.g., Eclipse) or they can use traditional but powerful tools such as VI or Emacs. Why? Because to create quality software, the developer must feel comfortable with the tools he uses. Forcing everybody to use the same standard tools would be as wise as forcing them all to wear the same size shoes.

We do have a minimal set of tools everyone has to use, but all are independent of a particular OS/platform. We all use our Scrum tool to plan, manage tasks and update progress, and register impediments. We require everyone to have Skype running on their laptop to stay in touch with others and clients. Everyone must use company e-mail and calendar, our SVN repositories, project wikis, and so forth. But this is hardly the level of standardization that, regrettably, has been reached at many other companies where everyone has to use the same version of Windows on identical PCs, staring at the same IDE.

Relaxed Atmosphere

In the same way that we don’t mandate tool use, we don't strictly enforce working hours. What we do enforce is presence on the daily scrums -- everyone on a given team has to be there and there are penalties for being late. While being in the office is expected and encouraged, there are no set hours. We have people running in just before the Daily Scrum and people who arrive in the office early in the morning morning. Surprisingly, even without a mandate, whole teams usually sit together in our "war room." It seems that making it both enjoyable and palpably productive to be in the office works much better than enforcing presence.

Universal Standards

Finally, there are certain standards that are applied universally across our organization. These include coding style, test coverage, the way the repository is to be used (what is acceptable as commit and what is not), and the proper procedure for starting a new project. We do not waver on those definitions. However, teams working on a given projects may (and frequently do) add to those existing rules additional standards that for their particular project. A good example is the release procedure, which looks different in each project and ranges from just tagging the release in the repository to working with the client's server(s) to actually putting the new release in production.

Our approach – strictly enforce a few key things; be relaxed on others - has worked extremely well for us. It gives us the discipline we need but allows us the freedom we crave. Following it to the letter may not be practical for every team, but achieving balance should be part of good practice on any agile team.

Scrum Meets Waterfall

By Dave Prior

Editor’s Note: You can choose to view the video or read the transcript (provided below).

Dave Prior: Hi. My name is Dave Prior and I’m chair of PMI’s IT & Telecommunications SIG … About a week and a half ago, I was fortunate enough to be able to attend the 2008 Scrum Gathering in Chicago. It’s an event where about 250 practitioners of Scrum get together to share ideas and thoughts about what’s working, what’s not; ways to promote it, bring in other agile practices; how to make it just all around better. I wasn’t really sure what I was going to experience walking into it, being as I’m a PMP-certified, waterfall-background project manager. But I was very, very surprised and happy to see that it’s not just [a bunch of] developers and agile-minded developers who hate waterfall guys. There was an even mix of project managers and software developers; a fair amount of PMPs [and] non-PMPs who consider themselves project managers. But overall I found the environment to be very welcoming and friendly, which was a nice thing because I wasn’t really sure that was going to happen. I learned volumes at this event and if you get a chance to attend this or one of the agile conferences, I absolutely recommend it. It was a great, great learning experience.

While I was there, I had an opportunity to sit down with Mike Cohn. If you’re not familiar with Mike, he’s one of the rock stars of the Scrum world. He’s one of the founders of the Scrum Alliance; [at the time of this interview he was] serving on the board of the Scrum Alliance.  He runs Mountain Goat Software and he is also a Scrum certification trainer who teaches all over the place. I took Mike’s class last year and it was a great time—I got a lot out of it.

When I sat down with him, one of the first things that I asked him was, “For a project manager who is just coming into the agile world, just kind of becoming aware of it, what is the best place, or the best way, for them to get started understanding what’s going on and how can they break themselves free of that waterfall mindset that would basically lead them to believe that a lot of agile practices are basically taking your hands off the wheel and seeing what happens?”

Mike Cohn: Well, I am associated with the Scrum community, as you mentioned I am a founder of the Scrum Alliance. One of the things I like about Scrum is that it’s a good place to get started. Scrum is kind of the default agile process in a lot of ways—it’s been around the longest. I like that it is the lightest-weight kind of starting point. We don’t start out by mandating you do twelve different practices or anything like that. Scrum, at its heart, is really just about getting a team to be iterative and once you’re iterative then moving towards becoming agile. So I really like Scrum as the starting point. Although, as much as I like Scrum, my preference is actually for what I call unbranded agile. I just kind of wish all the brand names would go away—Scrum and XP and Crystal and everything else—and we just call it agile software development, or even better just call it software development. But for now, we still have the brands and Scrum is the right starting point in my mind.

In terms of getting started with Scrum, Ken Schwaber has three great books out on Scrum. But what I really like is for somebody to read one of those and then go to something like a class. I’ve always thought that I could do a great two-hour Scrum training class if I could get somebody for one hour at the end of one day and then one hour at the beginning of the next day. There’s something that happens when you sleep on it over night. You know, I couldn’t do a two-day class and get somebody’s mind changed, but if I could get them to get the right things, kind of sleep on it and come back the next day, I think you could kind of start shifting your mindset away from traditional thinking towards a more agile mindset.

Dave Prior: I took Mike’s Scrum certification training in Dallas last year and I was the only project manager in the room, which surprised me, I was sort of expecting a lot more. And I asked him, generally when he teaches a class, what is the mix? Is it mostly developers, mostly project managers, or maybe a mix of both? Here’s what he had to say about that.

Mike Cohn: Well, the mix is really different. If I teach a public class (you know where I rent a hotel and invite people to just show up in my classes), the mix there is probably 70-80 percent on the management side. It’s either a project manager or it’s a tech lead who soon would be a project manager, kind of thinking in the traditional way, and a few developers that show up—but typically skewed toward a people who are in leadership or management positions at the public classes.

When I’m invited into a company to talk, one of the ways I structure the classes and just do my pricing with companies, is I want everybody there—it might be three managers and twenty technical people there—because I’m trying to get the whole team mindshift to happen. Earlier, when I started doing this I’d have companies that would say, “OK. You price per person, we’re going to leave the testers out.” I’d say, “No!” Right? And so I would price per day, right, with people, because I want the whole team there. … Otherwise, people don’t hear it. One of the things I’ve found with training, having been doing this for a long time now, is I have to be careful with what I say because people will hear the one sentence they hear, they doze off from the rest, and you’re quoted back the one sentence out of context that--people hear what they want to hear. And so I really want all the groups there. So when I go in to work with a company, that’s how I set it up, I want everybody there.  So I typically don’t just teach just a management class inside a company. But those choosing to come to a public estimating class or ScrumMaster class, much more on the management side.

Dave Prior: One of the projects that I’m working on right now is a Scrum project that’s being run inside a  waterfall organization. So everything within IT is happening from a Scrum perspective and that’s going off like gangbusters. But we still have to find ways to communicate with the folks upstairs, the people who want to see Gantt charts. And Scrum’s great, but they have to able to know when everything is going to be done.

Obviously there’s a lot of conflict there and one of the challenges that I’ve had in working on it is trying to find a way to come to grips with the fact that, yes we’re doing an agile practice or Scrum, but we’re doing it in a place where we still have to be able to answer to people who want to see a Gantt chart or a network diagram. So I asked Mike if he had any tips for project managers in a similar situation. How do you address that? How do you deal with the fact that you are doing an agile methodology inside an organization that is anything but?

Mike Cohn: There are a lot of myths in agile about things like, you know, “documentation is horrible.” Documentation is not horrible, right? The Agile Manifesto says we value working software over comprehensive documentation. It doesn’t say get rid of all documentation. And a lot of agilists are opposed to Gantt charts and things like that. Those are mistakes. Gantt charts are wonderful communication tools. So I don’t go in and want to try to change how a, how a company looks at things.

I was working with one company that had maybe twenty projects going on; they were experimenting with agile on two of them, and when I got there the two agile teams were trying to change the, kind of the, dashboard reporting that their VP wanted. I was like, “No. You’ve got eight teams doing it the other way, eighteen teams doing it the other way, you figure out a way to make yours look like theirs. “ Right? You don’t have to go in and change all those things as part of this initial battle. Again that’s part of starting in a lightweight manner and kind of pushing to constantly improve.

So a thing like Gantt chart is an absolutely wonderful way to communicate; it’s a horrible way to do day-to-day management. I’ve always had an issue [with a situation where] a project manager would walk in and say, “It’s Tuesday. The Gantt chart says you’ll be done with this. I don’t know what ‘this’ is but where’s you’re corrective action plan because you’re not done?” Right? None of us think that’s a good way to go. But as a way to communicate overall progress and just kind of map out high-level expectations, it’s wonderful. So I don’t necessarily look to change a lot of those things.

Dave Prior: In places where I’ve worked where agile has been a part of the mix, it’s normally been introduced by somebody from the development side. And walking into that situation as a project manager who is certified in being able to do things from a waterfall standpoint, it’s a little bit of an uphill battle for me, especially because you don’t have a developer background.

So I asked Mike, walking into that type of situation, if you’re a project manager and you’re not a software developer, how do you overcome that? What steps can you take to kind of even the playing field so that the developers who have brought agile in, or turned to it, turned to Scrum or XP or whatever it is, how do get yourself raised up to a level where they see you as an equal as opposed to the waterfall guy who is just going to be in the way?

Mike Cohn: I think if we make up a list of all the desirable attributes of a, kind of an agile coach or what Scrum teams would call a ScrumMaster, on a project, certainly having the knowledge of how to do the job is on the list. Right? I mean, I would love to have, even in a traditional world, I would prefer to have project managers that have done the job in the past. It’s going to help you when the team says, “ten days,” when a developer says, “This’ll take ten days.”  And if you know something about it you might know, you know, “Is it really going to take twenty and this developer just isn’t seeing part of the problem?” Or maybe you’re looking at it thinking, “[wow] ten days is kind of  a long time for that … is he sandbagging…what’s going on?” So having technical knowledge of things is certainly a desirable attribute, but there are so many other things that need to happen on the project, that that’s just one of many factors for me.

I mean, I’ve hired plenty of project managers into agile teams that did not have a technical background, a coding background. Right? They knew how to manage people; they knew when somebody said ten days they could look at their body language and other things. You know, is the guy confident in that? Is he kind of looking down at his feet? Those type of things that help you make up for that. Just knowing people is a big advantage there. So to me, technical ability is just one of many attributes-- love to have it, but to me it’s not a make or break aspect there.

Now in terms of the project manager, I don’t typically see a project that needs both a project manager and a ScrumMaster. Right? Typically the project manager becomes the ScrumMaster if they have that type of process and impediment removing desires. If the project manager is somebody who’s worked in that company or that domain for a long time, and they really know something about the product or customers, they shift into more of a product owner role, defining what we’re going to build. A lot of times, project managers shift in either direction.

Dave Prior: And if you want to find out more about Mike, here’s where you can go to learn more about him, Scrum, Mountain Goat Software, all of it.

Mike Cohn: The easiest place to find out about me is www.mountaingoatsoftware.com. … I’ve got a ton of presentations up there; every time I teach at a public class like this, I put my slides up there and sample chapters from books, and things like that. Good site to [visit].

New Version of ScrumEdge’s Online Scrum Tool is Live

We are pleased to announce that a new version of ScrumEdge has been released today. We have added many new features in this release and resolved some issues reported by our users.

We have done away with the old interface and come up with a completely new and more intuitive interface. Among other things, you will notice that this version will give you a lot more screen space to play with.

 
Major Updates:

• Interface: We have done away with the old interface and come up with a completely new and more intuitive interface. Among other things, you will notice that this version will give you a lot more screen space to play with. The use of smaller fonts should make text more readable and information has been organized such that users can view all project related information without having to navigate through too many pages.
• Story and Task Efforts: More detailed Story and Task Effort level reports will allow ScrumMasters and Product Owners to follow their sprints in more detail. ScrumMasters and Stakeholder can view these details on the Product Backlog and Sprint pages
• Free 30 Day Demo: Users can sign up for a free 30 day demo. Simply click the “Free Online Demo'” button on the main page.
• Setup Wizard Removed: We have removed the ‘Setup Wizard’ as many users were having problems running it. Instead we have added ‘Tips’ on most pages to help users navigate their way around the site.

Well-Formed Teams

By Douglas E. Shimp and Samall Hazziez

In the agile space the notion of the well-formed team (WFT) has been discussed by Team Capital. The purpose of a WFT is to have a team thrive in a direction ideally set by business vision. When directed towards business vision, a WFT becomes an innovation engine of extraordinary value.
A mature WFT is an indivisible unit, a self-organizing, learning engine of effectiveness, not merely a collection of individuals. Such teams rarely emerge by chance; a WFT is often intentionally formed with an understanding of the inherent value of such a team in mind. While agile provides pathways that can increase the chances of such a team forming, WFTs are not unique to agile.

Enabling the WFT

Certain processes and enablers, when applied with care, can pave the way for a WFT to form: Scrum, Lean, and XP are examples of agile processes, while from the more traditional processes come RUP, PMBOK, and Classic SDLC methodologies. Some enablers come in the form of assessment instruments for the organization and individuals, such as audits, Myers-Briggs, or agile assessments. Classic environmental enablers include things like collocated space, team rooms, training rooms, visible charts, and white boards. All of these processes and enablers have good qualities, tools, and ideas in them. However, these same processes and enablers regularly get over-complicated or misapplied. People are often loaded down with devastating amounts of information, which cripple an individual’s ability to think clearly. We can easily become burdened by frameworks, esoteric language, principles, or practices that clutter our minds and focus our attention on the wrong things.
What you focus on matters. All too often process, principles, and practices become a crippling focus. On the other hand, when processes and enablers are applied appropriately they can result in a group of people working very cohesively together (i.e., a WFT). Our goal becomes creating WFTs that are deployed to business’ needs. WFTs are how businesses can realize opportunities to thrive.

Explaining WFTs: 3 + 2

We have found some easily acquired language that helps make individuals and teams reason better collectively. We call this useful language “attractors for effective thinking.” Our goal with these attractors is to help WFTs behave more instinctively as a unit as they make decisions. The name of the game is to avoid and eliminate confusion while bringing a team’s unified, collective intellect to bear, in a highly focused manner, on business problems.
We have broken things down into “3+2” as an easy way to remind ourselves and help the teams we work with.

3 Attractors

Let the product lead

Pay attention to the needs of the product. As we consider adopting a new practice or idea from our process we ask ourselves if it serves the needs of the product. Or, said empirically, the product is your best source of reality to give you feedback as to whether you are making the right decisions and having the right conversations.

One bite at a time

Each item of work should be broken up into small enough pieces to eat. Most teams and individuals will bite off far more than they can chew. We are constantly working with teams to break the work down into manageable pieces that can get done in short time-boxed cycles. Short cycles that roll-up into hourly, daily and weekly rhythms begin to emerge as a good pattern for managing the work.

Keep it visible

This is one of the most obvious things to do yet it is rarely done well. Without visible pieces of work or a map to that work, we cannot see where effort is being applied. When we cannot see where to apply effort we flounder and do not work together. When the work is a physical thing like digging a ditch it is easy to see where to jump in with a shovel and help out. However, in the land of ideas or software work much of the work is not easily visible and therefore self-organization is inhibited.  When we make our work visible, we reduce the risk of disappearing for long periods of time and not producing anything. With visible work efforts we improve the chances that our next conversation will be the right one and make reporting on team progress a breeze. Great teams work together by keeping an appropriate amount of visibility.

+ 2 Balances

Conversation and Structure

Conversation and structure are used to achieve balance within the three attractors for effective thinking. Structure is added through process, product, physical location, and focus. Conversation requires enough structure from an established protocol so that we can communicate effectively. This communication protocol can be setup by formal or informal process (e.g. an agile process) language agreements, team location, and more. Conversation is necessary for humans to establish rapport so that we can create, contribute, and share deep, meaningful understanding. With conversation we can help each other detect if understanding is there. With structure we have an idea of what the next most important conversation to have is.

Recognizing WFTs

So, what does a WFT look like? To help answer this question we have listed some of the more common characteristics found in a WFT.

• Most WFTs emerge most easily from a collocated environment. We suspect that the reason for this is that critical mass team understanding is difficult with the technologies currently implemented to achieve a WFT in a distributed manner. We simply cannot achieve the high-bandwidth communication necessary to form the deep state of rapport that a WFT will exhibit when its members are in close proximity for a face-to-face conversation.
• WFT members show a high state of rapport and an ability to achieve that rapport rapidly. For example, they fluidly stop and start sentences as though speaking with one mind.
• Members actively contribute thoughts and share ideas to the group and do not egotistically claim ownership for those ideas.
• WFT members personally feel safe when the team is safe. Team members will do whatever they can for the sake of the team’s welfare.
• Team members self-organize frequently in twos and threes as the work is broken down and pulled in by the team.
• Team members often brainstorm as a group.
• Members self-assign work and pull new work assignments.
• Members have good line of sight to business objectives and work according to business value-added priority.
• WFTs spontaneously create a personal identity.
• Members put the good of the team ahead of their own personal goals.
• The team behaves as a local “marketplace of ideas” by actively contributing ideas. As ideas are contributed, the team grows, polishes, augments or kills the best ideas; the individuals who initiated those ideas do not feel slighted. Team members feel not only accountable but empowered to use their creative intellect to move the end product forward.
• Members pickup and quickly acquire new skills by helping each other learn.
• WFT are learning engines who tenaciously seek to acquire the knowledge they need to succeed in their objectives.
• Members do not seek to make themselves a skill or knowledge dependency. Team members will work closely with each other to have redundant skills whenever possible and share knowledge quickly.
• WFTs demonstrate productivity rates that are four or more times greater than industry averages; they are hyper-productive.
• Members leverage each other’s diversity to create innovative outcomes.
• Members challenge one another to bring their best.
• Teams are not conflict free. Instead they have constructive conflict marked by passionate struggles or learning aimed at better outcomes.
• Energy, excitement, and passion have an almost palpable feel in the team environment.
• WFTs move with a single purpose to focus their energy and burn holes through complex business problems.

Conclusion

Many of today’s business opportunities are in complex development landscapes; in other words much of the low-hanging fruit has been picked. Businesses are increasingly challenged with rapidly changing market landscapes. What we need are rapidly adapting development services. We see the WFT as the key to providing that service.
There are many agile pathways (e.g., Scrum, Lean, and XP) that can result in a WFT. No one pathway is necessarily right or wrong; we see pathways as a way to get and sustain a WFT. WFTs are basic assets that individuals, businesses, and organizations need to help them thrive.

Production Support and Scrum

By Geoff Watts

Teams adopting Scrum not only have to deal with the normal project complexities of prioritization, estimation, and turning product backlog items into potentially deployable increments of functionality, they also often have to support a system in production or address bugs that come back to them during development. How do we track and prioritize these support activities? How do we handle emergencies? Who performs production support?

Bug of the Day

Production support can be seen as a disruption to teams that just want to get on with things but is often very dear to the heart of the system users and, therefore, the Product Owner. It can be a tricky issue to handle as it adds an extra degree of complexity to the prioritization debate. Often teams will be asked to take an approach of “production support is a necessity, so just deal with it.” After all, if the system is down, what is the point in adding more features to it? The priority must be to get it back up and running straight away.

However, this approach to production support can’t be planned—just dealing with it as it comes up can lead us away from the most appropriate decisions as we get caught up with the “bug of the day” scenario. It’s easy to lose sight of our vision and strategic plan by just dealing with whatever the latest system problem is.

Scrum asks us to prioritize our effort, sometimes making difficult decisions to create maximum business value as early as possible in order to help us achieve our strategic goals. One of those difficult decisions may be to question the relative value of fixing bugs against adding new functionality. Just like our initial instinct when faced with a user story that helps us comply with a new law might be “we have to do it, it’s the law,” there might be a scenario where, from a business perspective, the fine for not complying with the law is less than the value obtained by implementing an alternative story. This is a difficult decision, but arguably the right one for the company. Applying this theory to the area of production support, we might prefer to live with an inconvenience and have a new feature than fix that problem right away. We should at least consider the relative merits.

If we follow this route, there is a perceived risk that our bugs will never get fixed. I understand that concern, but in my experience, that risk doesn’t become a reality. There still remains the concern of how we plan for production support. I have seen teams deal with the issues of production support in different ways.

First Steps

The most common solution teams employ initially is to effectively have two backlogs—one for development features and one for production support issues. The Product Owner sets a guideline ratio for planning whereby the team will take, for example, 70 percent from the development backlog and 30 percent from the support backlog. This is arguably not much different than the team just reducing their capacity to account for support tasks and is effectively hiding the issue, shying away from the conversation around priority and increasing the risk of spending effort on sub-optimal work.

In this scenario, because production support is usually not in the easily estimable form of user stories and often crops up during the sprint, teams will have a burndown for their development stories and a burnup for their production support. The team can then review their feature/bug ratio in the daily scrum thus allowing the team to raise issues and tradeoffs with the Product Owner. There is a risk of burning through all production support before the sprint ends but the shorter the sprint, the smaller the potential impact of such a situation.

Bugs as Feature Requests

In the above scenario, teams placed production support items onto a product backlog, with an associated business value and size estimate. This begs the question, why split the product backlog into two? By combining the two backlogs, we can explicitly confront the issue of whether we are doing the “right” things, which is ultimately preferable in my opinion. While this involves more complexity from a Product Owner point of view, it allows the team to concentrate on what’s important. The opportunity is still there for the team to pick synergistic items to maximize overall value, which leads us to another interesting way of dealing with production issues.

A number of teams add existing production issues as acceptance criteria of functional user stories so that when a team opens up, or touches, that area of the system we have some pre-existing tests for when that feature is “done.” The added benefit here is that some of those bugs that might never have gotten fixed if prioritized on their own get addressed while the team is focused on the most important features. Ideally, any new problem will be defined in terms of acceptance tests that need to pass; these will then become part of the evolutionary design documentation of the system.

The key here is to try to avoid getting into an argument over whether something constitutes production support, a fault in development, or a change request. This is easier said than done but teams that can absorb this discussion rather than draw absolute lines will be the more effective and productive teams. Finding out that the acceptance criteria pass but the feature isn’t really potentially deployable should neither be an opportunity for the Product Owner to introduce scope creep nor the development team to hide behind a requirement spec (“you asked for this”) but rather an opportunity to be pragmatic and, most importantly, learn about what we did so we can improve the system and our test coverage for future stories.

This is additional valuable information. If production support issues come up, it usually means we missed something (perhaps an acceptance criterion) in our initial development. This is an opportunity for us to increase the test coverage of our system – a vital part of the team inspecting and adapting and maintaining (and increasing) the integrity of the system.

Emergencies

We still have the issue of what to do with the emergencies that crop up and aren’t part of the product backlog. The ScrumMaster or Product Owner should assess whether the issue is an actual emergency.  By working in sprints we are reducing the wait time before we can plan to work on these items, often resulting in those “critical items” becoming not quite so critical.

If the issue is a true emergency, the Product Owner should have the authority to play the “emergency card,” as long as he is aware of the costs of doing so— not completing the items we planned to and, potentially, jeopardizing the sprint goal. If this happens frequently, then it might be worth considering a maintenance sprint to clear up some of the technical debt that might be causing a lot of these problems. Another option is also to shorten the sprints, thereby reducing the potential waste in these scenarios.

Who Does It?

The other issue of planning for production support is deciding who will do it. Production support issues are considered “boring,” so there is often a reluctance to sign up for them. Assigning someone (or even a pair) as the “support person” is not a popular idea and having a “support team” causes an unnecessary split along with the associated confusion. There are a number of benefits to not splitting the team, not least of which is the synergy of keeping all efforts within a sprint and, probably most importantly, the sense of responsibility the team has for a system that it not only develops but also maintains—the team is acutely aware of the impact of getting things wrong.

Some teams will rotate the support role either on a sprint-by-sprint basis or weekly basis, coupled with a rule of “if you start it, you finish it.” This can also have the secondary benefits of expanding the overall knowledge of the system for all team members and increasing cross-functionality within the self-organizing team. Doing this is difficult and will take more time if the team members are highly specialized in their particular skillsets or areas of the system but, arguably, this is a risk that could benefit from being managed proactively anyway.

Different options are available for teams to deal with the issue of production support and, although there is no “right way,” I have seen the biggest benefits accrued by teams that look at production support and feature requests with equivalence. I am very encouraged when a team is willing to take the challenge of confronting the prioritization issues of bringing support issues on a par with the development backlog items, thus sticking to one product backlog. These teams look for opportunities to improve the system as they work on it and use production support issues as already-written acceptance tests. This approach not only gives us the greater likelihood of doing the “right” things but also shows the team is up for the potentially difficult decisions during its journey towards a more agile way of working.

The Hills Are Alive with the Sound of Scrum

By Paul Goddard

I am always on the look out for new and interesting metaphors for the use and benefits of Scrum specifically and an agile approach to delivery in general. As a keen and almost-able musician myself, the title of Mike Cohn’s recent article, “Leader of the Band,” got me thinking more about the parallels between agile and music: both in its composition and its performance.

Creation

I do not profess to be skilled in composition or arrangement of music. I can, however, imagine how a composer visualizes a piece of music before it has been completed. Before he has written a single note, a music composer must have an idea of the style, structure and mood of the piece he is about to create. He starts with that vision. So, too, must a Scrum project begin with a theme or picture of what ultimately will be delivered.

In music, this vision comes from many different sources. Compositions can be written to mark a specific event, reflect a particular emotion or experience, or to convey a particular mood in a play or movie. Historically, many classical compositions have been written to mark specific events. For example, Piotr Ilyitch Tchaikovsky’s 1812 Overture (1880) was composed to commemorate the unsuccessful French invasion of Russia in 1812, a major turning point in the Napoleonic Wars. Tchaikovsky’s clearly had the intention of building a classical masterpiece that portrayed the increasing magnitude and frenzy involved in the final stages of battle. Other pieces of classical music have been written to encapsulate a composer’s own thoughts, experiences or emotional state. The Symphony No. 9,  From the New World, popularly known as the New World Symphony, was composed by Antonín Dvořák in 1893 during his visit to the United States from 1892 to 1895. In an article published in the New York Herald (December 15th, 1893) Dvořák explained how Native American music had been an influence on his vision for this symphony:

"I have not actually used any of the [Native American] melodies. I have simply written original themes embodying the peculiarities of the Indian music, and, using these themes as subjects, have developed them with all the resources of modern rhythms, counterpoint, and orchestral colour."

- Antonín Dvořák

In some cases, composers are asked to write a movie soundtrack that encapsulates the themes of the motion picture. Good examples are the iconic works of John Williams (Star Wars, Jaws, Superman) and the more sedate film scores of James Horner (Titanic, Braveheart, Apollo 13). In these cases, the film director has a great deal of input as to which parts of the soundtrack are added to the film structure to improve the final product. He must work closely with the composer to ensure that his own vision is realized, in most cases working with only the movie’s script, rather than the visual elements of the motion picture. In all of these instances, a clear project vision gives structure to what the composer will create. The project has a purpose: deliver something that will make people feel, remember or understand a particular mood, experience or event.

In software development, the vision usually comes to the team from someone like a film director: a product owner. The product owner gives a clear picture of his goals and writes, or helps to write, stories that describe the things he’d like to have in the final product. Working collaboratively with the team throughout the project, he guides the team toward the creation of a product that fits his, or the organization’s, needs.

Playback

I also see the emergence and development of musical piece as a distinctly agile practice. Picture a composer sitting at a piano, armed only with blank manuscript and a vision. The ideas in the composer’s head are translated into sound using the piano. The sound provides instant feedback as to which melodies, harmonies and chords combine effectively; in other words, the composer is testing and integrating while the piece develops. In most cases, a musical creation starts small: a simple melody or sequence or chords from which the composer can choose to overlay harmonies and counter melodies. Through simple playback and constant rehearsal the composer can quickly identify problems or imperfections in the product. Working with this integrated product allows the composer to add depth to the music against a solid, tested foundation.

These simple common sense practices translate directly to the quality engineering practices that underpin a Scrum development project. A test-first approach always minimizes the risk that our software “music” will not integrate at the end of a sprint.

Reducing Risk

“To achieve great things, two things are needed; a plan, and not quite enough time.”

– Leonard Bernstein

Scrum allows us to reduce the risk of undelivered projects through iterative delivery and striving for a potentially shippable product increment at the end of every sprint. I found many examples from music that characterize a similar low-risk approach to composing. This is best seen from composers who repeat a simple melody throughout the piece, then add substance to the music by changing the mix of instruments or by increasing the volume or tempo. These changes move the one simple melody towards a dramatic crescendo.

This is most noticeable in pieces such as Pachelbel’s Canon in D Major (1680), Dukas’ Sorcerer’s Apprentice (1897) and Grieg’s In the Hall of the Mountain King (1876). It is also evident in more modern music, where artists build on a simple theme with instruments and vocals, while the original melody still remains identifiable. This is a relatively safe way of adding depth to music, one instrument or rhythm at a time. This can be recognised in the Rolling Stones’ "Sympathy for the Devil" (1968) and more recently in the dance anthem "Sunchyme" by Dario G (1997). When listening to these pieces, clear sections are audible where the composer has modified the melody only slightly while still adding value. Each section is its own marketable product, which could be released if necessary even if the entire piece has not been written. The risk in not having a completed composition has been greatly reduced.

In the same way, adding functionality to a software project in small chunks adds to its depth and usability, but at the end of any iteration, you are still left with a potentially shippable product, greatly reducing the risk that your software project will fail to deliver.

Continuous Integration

Modern music recording in studios allows musicians to record iteratively and constantly check the quality of the outcome. Components of the song or music are usually recorded in isolation, but need to be integrated effectively to form a quality final product. Digital recording now allows musicians to playback drums, bass or treble to allow vocals to be added and tested against each other. This kind of dedication to testing and feedback continuously throughout production ensures the product achieves the artist’s goals. The same can be said of a Scrum project.

Self-management

As a former member of a brass band, I can certainly relate to Mike Cohn’s observations on the close similarity between a ScrumMaster and a band/orchestral conductor. The conductor (or musical director) maximizes the performance by ensuring the musicians carry out the composer’s vision when playing the piece. Some conductors can become quite animated as a means of injecting passion into their ensemble. However, a conductor does not have the capacity, or in most cases the technical proficiency, to take the place of a team member.

A good conductor cannot make a poor band play great music. But a good conductor can point out and help bands tackle some of their biggest problems. He can work with the band to improve those aspects that can be improved and can find ways to maximize that which they do well. In the same way, Scrum teams benefit from a ScrumMaster who can keep them moving toward a project vision, removing impediments and emphasizing team strengths.

Ultimately, though, it is the band that makes the music and the software development team that creates the product. When I hear a band play great music, I am not applauding the conductor’s baton but the combined unity of the musicians making such a pleasant sound. In the same vein, when a band under performs, the audience regard it as a poor performance regardless of the conductor’s efforts to maximize the quality the band provides. Similarly, when a team delivers a great product (or a sub-par one), people notice the product, not the ScrumMaster.

“Life is a lot like jazz... its best when you improvise.”

– George Gerschwin

Although the conductor keeps the team on the straight and narrow, I have seen first hand how a band of musicians can continue to work effectively and still deliver in the absence of a conductor. If a conductor ceases to conduct, the music will continue, but there is more responsibility for musicians to listen to the person sitting next to them. Listening is one of the keys to self-management.

Similarly, for Scrum teams developing software, listening is a fundamental part of teamwork. During the daily scrum, we should spend about one minute talking and up to fourteen minutes listening. Teams who don’t listen to each other are going to struggle to work effectively as one team.

Another important factor for self-management is team size. In large bands or orchestras, instruments generally split into sections which have to function as a section to add value to the overall sound of the musical arrangement. In most cases, section leaders help lead these smaller groups if only to ensure the sections begin and end their parts in a smooth and together fashion. This is particularly necessary in a larger orchestra when the conductor may be addressing a different section of the ensemble.  In these large musical arrangements, sections also need to be more aware of other sections sounds in order to maintain the quality of the overall piece. My former musical director would often shout, “If you can’t hear the trombones, you’re playing too loud”.

The same principles should apply in large scale scrum project, especially where multiple Scrum teams are involved. Experience working with Scrum teams tells us that teams between five and nine in size are most effective. Each small team needs to be fully aware of what the other teams are contributing to minimize the risk of delivering a poor quality product, or possibly no product at all. Teams who are functioning well, but playing too loudly, could even be sub-optimizing the system as a whole.

In summary

The Scrum framework helps teams to achieve excellence in delivering products by suggesting very few rules backed by simple and common sense principles. These common sense principles apply to many things we see or hear in our everyday lives. Music is an art we have encountered and enjoyed all our lives, yet the time, effort and dedication to composing, writing, performing and recording is something we probably have little experience in or have paid little attention to. The principles and practices involved in making music are not that different from those we use to deliver Scrum projects. Clear product visioning helps define and drive a delivery while regular feedback and continuous testing and integration reduce the risk of un-deployable products. When I played the cornet in a brass band, I felt part of a team. The team struggled if certain players failed to turn up for practice. The team would have to self-organize to fill the gap. Effective teams are born of constant listening and reflection. This becomes even more important in larger teams, or teams-of-teams. Similar to a large orchestra playing a symphony, each section of a large software project will need to understand the role of other sections as well as their own to ensure the composer’s (or, in this case, the product owner’s) vision is achieved.

Focus on Value

By Chris Sterling

Traditionally, software development projects started out with an idea and then tried to identify all the requirements needed to make that idea "complete" for the intended users. This long process was expensive (and sometimes ended in a “no-go” decision only after a great deal of money was spent) and did not place enough emphasis on value returned for the investment made. 

Agile has a tool that can help organizations re-focus on return on investment: value-driven user stories. Value-driven user stories are created specifically to link features with their users and the value the features have for their users. They can be created from a list of high-level features or a list of values and users centered on a general idea.

Value-driven user stories are useful in three main situations:

• Generating an initial product backlog from the product vision: A Product Owner has an idea for a product. She has not detailed specific features which would make the product come to life. Instead she has an idea of the value she is looking to provide for a specific customer base. In this scenario, we know the value that the product will provide and have identified the intended users of the product.
• Generating user stories from descriptions of larger and mostly ambiguous features that have risen in priority on the product backlog: We have an existing product backlog that contains smaller user stories, easily consumed by the delivery team, listed as highest in priority. Just a bit lower in priority on the product backlog are larger, more ambiguous user stories, otherwise known as "epics." As the smaller, higher priority user stories are pulled from the product backlog by the delivery team, the upcoming prioritized epics become higher in priority and must be broken down into smaller user stories consumable by the delivery team in an upcoming iteration. In this scenario, we will need to identify the value each epic will provide to users that are most interested in that epic.
• Generating user stories from a product roadmap's next release: A product roadmap is a plan for multiple releases and usually includes high-level descriptions of features, which can be thought of as epics. In keeping with the just-in-time elaboration concept, we focus on the next release in the product roadmap. The epics contained within this release will each be broken into smaller user stories to better understand the release. In this scenario we will need to identify what value each epic will provide to the intended users of the features delivered in the release.

To create value-driven user stories for these scenarios, we will need to perform a value-driven user stories exercise containing the following steps:

1. Brainstorm value statement from product vision, product roadmap, or epic
2. Identify interested user roles for product vision, product roadmap, or epic
3. Generate user stories for each user role and value statement we’ve identified in steps 1 and 2 in breakout sessions.
4. Debrief as a group.
5. Capture and prioritize user stories in product backlog.

The following sections will describe the setup, suggested practices, and artifacts to be created for each step of the exercise.

Step 1: Brainstorm Value Statement

Setup

The Product Owner starts the meeting by introducing the product vision statement, product roadmap, or epic that is driving the exercise. The participants may direct questions to the Product Owner throughout the introduction to gain better understanding. When the participants feel comfortable with their understanding it is time to brainstorm value statements. The facilitator for the exercise stands up in front of the participants with either a white board or easel pad to scribe for the group. The facilitator asks the participants:

"What values or benefits will this [product, release, or epic] provide to a user?"

As the participants brainstorm value statements vocally the facilitator writes them in a single column on the white board or a sheet of easel pad paper. If the facilitator or any participant believes that a particular statement needs clarification, a mini-discussion commences. When the participants are no longer generating value statements, it is time to go onto step two, identify interested user roles.

Suggested Practices

• Have a designated facilitator; either the project ScrumMaster or third-party facilitator
• Allow enough discussion for the participants to feel comfortable with the product vision statement, product roadmap, or epic.
• If introducing a product roadmap, focus only on the first release
• If introducing a product vision, write down some high-level capabilities the product should have.
• These may become epics to help drive the exercise
• As facilitator, try to evaluate each value statement by asking yourself, "Is this statement a value for the end user or a technically assumed value?" I have found that in many cases people in software assume certain technical capabilities are valuable to a customer. It is usually best to capture value from an end user's perspective rather than non-functional aspects that the end user is not aware of immediately.

Artifacts

• List of values that the product or epic will provide

Step 2: Identify Interested User Roles

Setup

In Step 1, you created a list of values that the product or epic will provide. This list is used as a backdrop for identifying user roles who are interested in attaining these values from the product. The facilitator asks the participants,

"Who is interested in attaining the values that are being provided by this [product or epic]?"

As the participants suggest user roles, the facilitator writes them in a second column on the white board or on a separate piece of easel pad paper. Allow the participants to make user roles more specific or generalized through discussion. When the participants are satisfied with their list of user roles, it is time to move onto step 3, generate user stories in breakout sessions.

Suggested Practices

• Facilitator should make sure that each user role is reiterated back to the participants for confirmation
• Ask the group if they are satisfied with the user role list when the rate of participant suggestions slows down

Artifacts

• List of user roles interested in attaining the values that the product will provide

Step 3: Generate User Stories in Breakout Sessions

Setup

Now that we have a list of values the product will provide and user roles interested in these values it is time to generate user stories. The facilitator asks the participants to choose a partner for the breakout session.  Ask each pair to choose a user role from the list created in step two. Each pair will generate user stories from this user role’s perspective for each of the values listed in step one. Some of the value statements may not be appropriate for every user role, but they should be evaluated before moving onto the next value statement. The group may not be large enough to cover all of the user roles at once, so each pair should continue to choose a new user role until all have been chosen and their respective user stories generated. (Conversely, if there are not enough user roles, form larger breakout session groups.) It is important that all user stories are written using the Mike Cohn template:

"As a <<user>> I want to <<feature>> so that <<value>>".

Place the user role into the <<user>> slot and the value this user role is attaining in the <<value>> slot. The <<feature>> slot is what is generated based on the user role and value to be attained.

Suggested Practices

• Make sure participants understand that each user story should follow the template. It will make the group debrief go more smoothly and decrease the need to rewrite user stories before capturing them in the product backlog.
• Divide into pairs if there are enough participants (5 or more).
• When a pair chooses a user role, place their initials or some indicator next to that role.
• Breakout pairs should focus only on one user role at a time
• If a breakout pair discovers a new value, they should add it to the master list of value statements.

Artifacts

• A stack of index cards or sticky notes with user stories written on them

Step 4: Debrief as a Group

Setup

Once all of the user roles have been chosen and the corresponding user stories have been generated, it is time to debrief as a group. The facilitator asks for a pair to volunteer to go first in order to get started. The pair reads their user stories to the group, asking for feedback after each one. If there is no feedback, the user story card or sticky note is placed into a pile in the middle of the group and we move on to the next user story. If there is feedback then the group helps to generate either a replacement for the user story or to supplement it with additional user stories. Once the group is satisfied, the replacement and/or original and supplemental user stories are placed into the group pile.

At the beginning of this debrief, the group may suggest features that the pair has captured but not mentioned yet in their debriefing. In my experience, this starts to subside as we progress through the group's generated user stories. After all pairs have debriefed to the group the facilitator should ask if the group is satisfied with the stack of user stories that were generated during the exercise. If they are satisfied, then it is time to conduct a retrospective so that the team can improve next time the exercise is conducted.

Suggested Practices

• Ask for a pair to volunteer to go first in debriefing to the group
• Allow group to give feedback on each user story
• Facilitator should make sure that the process of placing the user story into a pile in the middle of the group is followed. This places emphasis on completing discussion on each user story before moving onto the next
• At the conclusion of this step, conduct a short retrospective on the entire exercise to document improvements that should be implemented the next time it is conducted

Artifacts

• Conversation with participants about each user story generated
• New and modified user stories from group feedback
• Stack of user stories that are to be captured in the product backlog

Step Five: Capture Generated User Stories

Now that we have a stack of user stories to be captured in the product backlog, it is important that we do not lose them. I have found that spreading out the user stories on a table, wall, or white board and taking pictures of them is a good practice. The pictures will capture the generated content just in case the index cards or sticky notes are misplaced. It is also important to place the user stories into the product backlog immediately after the exercise has completed. The conversations about each user story are still fresh and the product owner has usually been thinking about priority during the exercise. Not all of the generated user stories must be listed together in the product backlog. For instance, the product owner may decide to focus only on one or two user roles for an upcoming release of the product.

Conclusion

Agile methodologies emphasize delivering value early and continuously so that customers get the highest return on their investment. By including the value provided by our product features and the user roles that are interested in attaining that value, we are able to more easily prioritize to optimize this return. The value-driven user story exercise supports just-in-time elaboration of features based on the value we are trying to provide and user's perspective of that value. The exercise can be used to generate your initial backlog or elaborate high priority epics throughout the project lifespan.

The Case of the Time Tyrant

By Alan Atlas

Managing a Scrum team for the first time brings some unexpected challenges. Often, at least at our company, the lucky manager hasn’t received the same Scrum training as the ScrumMaster or the team. She hears a lot of vague things about letting the team manage itself, but doesn’t quite know what to expect, let alone how to properly manage a Scrum team. All she really knows is that she is responsible for the success of a team over which she has very little control and who are using a process she doesn’t really understand.

As the scrum process takes hold, it begins to do what we promise in training: it makes a lot of things visible that were not visible before. One common example of this phenomenon is the fine-grained list of tasks that the team is doing on a daily basis (the sprint backlog). Estimates for these tasks in ideal hours are a tantalizing target for managers who are used to creating success by actively controlling (managing) their people. These lists are often like candy to managers who have never before had such visibility into what their teams are doing on a daily basis. They latch onto this concrete artifact with its numbers and lists and immediately start to manage with it.

Many hard-charging managers become puzzled, scratching their heads in confusion and consternation as they try to apply waterfall-based thinking to the sprint backlog. They end up wondering how it is that they can’t make the estimated hours add up to the number of hours that the team has available during the sprint, even allowing for overhead. Worse, they start to wonder why the team appears to be committing to work that adds up to a paltry 30 percent or 40 percent of the total time available during the sprint.

“Five people for 30 days (22 work days) adds up to 110 possible person-days of work! That’s 880 hours! I only see 350 hours estimated on your backlog! This can’t be right. You’re being lazy or inefficient. This Scrum process is awful, and I’m going to get very involved to make sure we’re doing the right amount of work!”

This is something that I see fairly often as Scrum spreads throughout my large, successful Internet company. Does this happen at your company, too?
What is the thought process that got our new-to-agile manager so upset?

• Employees need to be supervised (command and control).
• Time spent is a good measure of work done because employees have already been told the correct thing to do.
• 100-percent-resource- (employee-) utilization is the goal in order to avoid “waste” and reduce costs.
• If utilization is low, it is because employees are not being controlled enough. They are getting away with being lazy.
• Therefore, I as a manager must make sure the team is spending every possible minute doing work. That’s the way to get the most software released!

By contrast, what would an experienced agile manager be thinking?

• The team is doing the most work possible in the time allowed.
• The team is concentrating on delivering value, defined by product backlog items, in priority order.
• The most useful measurement of team accomplishment is the delivery of product backlog items as working software, so that is what should be monitored. Time spent does not correlate with delivering value.
• Improving the team’s velocity requires removing organizational impediments that are revealed by Scrum (e.g., high operations load, high maintenance load, technical debt in legacy software, requirements churn and lack of definition, no continuous integration environment, poor employee retention, incorrect team size, incorrect people on the team).
• The goal of Scrum is not to achieve the highest resource utilization; it is to achieve the highest throughput of completed, deliverable value. Little’s Law, Goldratt’s Theory of Constraints, and the Lean principles of pull scheduling and working to capacity explain why Scrum can deliver on this goal. From these underlying principles, we realize that 100 percent utilization actually works against high productivity.
• I, as manager, care that the team produces the most value possible each sprint, therefore the best way for me to reinforce the team’s focus on improving velocity is by helping to remove impediments.

We already know what 100-percent-utilization of roads gives us: zero throughput (gridlock)! Why do we think it is different for a development team?
Concentrating on resource utilization sends a negative message to the team without improving anything except, well, resource utilization. It diverts energy and focus from the important thing, which is delivering value for customers. It takes away the single largest source of productivity we have available: the creativity and commitment of the team.
So what should our manager, who is perplexed because “the hours don’t add up” and suspicious that not enough work is getting done, do? The key is to stop thinking in terms of people spending more time doing more work and start thinking in terms of changing the tasks that the team is doing so that the time spent working contributes to value and not waste. This shift in mindset leads to a different set of possible actions for the manager:

• Concentrate on velocity as defined in Scrum: the amount of value completed each sprint. Watch for the velocity to increase every few sprints as a result of the improvements that you and the team make.
• Stop worrying about why the hours don’t add up. Start noticing instead that the team produces the working software they say they will at the end of every sprint.
• Challenge and inspire the team to improve velocity by changing the things that get in the way of building lots of good software. Ask about the impediments that have been raised in retrospectives and what has been done to remove them.
• Work with the team to address organizational impediments as they are identified in retrospectives.  For example:
  • Do you really need to have a meeting of the entire organization every week?
  • Is the corporate QA group able to support your team in the most efficient way possible?
  • Are outsiders randomizing your team by redirecting them during the sprint?
• Let the team self-organize to improve velocity. Ask them what changes they are making that will enable them to spend more time building software and less time doing unproductive work. For example:
  • Did people spend a lot of time fixing broken builds that could have been spent delivering features?
  • Were team members available to help one another when help was needed?
  • Did the team swarm to complete features quickly, or to overcome difficult obstacles?
  • Did people privately wrestle with problems rather than reaching out for help? Look for and review impediment backlogs.

Thinking in agile terms will lead the manager, and the team, to their shared goal of shipping the most, and highest value, software possible. The improvements to velocity that are achieved in this manner will be long lasting and sustainable.

The passage of time, in and of itself, signifies nothing. Don’t tyrannize your team with ideal hours. Time is enough of a tyrant as it is.

Writing the Product Backlog Just Enough and Just In Time

By Mike Cohn

Some people want to take the stance that no work should be done in advance of the sprint. That is clearly untenable. To see why, let’s take that view to its extreme: If we did nothing in advance to understand what we're building, we’d show up at the planning meeting and say, “Hey, what should we build this sprint? We were working on an eCommerce site yesterday, but I think maybe we should switch to writing a word processor...” The team would literally have nothing written down—no product backlog / user stories / prioritized feature list at all.

This approach leads to what I call “billiard ball sprints.” Without any planning, the team starts a new sprint on the day after the prior one end, but spends the first two to five days “getting ready” to start the sprint. The start date of the second sprint is knocked forward by the end of the first—like one billiard ball knocking into another.

Having dispensed with the possibility that no work should be done in advance we are left to consider the question of how much work should be done in advance. Many say that as little as possible should be done: the team should do no more than write a few words of a user story on an index card to represent each product backlog item. While it’s true that this may be sufficient in many cases, it would clearly not be adequate in all situations.

My view is that each product backlog item (usually reflected as a user story by teams I train or coach) should be captured just in time and in just-enough detail for the team to go from product backlog item to working, tested feature within a sprint. To see why just-in-time and just-enough are appropriate targets, suppose we decide to write a checkbook program to compete with Intuit's Quicken product. We create an initial product backlog that includes these two user stories:

• As a user I can see the current version, company website, and copyright in a "help about" dialog so that I know useful information about the product.
• As a user I can enter a check in my register so that I can track who I pay.

That first story can go from that short description to implemented code quite easily within a sprint. The analyst will have time to figure out exactly what the text should say; the user experience designer (UED) will have time to mock up two or three screens, show them to some users, get feedback, and create the best possible “help about” screen. And the programmers will have time to code it and the testers to test it. In short, it meets the just-enough-detail criteria.

The second user story, “As a user I can enter a check in my register,” is too big to be done in a single sprint. It encompasses the entire main user interface (UI) metaphor—will our system look like a paper check register? How many rows in the register? How will users choose things like check numbers or electronic funds transfer (EFT) transactions, and so on. There is no way the UEDs can figure all that out in a two-week sprint. This user story is not explained in just-enough detail. This is where our second attribute comes in: detail should be added to this user story (product backlog item) just in time. If the team will not work on this user story for six months there is no need to expand on what is already written. On the other hand, if the team hopes to start it in a few sprints, it is likely time for the UEDs to figure out the answers to the high-level questions listed above.

To do this, they’ll need to allow time to “figure out the answers” in the upcoming sprints. Let’s say that during the first sprint the team chooses to work on the “help about” story and likely a few others (not shown in our sample product backlog above). They also agree to spend some time figuring out what the main UI metaphor for the system will be.  During this time the UED may design a couple of screens and show them to a few dozen or hundred users, get feedback, and do it again. This may happen a few times. When they finish they may have turned that one user story (as a user I can enter a check in my register) into a dozen smaller stories, perhaps specifying what fields are needed and other details such as:

• As a user, when I enter a new check it defaults to the last check number + 1
• As a user, I can enter a memo for each check, etc.
• As a user, I can double-click on a check in a list and see the current item look like a paper check.

In some cases splitting a large story into smaller ones is sufficient to show the new items at the right (just-enough) level of detail. When it’s not, we can augment the user story with additional information. I like to write user stories on index cards. That was sufficient for the "help about" story. It’s not for the initial large user story encompassing our system’s main UI metaphor. If splitting a story does not add just-enough detail, the UED and others involved may want to staple a UI design spec to the index card. (If you are using a software system for managing your product backlog, your virtual staple may be a hyperlink to a wiki page.)

The UI design spec that is stapled to the user story card will not yet be perfect; rather it will be close enough that remaining details can be figured out during the sprint. For example, the UED may not yet have decided if each check should take two rows or three on the screen and wants to do a bit of user testing early in the sprint while the team codes that story. He'll get them an answer early enough that they can do it either way during the sprint. 

The goal of the UED (and anyone else involved at the time) is to add detail to the story in a just-in-time manner. There is usually no value to splitting a large user story up now or stapling a document to it if we won’t work on that product backlog item for quite awhile. While working to add detail in a just-in-time manner, those doing so should strive to add just-enough detail that no individual item will take more than one sprint to complete. Just-in-time and just-enough become the targets for establishing a smooth flow from product backlog to sprint backlog.

Destination: Agile

By Sally Elatta

Organizations are increasingly moving from traditional waterfall methods of software development to agile methodologies, including Scrum. If you're new to agile and not sure of exactly what it is then allow me to give you a five-minute overview before I jump into why companies are moving this direction. You should also read “The 10 Key Principles of Agile.”

Agile refers to a set of values and principles which govern a style of software development that encourages iterative, collaborative and results-focused development. The following definition from Scott Ambler says it best:

“Agile is an iterative and incremental (evolutionary) process approach to software development which is performed in a highly collaborative manner with ‘just enough’ ceremony that produces high quality software which meets the changing needs of its stakeholders.”

Agile is the umbrella for several other popular methods such as Scrum, XP, Feature Driven Development, DSDM and others.

Scrum is one of the most popular agile methods. You can think of it as the project management side of agile. Scrum provides the processes and visibility needed to manage and control complex software and product development. Jeff Sutherland and Ken Schwaber are the two founders of Scrum. Many companies that adopt agile will adopt Scrum for managing the projects and also use some engineering practices of XP (such as Test Driven Development, automated testing, coding standards, and user stories) and some of the agile modeling and light documentation techniques provided by Agile Modeling.

If you adopt Agile/Scrum, your teams will likely:

• Gather the list of work to be completed as user stories
• Develop a release plan to determine the project schedule
• Estimate the complexity of each story in terms of story points
• Work in small two- to four-week fixed iterations (also called sprints)
• Start an iteration with a planning meeting
• Collaborate within the team and with the business
• Have daily fifteen-minute standups to track progress
• Have a demo at the end of each iteration to review what was accomplished (or not!)
• End the iteration with a retrospective

Most importantly, your agile team will have the following goal:  “To deliver high quality, running, tested stories that meet the business need in a predictable, efficient and collaborative manner—on time, on budget!”

So now that I’ve covered what agile is, let’s dive into the top reasons why organizations are moving this direction. We’ll first look at why customers and product owners adopt agile. We’ll then examine why teams and management adopt agile.

Top 8 Reasons Why Customers/Product Owners Adopt Agile

1. Early measurable return on investment. They want to see working software at the end of each iteration and early in the process.
2. High visibility and control over the project progress. High visibility into project progress can also yield early indications of problems.
3. Early and continuous customer feedback. Because the customer is involved throughout development they end up with software they want and will use.
4. Empowered Product Owner. The PO is given the information necessary to make decisions to steer the project toward the goal.
5. Incremental delivery. Delivery of software on the scheduled release date is not an all or nothing deal.
6. Agile change management is adaptive to changing business needs. Agile and Scrum give the product owner more control over adding, changing, or removing requirements (except for the current iteration stories) than traditional methodologies.
7. Agile helps align IT with the business. Teams work only on the top business priorities.
8. Agile reduces product and process waste. Nothing is developed that isn’t specifically needed. Agile processes are lightweight and value driven.

Top 8 Reasons Why the Team and Management Adopt Agile

1. Agile builds empowered, motivated and self organizing teams. Agile produces an increased level of team satisfaction because individuals are empowered to provide input, set the iteration goal, self-organize, and help improve the process. This unleashes the creativity and innovation of the team members.
2. Clear expectations are set and communicated. Both the team and product owners have a clear understanding of the release and iteration goals and what is expected of them to reach these goals.
3. Success is clearly defined. The agile definition of "Done" is accepted by the product owner as completed and ready to ship. The only measurement for success is stories that are "Done" at the iteration and release level.
4. Teams can focus on delivering measurable results. Agile teams focus on getting working software delivered instead of clearing impediments, prioritizing, or being pulled in other directions.
5. Customers communicate directly with the team and provide timely feedback. Early and direct feedback is the only way to deliver what the customers really need.
6. Teams feel a sense of accomplishment and recognition. The team feels a sense of accomplishment at each demo when they deliver stories that are "Done" and hear the customer and stakeholder feedback first hand.
7. Management realizes cost/time savings due to waste elimination and efficiency. Many organizations that adopt agile seek to become "Lean" and eliminated processes that add no value.
8. Better resource management for shared team members. The good thing about time-boxed iterations is that they are time-boxed! This means that shared members from other teams (DBAs, Technical SMEs, Report Writers, etc.) will know in advance when the next planning meeting, demo, and retrospective are scheduled.

Every person on an agile project could add a reason to this list. These, however, are the prominent reasons why more and more companies are adopting agile methods for their software development projects.

Major Scrum Tool Update Coming Soon

The launch of the newest version of ScrumEdge’s online scrum tool is expected before Christmas. Once live, you will notice that the new version is significantly different from the current version.

Update Details:

• We have done away with the old interface and come up with a completely new and more intuitive interface. Among other things, you will notice that this version will give you a lot more screen space to play with.
• We have removed the ‘Setup Wizard’ as many users were having problems running it. Instead we have added ‘Tips’ on most pages to help users navigate their way around the site.

Expect more details of this release as we get closer to the release date.

Scrum Turtles

By Haim Deutsch

Every Scrum practitioner (certified or not) knows that while Scrum principles are easy to learn and to understand, they are often tricky to manage. The ScrumMaster finds himself at the nexus of the development effort. All around him revolves almost every single function in the organization (with the possible exception of the janitor). The ScrumMaster has to control and manage the fears and concerns of the customer, the Product Owner, the QA manager, his own boss, the VP of marketing & sales, and, last but not the least, his teams. In essence, he is the lamentation wall for a global village. This stress is always present—I know; I have experienced it over and over again. To succeed in this environment, the ScrumMaster needs powerful tools that can help him regain control and manage the constant stress.

Luckily, coaching provides us with just such a toolbox. The ten tools in the coaching toolbox (this may sound familiar) are easy to learn and to understand, but are often tricky to apply. None are a silver bullet. I'll describe each of the ten tools in detail in future articles, and will also show how you can leverage them to manage delicate situations. In this article, however, I'll present a much more general approach for being a successful ScrumMaster. This approach is one that we all know—one that is pure common sense and that we apply to our coding but not necessarily to our project/team management.

Back in the early 1980s, a seventeen-year-old boy named Richard Dennis stepped onto the floor of the Chicago Mercantile Exchange, the biggest commodities trading floor in the world. A few years later, this same young boy was one of the most famous traders of this exchange and became known as "the prince of the pit." Dennis believed that successful trading was an activity that could be learned, rather than an innate ability. “We're going to raise traders just like they raise turtles in Singapore,” Dennis said. Few believed he could do it. To prove them wrong, he published an advertisement searching for traders to be trained. Though thousands answered, Dennis hired only twenty three of them. He dubbed them his turtles. What began as a bet, turned out to be one of the most amazing experiences in Wall Street.  Dennis gave his turtles two weeks of training. Four years later, each of the turtles had produced 30 million dollars and had averaged an 80 percent profit. Some had as much as 100 million dollars in profits to show for their four years of trading. All this after only two weeks of training! What turtle-raising techniques had Dennis employed to produce such amazing results?

Sit down with me a while. We’ll have a drink and ponder the way of the turtle.

Dennis relied on five principles to raise his trading turtles:

1. Keep it simple. Dennis built some simple rules that his turtles would have to follow. (Sound familiar?)
2. Too much data is a lethal weapon. Dennis minimized the amount of data the turtles would have to process.
3. Have a clear plan. Define your goals clearly and determine what steps will get you there. Anything that doesn’t take you there is negligible. Yes. Anything, no matter what the losses, that doesn’t take you toward a goal is in the way. (This is the crux of “result thinking,” for those of you who are of the coaching persuasion.)
4. Manage the risks properly. Without proper risk management (or money management in Dennis’ case), you are the walking dead.
5. Never try to foresee the future. You must have a general idea of where you are heading, be able to react to the reality of the market, and have the discipline to react only to what you actually see.

Whew! You now have all five principles. Let’s take a quick break. Take your time and reread the way of the turtle. You can have another drink if you need one; I’ll take a diet cola. When you’re ready to go on, keep reading.

Whether you are introducing Scrum in your company or you are a seasoned ScrumMaster, these guidelines apply to you. To manage stress, follow the way of the turtle. You need to teach each function of the company, including the customer, to work in a Scrum-ish way; but to achieve your goals, you will have to raise your turtle. Let’s turn those turtle-raising principles into Scrum-specific guidelines.

Keep it simple. The rules have to be minimalist and simple. Remember: people like simple rules, or thumb rules. Not only are they easier to follow, but it is also easier to detect any infraction. When you have only a few rules, you can rationalize your insistence that they be followed to the letter. The only intent of these rules is to allow you to do your job properly by enforcing effective, creative, and committed work from all functions of the company. These rules are also very important within the team. The team must have a limited bunch of rules on how to code, how to document, and how to test. These rules must facilitate the developers’ work, rather than hinder it. A good rule set allows developers to think less about how and more about what. In other words, good rules should free developers to concentrate on code development.

Too much data is a lethal weapon. Make use of a dashboard to give a global vision of the entire process in the more concise manner. Restrict yourself to the minimum documentation and data when you present to customers or executive managers. Believe me, they will thank you for it. Making conscious choices about simplifying data not only builds transparency, it also builds focus. Give the team a global picture verbally, and transmit focused and concise written material to support that picture. Think about it: each piece of written data has to be controlled and updated. Why waste the time? Standards like FDA or AAA require a minimal amount of written documents. You may be surprised by how concise these documents can be while still conforming to these standards.

Have a clear plan. It seems evident but, in fact, not every function sees the plan clearly. This is partly because the goals of each function are not necessarily the same. The first tool of coaching is result thinking. It looks much easier than it is in the real life. While I’ll cover this I more detail in a future article, for the moment, let’s just say that a clear plan helps to coordinate the entire effort of the organization. It helps to manage difficult situations and conflict by focusing on the common goal. It helps to determine which action items to undertake: those that are bringing the company closer to the stated goal. The plan gives a common frame for everyone to work within. It helps to manage difficult times by reassuring everyone that any losses incurred are only lost to realize some other action that fits the overall plan, so that by the end we will be much more profitable.

Manage the risks properly. Don't put your head in the sand. It doesn't help. In the same manner that Scrum embraces change, Scrum also embraces risks. Identifying them clearly can help to either prevent them or take corrective actions in time. How much effort are you assigning to risk analysis and risk management? If you are like most, not enough. This action starts at the top. Executive managers have to be involved and committed. They have to identify their risks in front of each function in the organization; usually, they need a coach to achieve this. And then from there the risks have to trickle down until they reach the developers, who have to know their own risks. Each single function has to identify and manage on-the-fly the risks in front of each function. This is really hard the first time you do it, and in general you need the help of a coach, but as you learn to do it, it becomes more and more natural. Knowing all the risks makes you more proactive. You can see more clearly the situation you are heading towards, and are able to take corrective action according to the plan. In the end, you make fewer mistakes.

Never try to foresee the future. This is what Scrum is all about. You can never know exactly what will happen, and you cannot possibly be ready with solutions up your sleeve for every impediment that might occur. Do you have a plan? Good. Do you know where you are heading? Double-good. Don’t even try to prepare responses to the “pacmans” that lurk around the corner. You will have enough work on your plate when they do happen. Do, however, be observant and aware of what is happening around you. And as you identify a change, embrace it or kill it; it's up to you. Just like the trading turtles, you can follow a plan, but you cannot go against the market.

And I’ll add a sixth guideline—one to see you through. The sixth principle is to have faith in your skills, belief in your capabilities, and trust in your way.

Be Scrum smart!