Progressive Development : scrum

Motley says: "What's wrong with mixing Scrum and Waterfall? You get a nice 'Scrummerfall'!"

James Waletzky — Tue, 25 Aug 2009 17:45:00 GMT

Summary

	Motley: An effective modification to Scrum is to do a requirements sprint, followed by a design sprint, implementation sprint, test sprint, and stabilization sprint. It has the benefits of Scrum and has commonality with our older processes, which makes the developers happier.
	Maven: Scrummerfall, or mixing traditional Waterfall with Scrum, is less effective than Scrum itself. Deliver real business value with each sprint for early and frequent feedback, and improve collaboration amongst team members as no one is left blocking and waiting for others to finish their tasks.

______________________________

[Context: Motley and his team of able developers have been brainstorming ways to improve their Scrum process, and he is about to upset Maven with the details of his "improvements"]

Motley: Hey, Mave. Where have you been hiding lately? I haven't seen you around the office much.

Maven: Summer time is busy time. I had softball to play, a week of karate class with my sensei's sensei, and a couple of backpacking trips. I've been taking my vacation in small chunks.

Motley: I thought you were just slacking off, as usual.

Maven: Funny guy. This year I've had lots of small vacations instead of one big one. It really doesn't allow you to recharge enough, but I do like the variety.

Motley: Ok, enough about your relatively boring personal life. I'm thinking of making some changes to our Scrum process. With our next milestone fast approaching, the team really wants to transform Scrum into something more effective.

Maven: That's great! A key tenet of agile development is frequent introspection and continuous improvement. Glad to hear it.

Motley: Yeah. The team is thinking of having a requirements sprint, followed by a design sprint, followed by an implementation sprint, followed by a test sprint, followed by a stabilization sprint. Because the company wants to see these document deliverables as early on as possible, it might make more sense to get these done in sequence like this. The team also likes it because it is more similar to our old process.

Maven: I take it back - that's not so great.

Motley: What's the problem? The changes sound reasonable to me.

Maven: What you are proposing can be referred to (depending on the circle) as "Scrummerfall" or "WaterScrum". I'll call it "Scrummerfall", as I like that term better. In essence, you are proposing to combine two methodologies that typically do not work well together. With the proposal, you are basically doing Waterfall development, with more frequent check-ins (more akin to the way Waterfall was supposed to be, but typically is not). You lose the benefits of being an agile team.

Motley: How is it really different? We obviously still preserve the core of Scrum, including the daily stand-up meetings, planning, burndown chart, retrospectives, continuous improvements, and all the other pieces.

Maven: The proposed process is fraught with issues. In fact, you are no longer an agile team - you are back to waterfall, like it or not. Remember our previous chats on agile development? This process would break many of those principles. For example:

Scrummerfall abandons the idea of vertical slices, or delivering end-to-end functionality in short iterations of 2-4 weeks. Your deliverable at the end of a "sprint" in this model is a document, such as a requirements specification. Does that add real customer value that you can solicit meaningful feedback on? In my experience, it is hard for a user or fellow engineer to provide real valuable feedback on something that is not real (i.e. there is no working software, only a description of what that software will do).
Scrummerfall loses the benefits of the improved collaboration that Scrum provides. Sure, you can still have your daily stand-up meeting, but the feeling of marching toward a common goal is somewhat lost. What are the developers doing while the "Requirements Sprint" is happening? What is the test team doing while the "Design Sprint" is happening? Scrummerfall just doesn't work in a truly collaborative way vs. delivering real business value at the end of a sprint. Additionally, it forces you into doing too much up-front work with requirements and design, leading to overthinking the problem.
Scrummerfall violates the "working software over comprehensive documentation" piece of the agile manifesto. Don't get me wrong - documentation is necessary even with agile teams. Here, however, you tend to generate much more of it, which often falls into the waste (i.e. wasted effort) category, and we want to eliminate waste.
Scrummerfall makes change harder. If you get to implementation and test and realize something is amiss, you have a bunch of rework to do, including potentially large adjustments to design and documentation. Don't forget, with agile, we want to embrace change.

The team needs to deliver working software every sprint for early and often feedback. Yes, you can apply some of the practices of the Scrum methodology that contribute to team success, but Scrummerfall violates the fundamental principles of agile, which put you back in a Waterfall world.

Motley: But we still only need to plan for short iterations instead of long term crystal ball-like planning, which is a benefit and better than pure Waterfall.

Maven: Scrummerfall forces the team into a longer-term detailed planning phase because the end date of specific functionality in working software is important to the management team. You'll be predicting the future farther in advance for each feature instead of delivering features in just a few weeks. Of course, if you have a management team that wants crystal clear concrete delivery dates for all functionality up front, then you have less leeway here and have to do up front planning anyway to increase their confidence and minimize risk (even though that may be a fallacy anyway).

Motley: What about bugs? I don't want the team to be distracted with a bunch of bug fixes while we are doing feature development. We need that stabilization sprint at the end once everything is complete to fix all our bugs.

Maven: Don't forget - agile thinks about bugs differently. Instead of leaving bugs until the very end of the cycle, address them in the next sprint after a small end-to-end scenario is implemented. Bugs are a sign that the feature developed in the iteration is not done. Address the bugs as soon as possible, as they lead to increased technical debt (plus potential bug postponement, forgetting context of the bug, fixes growing more complicated, etc.) if they hang around. Avoid leaving them until a stabilization sprint at the very end. As we discussed previously, it is okay to have a quality sprint where you just focus on bugs as your iteration goal - it is more about when you fix the bugs.

Motley: Although I think the proposed process can work, I see some of your points. Small iterations of complete functionality, focused shorter-term planning, better collaboration and efficiency of team members, and less emphasis on documentation.

Maven: I actually agree with you - the proposed process can work. But, you are either an agile team or you are not. Mixing the two models can confuse people and actually make team effectiveness worse. With small chunks of deliverable software, you can get the test team private builds quickly to hammer on, and the test team does not fall behind as quickly. Because the team is marching to a common goal, the constant collaboration leads to priority adjustments and work breakdown to help others succeed (e.g. dev can build stubs and the test team can start to write test automation).

Motley: Ok, ok. I'll have a meeting with the team to discuss putting the brakes on this proposed change. They might be a little upset.

Maven: There is no one right way to build software. The idea here is to set the team up for greater success than it would have had otherwise. Other factors can get in the way of putting in your own completely customized process, but that is a topic for another day.

______________________________

Maven's Pointer: Brad Wilson, a blogger on the "Agile Programmer" site defines Scrummerfall as:

Scrummerfall. n. The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.

Interesting definition. His description of Scrummerfall is slightly different than above. It involves embedded Waterfall within each sprint in a one-two-one pattern - one week of design, two weeks of implementation, one week of test. Although, in my opinion, this situation is not nearly as bad as full requirements, design, implementation and test sprints, it is still somewhat outside the spirit of Scrum unless you parallelize the tasks and help each other succeed.

