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


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:



  1. Build the product backlog

  2. Plan the sprint

  3. Execute and meet daily

  4. Show a demonstration of completed work

  5. Do a retrospective

  6. 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/

Comments (2)

  1. Richard says:

    Having worked in an agile environment which uses scrums and sprints for the last 7 months, I have to say that a huge weakness (at least in how we do it) is in the slippery definition of "completed work".

    If your requirements are ambiguous or vague or even lacking for a particular feature (as ours are) and you don’t run any automated tests or unit tests or regressions tests (as we do), then there’s little difference between agile and standard crisis management.

  2. Richard,

    I totally agree with you. The meaning of "done" is extremely important to Scrum. In fact, that is a decent-sized chunk of the conversation in part 2 of this article.

    For your second comment, to me, automated unit tests and agile go hand in hand. Tests are a precursor to refactoring, which is a mandatory technique to keep a code base clean and of high quality.

    Ambiguous requirements can actually be okay, as long as your requirements engineers, developers and testers are all working together to satisfy the same goal. Scrum is great for that. You build a little, get feedback, build a little more, get feedback, etc. That feedback loop helps you embrace change and ensure you build the right thing, even as requirements change.

Skip to main content