Maven's Resources:

Scrummerfall - Mixing Scrum with Traditional Software Methods, blog by Mitch Lacey, http://blogs.msdn.com/mitchl/archive/2006/08/18/706897.aspx

Motley says: "Use Scrum in my personal relationships?!? Don't be such a geek."

James Waletzky — Tue, 22 Jul 2008 17:59:00 GMT

Summary

Motley: Use Scrum in my personal relationships? Don't be such a geek.

Maven: You can apply the same lessons as Scrum teaches to your personal relationships - lots of communication, planning, iteration, and retrospectives focusing on continuous improvement. Just translate the really hard stuff (relationships) to the what we geeks understand.

______________________________

[Context: It's Monday. Motley is not a very happy developer after spending the weekend with his girlfriend]

Maven: Hey, Mot. You look a little depressed today. Did you not have a good weekend?

Motley: Personal stuff. Leave me alone.

Maven: Ah, c'mon. Maybe I can help.

Motley: Dude - you write software for a living. You have no personal life. You don't know the first thing about relationships. Ah, crap. I already gave too much away.

Maven: Girl troubles. I see. What's the problem?

Motley: Ok, I'll humor you. I may as well tell someone my problems. It helps to get them off your chest. It's pathetic that I have to resort to you, however. Anyway, I have a great relationship with my girlfriend - usually. We are going through a rough patch. We haven't been communicating as much as we should, expectations are not being set appropriately, and I feel like we keep digressing to old behavior.

Maven: Typical problems in a more mature relationship. I remember you saying you live with her, so I presume it's mature. How about starting with some examples? What's the communication issue?

Motley: Wait a second. You see James listening again hoping for some blog material? Hah. Not getting anything this time. For once we are having a conversation about a topic that has nothing to do with software engineering! Sucker.

Maven: Knowing him he'll turn this into a software engineering topic somehow.

Motley: Anyway, one of the main issues in my relationship centers around chores. She has some responsibilities and so do I. The problem is that she does a poor job at the chores and I have to clean up and finish. It is frustrating.

Maven: It's your fault.

Motley: What do you mean it's my fault?!? She does the chores!

Maven: Have you sat down and communicated expectations you have for the chores? The two of you have not specified the completion criteria for the chores, so there is a misunderstanding of what needs to be done.

Motley: That sounds so robotic, dude. But, fine. I guess if we don't talk about expectations, that leads to issues. I'll have a chat with her about that.

Maven: What are the other problems?

Motley: Still related to chores, when she starts on something, it takes forever to finish it. She just bites off way too much at one time. And by the time it's done, it's too late to be useful. Yeah, yeah - you want an example. Well, she started working on the yard in mid-summer - bought all the plants, and by the time the plants were all in the ground it was fall and they died off shortly thereafter. Definitely not the way I would have done it.

Maven: Have you encouraged her to split the larger tasks in smaller pieces? Instead of doing one big task she could do a bunch of smaller tasks and adjust as needed. If the yard is taking much longer than expected, she could adjust what plants to put in the ground to be more seasonal.

Motley: Probably not a bad suggestion. I'll bring it up. While I am in a whine mode, another thing I am not happy about is that many chores get overlooked. Taking out the garbage is a regular thing - if you don't do it, you miss garbage day and have to put up with a nasty odor for a week. Don't you just love the smell of two week old rotten vegetables?

Maven: Perhaps what you two should do is have a brief discussion at the start of the week to come up with a shared to-do list of tasks you need to accomplish. Think of it as a family meeting or something.

Motley: Have you ever had a relationship? Never mind - I withdraw the question. Your suggestion is way too formal! She will likely laugh in my face.

Maven: It doesn't need to be formal, and it goes back to setting expectations. If you clarify the plan for the week, you will save yourself some stress and headaches later. Write it down so there is no confusion, and then you get the pleasure of checking off the task when it is complete, as we talked about previously in our checklists conversation.

Motley: I am not going to bring it up as a "family meeting", but the concept is reasonable.

Maven: If you do a daily check-in as well, you ensure that things are kept on track for the week. Just bring it up in everyday conversation.

Motley: I am afraid that if we take these suggestions that we will be back to our same old selves at the end of the first week.

Maven: Change is hard. We have talked about that too. When you make up your plan for chores for the next week, think back about the previous week and talk about how you can make the next week better. Scrap the to-do list if it isn't working. Make more time to talk if that's what it takes. Additionally, have a chat about what went well, and continue to do those things.

Motley: I don't know if I can sell all of this to her. I am obviously going to have to rephrase everything that you have just said in a way that she can understand, and not sound so ridiculously formal. All of this thinking sounds familiar though, but I am having a hard time placing it.

Maven: At this point you likely think I am completely off my rocker (crazy), but in a previous relationship my girlfriend and I were seeing a counselor and he recommended everything above. I thought it sounded very familiar to the work environment, and then it hit me like a tire on the side of the head - it's Scrum! Who knew that you could apply Scrum concepts to your personal life. I didn't.

Motley: Scrum. Yeah, I thought that sounded familiar. You just ran over planning, the meaning of "done", doing work iteratively, the daily check-in meeting, updating your backlog, and retrospectives. You are such a geek. You did say "previous relationship" with your girlfriend, so I am assuming this didn't work. Why bother?

Maven: Don't be a wise guy. Apply all the stuff we just talked about to both your relationships and to software engineering and you will be fine. Just remember to apply some right brain thinking when you use it with your girlfriend.

______________________________

Maven's Pointer: Building and maintaining relationships is often hard for techno-geek logic-based beings like software developers. It is amazing how the metaphors that we apply in everyday software development also apply to life in general. The counselor in the story above had no idea whatsoever what "Scrum" was, but he presented all the concepts in his language. Many concepts that we leverage as developers are applicable to other domains and disciplines. You just have to look for it.

Maven's Resources:

Yeah, right. This topic is pretty far out there. If you find any related resources, be sure and let me know!

Motley says: "Bug fix sprints are a Scrum anti-pattern"

James Waletzky — Tue, 27 May 2008 17:57:00 GMT

Summary

Motley: Bug fix sprints are a Scrum anti-pattern. Quality should be kept high so as not to have to focus on bug fixing.

Maven: A clear meaning of done for sprint tasks is important, but even if you follow this best practice, there will always be integration issues, bugs, and changes required late in a cycle. A sprint focused on these tasks is reasonable.

______________________________

[Context: Motley and his team of merry developers have been fixing bugs for the past week, and Maven has noticed something odd]

Maven: Morning, Mot. How are things going?

Motley: Not too bad, although I'm a bit late getting in this morning. It's tough to get out of bed when all you have to look forward to is fixing bugs for the next couple of weeks. The bug database is the team's to-do list for the next little while.

Maven: Yeah, this is a part of the development cycle that is rarely a developer's favorite. Is morale still high in the daily Scrum meeting?

Motley: Daily Scrum? Why bother? We are done with Scrum now that we are integrating and bug fixing. Besides, bug fix sprints are a Scrum anti-pattern. Didn't you tell me the other day that Scrum only works for new feature development?

Maven: Um, you must have heard that statement from someone else, or misunderstood something I said. I would partially agree with your statement that bug fix sprints are a Scrum anti-pattern. In fact, most of the Scrum/agile purists would likely say that you are absolutely right. However, past experience and the reality of software development have made me realize that bug fix sprints can be a necessity in large organizations practicing agile development.

Motley: Why?

Maven: One of the most important concepts of Scrum, and where many teams fail, is having an explicit meaning of done for each and every task on the sprint backlog. For example, a typical coding task may involve the following in its "done" definition:

Design document reviewed (if necessary)
Feature fully implemented (including error handling, performance, reliability, security, maintainability and other quality concerns)
Buddy build complete
Buddy test complete
Unit tests written
Code coverage from unit tests > 80%
Static analysis run
Code reviewed by at least one peer
Code checked-in to the source tree

Motley: That's getting pretty detailed isn't it? What's the point?

Maven: The point is that we all have a common understanding for what it means to complete a specific coding task, and understand what "shippable quality" means. If you do not explicitly define the task, some tasks may get missed costing you valuable time and effort later in the cycle when change is more difficult. With agile, we want to produce high quality deliverables very early and not rely on a long "stabilization" phase at the end. If we do everything we can to prevent bugs up front, we'll actually save time in the long run and theoretically ship sooner. Having defined meanings of "done" for all our tasks is a big key.

Motley: Which reinforces my point that a bug fix sprint is an anti-pattern. Jeez, Mave - did you not have your morning jolt of caffeine?

Maven: If everything goes according to plan and you integrate components as you go, then yes, longer bug fix periods are somewhat of an anti-pattern. But let's be realistic. There is some measure of integration and late discovery of unknowns in any large software project. For a small project of a few thousand lines of code, you may be able to avoid a bug fix stage like this. However, take James' experience in working for a previous company. One thing his team was responsible for was porting a large code base from one platform to another. The team added unit tests where possible but much of the code was inherited legacy code that did not come with tests. The test team worked closely with the development team to find as many problems as possible up front, but when you have tens of thousands of lines of code running on a platform that is changing underneath you, you must expect to find bugs later.

Motley: Not to mention when people in the organization start hammering on your code as real users would. I think James called that "dogfooding" when I talked to him, as in eating your own dogfood. That does not sound very appetizing.

Maven: Correct. You cannot possibly predict all the issues that will arise and fix them proactively. As a result, his team undertook what they called a "quality sprint", which focused on fixing bugs. They took an agile approach and refused to develop new features until the product was at shippable quality, and they hit ZBB.

Motley: What the heck is a "ZBB"?

Maven: "Zero Bug Bounce". It's a moment in time where you have no bugs that are older than, say, three days and there are no ship stoppers. At this point, the team can make a call that quality is high and new features can be developed.

Motley: You called it a "quality sprint". You could also call it an "integration sprint" depending on what your goals are. In fact, that might be a better name for what we are doing now.

Maven: Agreed. The term I don't like ,however, is "stabilization sprint". To me, this implies that the code you wrote was crap to begin with. In reality, there may be things beyond your control that crop up upon integration even though you focused on quality, so I prefer to give it a more positive spin. "Stabilization" also typically implies a huge focus on testing. Testing is part of what happens here, but testing is also happens in every sprint.

Motley: Game it if you want. If it looks like a duck, and quacks like a duck, well, you know. You still have not answered the question as to why I would want to practice Scrum when I am fixing bugs!

Maven: You don't necessarily have to practice Scrum while bug fixing, but you may find it valuable. When your team needs to fit within a larger ship cycle on a big team, you may not have full control over how to structure your bug database. In addition, your team may live within the confines of a waterfall-oriented organization, but you can be agile as a feature team by practicing Scrum and transferring prioritization of fixes to the sprint backlog. The team does the usual sprint planning figuring out which bugs are most important to fix. The sprint backlog is then a prioritized queue of bugs, and devs grab bugs from the queue as soon as they are done fixing their current bug and validating with test.

Motley: Is it really worth the overhead though? I already have my list of things to do in the bug database. Why duplicate it?

Maven: I generally don't consider Scrum as "overhead" - it's a very lightweight process, although I would agree that with any process you arguably get some level of overhead. You could fairly easily write a tool that automatically populated the sprint backlog with the top bugs from the bug database. Note, however, that you also gain the following benefits by practicing Scrum while fixing bugs:

The daily meetings ensure improved communication and collaboration
Data gathered is useful for future planning sessions
Frequent retrospectives allow the team to constantly improve
The team can adjust priorities during the sprint
The team need not rely on a rigid bug database schema, and can use the sprint backlog to customize information about the bugs
The team remains focused, and has a Scrum Master to help

Motley: Fine, fine, fine. We'll try it your way for a sprint and see if it pays off. I did kind of lose track of what Marvin was doing with his bugs and the daily meeting should help.

Note: I'd love to hear some better suggestions on how to deal with the problems discussed in this story. Arguments based on reality (vs. theory) are much appreciated in comments!

______________________________

Maven's Pointer: Here's another argument for tracking time spent on tasks in a sprint: over several short quality-oriented sprints you can gather data on the amount of time it takes to fix each bug. By mining that data, you can compute an average length of time per bug, which helps you with effort estimates for capacity planning on future bug fixes. Our team, for example, knows that it takes just under 5.4 hours of effort to fix an average bug. We can then estimate how many we can fix during any given sprint, and set expectations accordingly.

Maven's Resources:

Scaling Testing in Scrum, by Bob Galen, http://www.agile2007.org/downloads/handouts/Galen_532.pdf

Motley says: "What are we burning down? Your house?" (Scrum Part V)

James Waletzky — Tue, 19 Feb 2008 20:09:00 GMT

Summary

Motley: A burndown chart? What are we burning down? Your house?

Maven: Track time remaining for tasks to generate a burndown. Combine time remaining with time spent to generate a cumulative flow diagram with burndown. Use the charts to get an accurate picture of project progress.

______________________________

[Context: Maven and Motley just arrived at work in the morning and are continuing their discussion on Scrum, this time discussing data analysis]

Maven: Morning, Mot! Want to pick up where we left off in our Scrum conversation?

Motley: Does Superman want kryptonite for breakfast?

Maven: C'mon - this is important stuff. Let's talk a bit about data gathering in Scrum.

Motley: Sounds about as exciting as cleaning the bathroom. I've got stuff to do.

Maven: This won't take long. Previously we talked about the importance of retrospection for a sprint. You had some questions around why we gathered data during the sprint. Well, the basic data that we gather every day is the amount of time remaining on our tasks. We want to be realistic with our estimates - as we execute, we feed the learning back into the plan and make adjustments. For example, if we underestimated a task and it will take longer than expected, we may want to cut some tasks off the bottom of the priority list to set expectations with our stakeholders that we won't deliver everything we set out to deliver. Tracking our new estimates on a day-to-day basis gives us a burndown chart.

Motley: What are we burning down? I'll bring the matches.

Maven: Time in the sprint. We use the burndown chart to get an idea of how the project is trending and whether we are going to meet expectations. The goal is for the burndown line to reach zero at the end of the sprint.

Motley: I guess given the burndown and the fact that we were able to complete a certain number of hours in a sprint, we can use that data to help us plan next time.

Maven: See? I knew you were enthusiastic about this! You are absolutely correct.

Motley: Am I never not correct? I thought you would have learned by now, Mave.

Maven: You need a bit more humility, Mot. Like a friend of mine always says about himself, "I'm a 9, because nobody's perfect." Errrr… wait. Maybe that's not a good example. But I digress. The burndown also works on the product level, so that over several sprints you can see how your overall release is trending.

Also note that you need not estimate in hours as the chart above indicates. Many agile teams use "story points."

Motley: "Story points"? What the heck is that? I am building software, not telling a story!

Maven: Story points are essentially a unit-less measure that describe the size of a requirement in relation to other requirements. Think of a story as a basic requirement written as a scenario from the user's perspective. The reason we use a generic measure like points is to get us out of thinking about hours. The important concept here is that we understand how much work we can do in a sprint, i.e. our velocity, and use that measure to plan future sprints. Story points remove the focus on time and remove the desire to compare across contexts or other teams. The story points become unique to the particular team.

Motley: But how could I possibly have any idea how many "points" a feature will take to build?

Maven: It's tough at the beginning when you don't have anything to compare to. Once you know your team's velocity and how many points you can deliver in an iteration, it becomes more natural.

Motley: Sounds interesting, but I think I'll stick with hours, thank you very much.

Maven: That's fine - whatever works. Let's get back to the data. While the burndown chart is very useful, you can generate much more valuable data if you not only track time remaining on tasks during a Daily Scrum, but also track time spent.

Motley: You have got to be kidding. Tell me you're kidding. You want everyone on the team to report time spent as part of their status?? I am telling you right now that no one on the team is going to like that. They will feel as if their manager is closely tracking every hour of their day. It will lead to micromanaging, morale will decrease, and people will be afraid to take a break. Not going to work.

Maven: I admit, it's controversial, and to be honest, outside the core Scrum process. However, you get much richer data. Plus, the data is for the team only - no one outside the core Scrum team gets access to the individual data. All that matters is the roll-up of time spent. Let me give you an example of a valuable pictorial representation of the data. The chart below is called a "Cumulative Flow Diagram (CFD) with Burndown".

Motley: I'm not convinced on gathering effort expended, but the chart looks interesting. Tell me more.

Maven: What do you think happened in this project?

Motley: Well, the red line seems to be the same as the burndown you showed earlier. There was a hump around day 16, which could indicate that the team underestimated or the plan grew. The grey indicates the total combined hours of tasks that the team has not started, the yellow the number of hours of tasks in progress, and the green the number of hours corresponding to tasks that have been completed. This team had lots of work in progress, had a slow start, grew and then later shrunk the plan, didn't finish all their tasks, and had some areas of poor productivity. Lots of things to look at in a retrospective.

Maven: Nice analysis! See how straight forward the chart is to follow? You can get some great observations out of one diagram. You mentioned that the hump may be due to underestimating or plan change. We can tell for sure by coupling this CFD based on hours with another one having a y-axis of number of work items. A corresponding hump in the work items CFD indicates that the plan grew. Notice anything about the yellow area?

Motley: It's big, but I don't see a problem with that.

Maven: A wide yellow area is generally not a good thing. With a chart like this you only get credit for work that is completed. The minute you log an hour on a large task, you end up with a large yellow area. Let's talk about the danger of that large yellow area later.

Here is another example of a CFD with burndown:

Motley: Wow - this team significantly over-planned. They didn't finish many of the tasks they set out to do. There is also a flat spot that we want to analyze. Why was the team unproductive during that time? Was there a major distraction? They did adjust the plan somewhat, but perhaps not enough. Actually, now that I look closer, this isn't a good sprint. Although they had a good velocity throughout the sprint, it lasted way too long and they didn't adjust the plan enough based on new knowledge. Stakeholders may have been expecting more to be delivered by the end if they checked-in midway. Bad Scrum Master.

Maven: Nicely done, Mot. You would almost think you invented that graph.

Motley: I am brilliant, of course. However, I cannot take credit for inventing that graph. They are easy to understand though, provided we can convince the team to track time spent. I'll see what I can do.

Maven: Just reassure them that the data will not be used against them. In addition, it doesn't take much extra time to track time spent in addition to time remaining. It does allow us to get a complete picture of the project over a short iteration and adjust the plan on-the-fly.

Motley: One more thing - I am still not quite seeing why a wide yellow area is a bad thing.

Maven: Let's save that discussion for another time.

Motley: Ah, that's typically code for "I don't have a clue".

______________________________

Maven's Pointer: There are generally two reasons why wide yellow areas are a sign of trouble. First, it may be a sign that the team has too many tasks in progress at one time.

Human beings are terrible at multi-tasking, but more on that later. Second, it may indicate that the tasks on the sprint are not broken down enough. For example, if you put 1 hour against a 40 hour task, you get 40 hours worth of yellow in the CFD. Estimate tasks from 1 hour to 16 hours in length. It is easier to define "done" and shows that you have more completely thought out the task. Otherwise, the team does not really know what is involved in completing that task, and the estimate is far less accurate.

Maven's Resources:

Tool: Microsoft Scrum Kit (http://go.microsoft.com/fwlink/?LinkId=98602&clcid=0x409): An Excel-based tool that James helped write for internal Microsoft use that is now available via the web through the most excellent "Hard Code" book by Eric Brechner, Director of Development Excellence at Microsoft. See the "Chapter 2" directory in the download.
Using Cumulative Flow Diagrams, by David Anderson, May 2004, http://dn.codegear.com/article/32410
Managing Lean Software Development with Cumulative Flow Diagrams, David Anderson, May 2004, http://bdn1.borland.com/borcon2004/article/paper/0,1963,32096,00.html

Motley says: "Reflection is for mirrors" (Scrum Part IV)

James Waletzky — Tue, 12 Feb 2008 19:50:00 GMT

Summary

Motley: Reflection is for mirrors. We just finished a sprint. Why open up old wounds?

Maven: At the end of a sprint, do a demo for stakeholders, customers, and the team. Do a retrospective to reflect on what went well and what requires improvement. Continually improve the team from one sprint to the next.

______________________________

[Context: In a continuing conversation about Scrum, Maven is about to enlighten Motley on the most effective ways to wrap up a sprint, or short iteration]

Motley: At the end of the sprint, we followed the Scrum process. Everyone did a quick one minute summary of the work they accomplished during the sprint. We then chatted for 5 minutes on how things went. That's it. Don't tell me there's more. This is a lightweight process, right?

Maven: I guess "lightweight" means different things to different people. There are some best practices for the demo and retrospective. It is a valuable exercise to take time to reflect on the past sprint.

Motley: Reflection is for mirrors. What's the point? We just finished the sprint - why open old wounds?

Maven: Hopefully ripping apart flesh is not a good analogy describing your last sprint. It is extremely important to reflect on your last iteration. Let's take the demo. You may wonder why we bother demoing the work we just did. We met on a day-to-day basis and everyone was aware of what each other was doing on a high level. Well, the demo serves a few purposes:

The demo allows stakeholders that may not be directly involved in the sprint to get a first-hand look at the progress the team made. Feel free to invite people not directly involved in sprint work.
The demo allows your customer(s) to provide feedback on the work you did, allowing the team to fold in changes in priority or requirements into the next sprint. Remember, customers love to see working software. Solicit them for feedback and changing priorities and update the product backlog. Incorporate that feedback into your next sprint planning session.
The demo is a chance for the team to celebrate their accomplishments over the past sprint. Seeing working software can really be a morale boost for the team.

Motley: One problem I have with all this is that I don't want the team spending a bunch of time creating demos for the end of sprint meeting when they could be doing real work. Seems like a waste of time.

Maven: Actually, that is a common misunderstanding. You are not out to create a really flashy demo to show off the product. You are simply doing a demonstration of the functionality you just built. There should be no extra gold plating just to look more impressive at the demo meeting. It's not about creating a glitzy demo.

Motley: But what if some members of the team did not work on software directly? They are going to feel left out at demo time.

Maven: Again, don't take the word "demo" too literally. A demo could be a review of a wiki page that was created, a tool somebody wrote, a document that is important to the product, a description of a consulting engagement, or anything else concrete that the team can see some created value from. The demo is typically a 1h meeting that occurs during the slack time between sprints. Make it fun. Bring donuts or burn CDs with interim builds for your stakeholders. Think of the demo as a team building exercise with a celebratory feel.

Motley: Ok, we obviously have room for improvement there. What about the retrospective? What's the point? We just finished the sprint, so we know what just happened.

Maven: The retrospective is a chance to do two primary activities:

Examine what went well in the sprint. It's important to analyze those processes and team procedures that lead to success and to continue to do them. Having a clear idea of what is working ensures everyone on the team knows the best practices and allows you to encourage them to continue doing them. It is also a bit of a morale boost knowing that what you are doing is working. You also want to avoid turning the discussion into a negative whine/gripe session. Remember the retrospective prime directive:

"Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand."

From <http://www.retrospectives.com/pages/retroPrimeDirective.html>

Examine what requires improvement. Perhaps the biggest reason for a retrospective is to focus on continuous improvement, which is one of the principles of agile development. In Japanese, this is called Kaizen ("Kai" = change, "Zen" = good), where you look a system and consider the results and process to get to the results with a non-judgmental focus and goal of improving how you generate results. We want to look at how we can be more effective in the next sprint. Think about what you would do differently next time. Use any metrics you gather for quantitative analysis and use those measures to drive improvements (e.g. Were the estimates off? Why? How can we improve?)

Motley: So we have a quick chat and then improve for next time. Easy.

Maven: Well, there is a bit more to it:

Clarify success. As a team, determine what success would have looked like for this sprint, and will look like for upcoming sprints. "Begin with the end in mind", as Dr. Stephen Covey says. If we apply Human Performance Technology (HPT) as we discussed previously, we can measure the gap between our current state and desired state, determine root causes, and implement interventions to help the team succeed.
Ask everyone to prepare. A bit of up-front reflection prior to the retrospective meeting helps ensure the conversation is valuable.
Give everyone a chance to speak. Chances are good that most people on the team are critical thinkers with a desire to improve. Ensure everyone gets a chance to contribute at least one thing positive about the sprint and one thing negative. Draw out the introverts - they have opinions too. Treat the exercise as a brainstorm - there are no wrong answers. As a last resort, make the comments anonymous.
Create tasks for improvement areas. Write down everything that is said in the meeting, particularly areas for improvement. Create concrete action items out of the improvement areas with assignments and due dates. Put tasks on the next sprint if needed. Make sure the discussion leads to positive change.

Motley: Jeez, Mave. You always put so much structure on everything. Can't we simplify?

Maven: Actually, this is quite simple. Most of this is just small tips to make you more effective. Just remember to focus on what went well, and what requires improvement.

Motley: One other thing that still isn't clear to me though. What the heck was the point of gathering all the data during the sprint? The data seems as useless as most other metrics. You didn't even mention it as part of the retrospective. We spend a lot of effort capturing them, and then no one ever looks at it again.

Maven: Actually, there is great reason to capture the data. And yes, we do use it in the retrospective and throughout the sprint. It's getting late though. Why don't you head home for the day and we can pick this up in the morning.

Motley: Ah, I get it. That's code for you having to head home and do whatever geeky thing you do in the evening. Have fun washing your pocket protector!

______________________________

Maven's Pointer: One of, if not the primary reason for short iterations in agile development is to ensure we get rapid feedback. We want to create a culture of continuous improvement of the product, the team, and ourselves. Although sometimes feedback may be difficult to accept, it is necessary for forward progress. Encourage feedback early and often on not just the product but all parts of your life. It is the best way to get better!

Maven's Resources:

http://www.restrospectives.com: A web site dedicated to the growing practice of looking back to move forward. The retrospective prime directive is found here.
Agile Retrospectives: Making Good Teams Great, by E. Derby, D. Larsen, K. Schwaeber, Pragmatic Bookshelf, ISBN: 0977616649, July 2006

Motley says: "The Daily Scrum meeting is way too much overhead" (Scrum Part III)

James Waletzky — Tue, 05 Feb 2008 20:33:00 GMT

Summary

Motley: We don't need the daily meeting. Very few people got any value out of them, and attendance started to wane near the end.

Maven: An effective daily stand-up involves < 9 people, all team members, everyone attends, and the conversation focuses on answering several directed questions: what have you done since the last time we met, how much time remains on your tasks, what are you going to do until the next time we meet, and are you blocked.

______________________________

[Context: Maven and Motley continue Motley's sprint post-mortem discussion, this time talking about the Daily Stand-up, or Daily Scrum, meeting]

Maven: So we have established that with Scrum the team needs to be involved in planning - it is not a one person operation. You also only want the details for those tasks you know you are going to start with. With Scrum, it is okay to cut tasks as you realize that you won't get to them this sprint. You always cut from the bottom of the priority list.

Motley: Isn't management going to be just a wee-bit upset if we cut stuff? This is flawed.

Maven: Scrum is about being realistic. If you put in tons of extra hours, you eventually burn out. You end up cutting quality to fit in more features, and everyone suffers. We want to establish a realistic velocity.

Motley: You mean Scrum is a project management methodology that deals with reality? Have pigs really started to fly?

Maven: Agile techniques try to prevent burning out the team and delivering as much value as possible in short iterations. Scrum is no different. Let's get back to how your last sprint went. You said that the team held daily status meetings in a conference room that lasted between 30 and 45 minutes?

Motley: Yeah. We talked about a lot of different things during the daily meeting. Most people weren't engaged though - they just sat there silent checking e-mail on their phones and laptops. A couple of us dominated the conversation.

Maven: There's a few things you can try-

Motley: Like not having the meetings? Very few people got any value out of them, and attendance started to wane near the end.

Maven: The meetings are actually extremely valuable to improve collaboration on the team. It is very important that everyone know what each other is working on, plans to work on, and how they can help with blocking issues.

Motley: But they just take too long! It's a distraction.

Maven: Here are a few tips to keep the meetings short and of high value:

Limit the size of the Scrum team to 3-9 people. Any more and there are too many communication paths and too many simultaneous tasks to track.
Ensure that the entire team is present for each Daily Scrum meeting. Everyone, including development, test, and program/project management should be present and contributing.
E-mail is not a sufficient replacement for the Daily Scrum meeting. E-mail adds overhead and does not provide the detail nor a chance for others to ask questions or help unblock another team member.
Each person should answer the following questions:

What have you done since the last time we met?

You want to go into enough detail so that the team has a good idea of what you have accomplished and what progress you made, but not too much detail that it will not interest most people on the team. Avoid answers like "Same as last time", or "I worked on bugs". More detail is necessary to keep everyone in the loop.

How much time remaining on each task you worked on?

With Scrum, you re-estimate your tasks each and every day. As you learn, your estimates may go up and down. If you have underestimated, adjust the plan and set expectations with stakeholders that our lowest priority tasks likely will not be delivered.

What will you do until the next time we meet?

Set expectations for what you will be working on next. This prevents duplicate work and aid other team members if your work is a dependency. Again, no need for a lot of detail, but enough to add value.

Are you blocked?

Blocking issues slow down the team and need to be addressed as soon as possible. Be sure to mention any blocking issues as someone on the team may be able to help. Otherwise, the Scrum Master should do everything he or she can to remove the block.

Motley: That still sounds like a lot of blabbering. The answers to all those questions could still take quite a bit of time!

Maven: Not really - if you focus. Make sure everyone in the meeting stands up. This provides a cue that the meeting will be short, forces people to focus more, and discourages checking of e-mail and other distractions. The Scrum Master should be the facilitator and come prepared. Ensure the Scrum Master has the tool or Excel sheet used to capture the data open prior to the meeting. If someone goes into too much detail or off on a tangent, the Scrum Master is empowered to cut them off and keep things moving.

Motley: Ah, somebody with permission to throw down the hammer! I like that role. It suits me!

Maven: Just remember that the Scrum Master is not the leader of the team, but the point-person for outside communication, the data gatherer, and the facilitator. The team makes decisions related to the project. The team is empowered to do whatever is necessary to finish the work, which includes cutting the lowest priority tasks to ensure the high priority tasks are completed.

Motley: You're ruining my fun. I thought the Scrum Master would be the dictator of the team. It sounded like a fun role. I would have renamed it "President".

Maven: Get your head out of the bushes. Scrum is about the team, and the team is self-directed. If there is a problem delivering a work item, the team is empowered to make the right decisions to fix the issue. Another suggestion is to not have the lead or manager of the team in the organizational hierarchy be the Scrum Master. Instead, choose someone else, and rotate the role every sprint. Following these guidelines helps send the message that the Scrum Master is not the leader of the team, but instead helps drive to completion and remove roadblocks.

Motley: Now you're REALLY ruining my fun. Then who makes the best Scrum Master?

Maven: There really is no right answer to that. Testers make great Scrum Masters as they look at the product and work items objectively and have an eye towards quality. Project Managers make less effective Scrum Masters as they may also be acting as the Product owners, and having the Scrum Master and Product owner be the same person is a conflict of interest. The Product owner acts in the best interest of the overall product, and the Scrum Master has to (a) translate product language to the language of the team, and (b) help ensure the highest priority work gets done and not be afraid to add tasks, re-estimate, and cut lower priority tasks.

Motley: Fine. Fine. So we did a few things wrong this time around. Now I suppose you are going to tell me that we messed up the demo and retrospective as well?

Maven: Well-

Motley: Ugh. Let me sit down. I am sensing this is a longer conversation than a daily stand-up.

______________________________

Maven's Pointer: Use a good tool for tracking your sprint data, including the estimates that are updated in a Daily Scrum meeting. As we will see when we talk about data analysis and the retrospective, having valuable data aids in planning the succeeding sprint. You also get an incredibly good snapshot of how you are doing as the sprint progresses. See the resources section below for some recommended tools.

Maven's Resources:

It's Not Just Standing Up: Patterns of Daily Stand-up Meetings, by Jason Yip, http://martinfowler.com/articles/itsNotJustStandingUp.html
Tool: Microsoft Scrum Kit (http://go.microsoft.com/fwlink/?LinkId=98602&clcid=0x409): An Excel-based tool that James helped write for internal Microsoft use that is now available via the web through the most excellent "Hard Code" book by Eric Brechner, Director of Development Excellence at Microsoft. See the "Chapter 2" directory in the download.
Tool: Microsoft eScrum (http://blogs.msdn.com/robcaron/archive/2007/06/12/3261753.aspx): eScrum is a freely available tool built internally at Microsoft to manage a Scrum team over the web with a Visual Studio Team Foundation Server backend.

Motley says: "We tried Scrum, and it sucks" (Scrum Part II)

James Waletzky — Tue, 29 Jan 2008 18:27:00 GMT

Summary

Motley: We tried Scrum, and it sucks. The team hated it.

Maven: Apply Scrum patterns and avoid the antipatterns. Some Scrum best practices include including the Product Owner in product backlog creation, including the team in planning, using Planning Poker to estimate tasks, having a meaning of "done" against each task, and assigning tasks just-in-time.

______________________________

[Context: Motley's team has just completed it's first two week sprint and had some issues. Motley wants some help from Maven to get some best practices]

Motley: Scrum sucks. We just finished a two week sprint and people hated it. The daily status meeting took up too much time, we were never sure when tasks are finished, and team members generally did not see the value in the process. Here's a summary of what we did:

We sat down for 15 minutes and built the product backlog
I took another 20 minutes and planned the sprint
We held daily status meetings in a conference room that lasted between 30 and 45 minutes
Everyone did a one minute summary of the work they accomplished when the sprint was over
We did a 5 minute retrospective to talk about our work
We ditched Scrum because it sucks

I'm thinking of making up some "Scrum is a sport, not a software process. Scrum sucks." shirts and selling them on the Internet, but it might upset the Australians.

Maven: I am sensing negative energy! Away with the negative energy! Shields up! Let's turn this into something positive, shall we?

Motley: You mean make Scrum suck less?

Maven: Errrr, yeah, I guess. Let's look at some of your troubles. What kind of items did you have on your product backlog?

Motley: I sat down as Scrum Master and created a list of tasks we needed to accomplish over the next few weeks, like running FxCop on the new component that Martin built.

Maven: The Product Backlog should generally consist of bigger ticket items that are product-oriented. Running FxCop on a component is a task that is involved in completing work on the product. When building the product backlog, the Product Owner (someone that can act as the voice of the customer) must be involved to help prioritize which features are most important. From that conversation you create a stank-ranked (prioritized) list with the most important features at the top. It is also a good idea to attach estimates to each item, although they need not be precise. T-Shirt costing (S, M, L, XL, etc.) works well. You want to have a rough idea of how much work you can put in a sprint. Try to have the product backlog in decent shape before your planning meeting.

Motley: I guess that takes longer than 15 minutes and involves other people. Whoops. I am assuming that I should not have been the only one to plan the sprint?

Maven: There really are no "individuals" in Scrum. Scrum is all about the team. We succeed or fail as a team. Although the Scrum Master role is there to facilitate, capture data, and unblock the team, that person is not a dictator. For planning, get the team together for as long as it takes to plan your sprint. Starting with a 2 week sprint is sufficient for your first time, as it is not a huge amount to plan and it ensures you get feedback on how you are doing in the near future (instead of waiting a month).

Motley: What else do we do in planning?

Maven: As a group, you want to decide what you can get done in a two week sprint. Since you don't have any historical data at this point, you'll have to make a guess as to how much work you can accomplish in the sprint. That can be a little tricky, but here's a way to do it:

Determine the theoretical number of ideal effort hours the team has available during the sprint. For example, in a team of 4 assuming 40 hour work weeks (ideal) over two weeks, you have 4 * 40 * 2 = 320 hours.
Remove any planned interruptions from that total. For example, say you have the only planned interruption during the two weeks and it's a 4 hour doctor's appointment to flush your system. Subtract that and get 320 - 4 = 316 hours.
Now, guess how much real work, or on-task time, you get during a typical day and express it as a percentage. If you think you get 4 hours done in an 8 hour day, use 50%. Multiply this "load factor" by the number of hours you have available to get 316 * 0.5 = 158 hours.
Pull off as many items off the product backlog that you think you can do in 158 hours. This list becomes your sprint backlog.

Motley: I don't like guessing. Did you pull a load factor of 50% out of your butt? Where did that come from?

Maven: Right now you don't know exactly what your load factor is, so the first sprint will be a guess. At the end of the sprint, you'll have some data to provide you with a more accurate load factor to use for planning the next sprint.

Motley: Fine. I think 50% is a little low though. How about more like 95%? We're efficient.

Maven: How much time do you spend talking to people, responding to e-mail, surfing the web, taking bathroom breaks, attending meetings, etc.?

Motley: Well, if you include all that stuff, I guess it's lower. Let's go with 60% to start.

Maven: That will work. Once you have populated your sprint backlog with the items you should take the highest priority items and break them down into specific tasks. That's where something like "Run FxCop on Martin's component would fit. For each task we'll assign an estimate using Planning Poker. Remember we talked about Planning Poker previously?

Motley: Yeah. I'm still waiting for my Royal Flush. Oh wait, you said I got that at the doc.

Maven: Nice tie in. We make a good comedy team.

Motley: Well, in this case there is an "I" in team. Me.

Maven: Another best practice for sprint tasks is that they are estimated between 4-16 hours. If they are larger, you haven't thought through the task enough and it needs to be more granular.

Motley: Check. That's generally a good rule of estimating anyway, Scrum or not.

Maven: Now a very important piece of planning. Each task on the sprint should have a definition of "done". It needs to be extremely clear what is involved to fully complete a task. With Scrum, we don't get any credit for work that is not yet completed. For the meaning of "done" for running FxCop on Martin's component, for example, what makes it "done"? One suggestion is to run the tool, mark off false positives, triage all PRI1 and PRI2 violations, make the fix, write a test, check-in the fix, and have test validate it. See how detailed we get? That way there is no confusion when someone reports their progress on the task.

Motley: That will be a lot of work, won't it?

Maven: It actually goes pretty quickly, but obviously takes longer than 20 minutes to plan a sprint. Once we have the top priority tasks broken down with estimates, we're ready to assign each person on the team a task and start executing.

Motley: Wait - why do we only assign one task and not all? Why don't we break down all tasks?

Maven: Tasks are assigned just-in-time. Ideally we only want one person working on one task (more on this later). Why don't we break down all tasks? Because that would be wasted effort if we end up cutting some tasks from the sprint.

Motley: Cut? Why would we cut?

Maven: Let's go grab a hot chocolate. I'll run down a few more Scrum antipatterns and patterns to help you out in the next sprint.

Motley: … if there is a next sprint!

______________________________

Maven's Pointer: Don't conclude that Scrum sucks after just one sprint. It is a different way of thinking about project management and it takes time to find a rhythm. At Microsoft, we recommend that teams stick with the process for at least 3 sprints. The first sprint is an experiment - plan to make mistakes. Come up with actionable feedback in the retrospective. Put the feedback into play in sprint 2 and make further refinements. By sprint 3, you'll start to see what your team is capable of once you have some Scrum learning.

Also a word about load factor: it's amazing how many distractions we get during the day that take us away from our sprint tasks. The previous team I was on at Microsoft consistently had a load factor of about 33%. My new team at Microsoft gets in the range of 35% to 40%. Once you understand your load factor, you can plan more accurately and look at the root cause for a low load factor, thus making you more efficient in later sprints.

Maven's Resources:

Various presentations on Scrum by Mike Cohn and Mountain Goat Software: http://www.mountaingoatsoftware.com/presentations_scrum

Motley says: "What does Rugby have to do with software?" (Scrum Part I)

James Waletzky — Tue, 22 Jan 2008 19:03:00 GMT

Summary

Motley: Scrum? Does that mean team members have to carry a ball and tackle each other in the hallway?

Maven: Scrum is an agile project management methodology that follows agile principles. The process is build a product backlog, plan the sprint, execute and meet daily, demo the work, do a retrospective, and repeat.

______________________________

[Context: Motley has been thinking about how to apply agile principles to an overall project schedule]

Motley: We talked about agile development in the past, and now I am trying to figure out how it applies to running a project. We chatted about Test-Driven Development (TDD) as a development practice, but what about overall project scheduling? Are there any agile methods for that?

Maven: Yes. Actually, one of the most popular agile project management methodologies is "Scrum".

Motley: "Scrum?" Isn't that a Rugby term? What the heck does Rugby have to do with software development?

Maven: No padding and lots of people get hurt.

Motley: Ha! Mave actually has a bit of a sense of humor. And I thought the only thing funny about you was your haircut!

Maven: What's wrong with my haircut?!? Never mind. Anyway, Scrum is an agile project management methodology that focuses on the agile principles we talked about previously, namely short iterations, continuous improvement and feedback, embracing change, and collaboration. It is a simple, lightweight process that has many benefits.

Motley: Do team members have to carry around a ball and tackle each other in the hallways.

Maven: It's not mandatory, but if you feel it makes you more productive, go for it! Well, on second thought, don't. Might not be best for team health. I've got lots of experience with Scrum and it is a fantastic way to run many types of projects.

Motley: This agile thing is actually pretty cool and has some benefits. Okay, I'll ask. I am curious how we could apply it here. What is this "Scrum"?

Maven: Scrum is all about running projects in an agile fashion. It's not about doing development. First, let's see how Scrum fits into the agile principles we discussed previously:

Keep it simple: Scrum itself is a very simple, lightweight process that allows us to keep development simple.
Embrace Change: Scrum encourages work in small chunks. We focus for short time periods but in between those periods we can re-prioritize the work we do.
Incrementally iterate: We build an application in small chunks over iterations that last no more than 30 days.
Continuous feedback and improvement: At the end of an iteration of work, we always look back at how we did and figure out what we can do differently next time to improve.
Collaborate: Scrum strongly encourages communication and collaboration among team members. It doesn't work without it.
Eliminate waste: Scrum helps us only do work that adds value to the customer or the team.

Motley: Ok, I remember those principles. You're not giving me much here though. How do I practice Scrum?

Maven: Scrum can be broken down into a few key steps. Before we do that, I need to cover a few basic definitions:

Product Backlog: think of the product backlog as a high level, prioritized list of everything you want to build. These can be user stories as used by Extreme Programming or simply one-liner feature descriptions. The important part is that the work is prioritized. As you pull items off the list to work on, you always work on what adds the most value.
Sprint: A sprint is a short iteration of work that happens over a maximum of 30 days. A sprint has a goal associated with it.
Sprint Backlog: A list of work items for a sprint. A sprint backlog starts with some items from the product backlog and then breaks them down into specific tasks, each with a meaning of "done" associated with it.
Product owner: The person that is responsible for maintaining the product backlog and making decisions about feature priorities. The product owner is usually not an active team member during a sprint.

Motley: You're already getting technical on me. What's with all the new terminology? Why not something simpler like "feature list". Wouldn't that be more in line with agile principles?

Maven: Hmmm… don't know what to say there. I guess the "product" part emphasizes the long-term nature of the list, and the backlog is stuff that we haven't yet gotten to. Makes sense. With "sprint", we are running a marathon (building the product) but doing it in short bursts (iterations) with breaks in between.

Motley: Fine, fine. I'll get used to it. What's the process?

Maven: It's actually quite easy. Here it is:

Build the product backlog
Plan the sprint
Execute and meet daily
Show a demonstration of completed work
Do a retrospective
Have some slack time, and repeat

Motley: That's it? Sounds pretty simple. Obviously I need a bit more detail on those steps.

Maven: Your wish is my command!

Motley: Get me a burger.

Maven: Not every wish is my command! Let's get back to Scrum. I'll give you a quick overview of the steps in the process first, and then in a later conversation we can go into some best practices for each of the steps. Sound okay?

Motley: Sounds better than an enema. Get on with it.

Maven: When you build the product backlog, the team, together with the product owner, determines what features are important to the customer and creates a stank-ranked (prioritized) list of all the features. The most important features are at the top of the list.

Motley: This requires some up-front thinking - isn't that contrary to agile?

Maven: This is planning on a very high level. It's our rough vision for what the user wants as of today. It could change tomorrow. The next step is to plan the sprint. Here we take the top priority items from the product backlog and plan to delivery them in completed state. How many? As many as you think you can build in the current iteration. We then break down each product backlog item into sprint backlog tasks and start executing.

Motley: Cool. Sounds easy. But how do I know what to work on next?

Maven: Each person should be assigned one task during planning so that they know what to work on. After that, as you finish a task, you take another one that is unassigned and is the highest priority. After we have a plan, we then execute and meet daily. We work through the sprint tasks and everyday we estimate how much time is remaining on the task. We are always realistic with ourselves about how long tasks take, and if they take longer than normal, we start cutting tasks that are lowest priority. Also, every day we meet for a status meeting.

Motley: Ok, now you are off your rocker! You want to have a status meeting every day? One status meeting a week is painful enough. I think you have been into the glue again.

Maven: I admit - it sounds crazy. But the meeting is very short, like on the order of 10 minutes for a small team of 5. I can talk about how to keep it short later, if you like. After the sprint is complete, we show a demonstration of completed work. This short meeting allows the team to celebrate what it has done and inform stakeholders of completed work.

Motley: I am assuming the customer, or the voice of the customer like the product owner, is there? They are probably curious to see the work.

Maven: Absolutely! Anyone with a stake in the project, including the customer, should be at the demo. The sprint ends with a retrospective. This is the team's chance to look at what went well (and continue doing it) and determine what we can do differently to improve next time.

Motley: Ah, the continuous improvement piece. Pretty straightforward process. I like it.

Maven: After the current sprint is done, you reprioritize the backlog once again and have a new planning session. Then you do it all over again and deliver yet more value to the customer.

Motley: Well, let me try it with the team and do a two week sprint. Perhaps you and I can have a retrospective in a couple of weeks and you can give us a few more tips.

Maven: Wow - look at that pig flying! You actually want my help?!?

Motley: <silence>

______________________________

Maven's Pointer: As step 6 in the process states, it's important to have at least a couple days of slack time in between sprints. Give the team a chance to take a breather and catch up on some non-sprint activities. This is a good chance to catch up on some technology or tools issues and regroup. You'll find yourself more effective by slowing down. It's called a "sprint" for a reason - you cannot sustain the pace indefinitely.

Maven's Resources:

Agile Project Management with Scrum, by Ken Schwaeber, Microsoft Press, ISBN: 073561993X, March 2004.
Ken Schwaeber's Company: http://www.controlchaos.com/