If you choose to implement Scrum, the most widely adopted Agile Methodology, then you will need to do synchronous work within short time-boxes, called Sprints. A Sprint, according to Wikipedia, is “a time period (typically 2–4 weeks) in which development occurs on a set of backlog items that the Team has committed to. Also commonly referred to as a Time-box.” This definition is somewhat vague. My equally vague definition of a Sprint is, “a set span of time (between 1 day and 4 weeks), in which, Done-Done is achieved.” So, what is Done-Done? Well, that is up to the team to determine and agree to based on their domain. This is why the Sprint definitions are purposefully vague.
For me, at the most basic level, Done-Done means that the feature (or story) is coded and tested. This means that while your developers are coding, the testers will be writing test cases and hopefully, testing the features as they become available to test. Also, it is likely that your developers will need to work together on the same feature, so that they can complete it faster. This is quite a bit different from more traditional approaches to software development, where individuals are responsible for an entire feature or an entire layer spanning multiple features.
So, why would we change the way we develop software? Simply put, employing Sprints correctly reduces cycle time in our feedback loops and minimizes and/or removes the 7 wastes of software development (OK, maybe not so simple). This allows us to:
- Get from idea to usable product faster
- Better predict project timelines
- Increase internal and external quality of the product
- Increase value delivered by always working on the items with the highest business value
- Fail fast
- Inspect and adapt at the team and development process level at regular intervals to drive continuous improvement
- Receive user input and course corrections at regular intervals
- Minimize over-production of code, tests, documentation, functionality, etc.
- Know where we are at any given point in time, based on fully functioning, business value-add features
- Reduce work-in-progress by achieving Done Done every Sprint
These are big promises. So, how can we possibly achieve all of these things? Well, there are many things that need to be done to ensure that we meet the expectations set above. Each of the practices or processes listed below are essential to successfully implementing Sprints.
- Collectively define Done Done
- Keep the backlog well groomed (INVEST)
- Keep a focus on quality
- Automate (builds, tests, reporting, etc.)
- Collaborate continuously & communicate openly and freely
- Control work-in-progress (Focus)
- Create clear role definition
- Maintain transparency and visibility
- Swarm issues (mob mentality)
- Keep the Product Owner highly engaged
- Protect the team
There is most certainly more that can be done to ensure the success of a team, but these are the base. Teams should work to master the base before they begin adding new practices or processes.
More to come on the benefits and the base practices and processes of Sprints.
Agile Sean 
Jordan
April 15, 2011
Hi Sean
Glad to see you posting again…
I’m not sure but maybe I’m missing your point….
But in our earlier discussion we had talked about Synchronization as a bottleneck in a Sprint because everyone is working on the same thing at the same time…
Specifically you had mentioned that the last half of a sprint exhibits this behavior, and I had brought up the source code multiple people merging same files etc…
How do you propose solving these issues?
In my view the Scrum/Sprint mechanism exacerbates these issues but does not address them.
Regards,
Jordan
Sean Heuer
April 16, 2011
Hey Jordan,
I actually started down the path of writing about the pain points that can be attributed to Sprints and it quickly evolved it this; the benefits of Sprints done well and the behaviors that are key to success. That being said, I probably should have changed the title.
I have definitely see the issue of work build-up at the end of a Sprint and a scramble to get the Sprint items to Done Done. I believe this symptom is a Scrum Smell. Meaning, the team is likely struggling with one of the base behaviors.
To prevent the piling up of unfinished work at the end of the Sprint, I would help the team learn how to breakdown the features or stories into smaller chunks. This should help them get items to Done Done throughout the Sprint, instead of everything at the end. I would also work with them to figure out what they need to do to reduce WIP and collaborate to focus on completing small chunks as a team. This leads to the feel of ‘too many cooks in the kitchen.’ The only way I know to reduce this pain is to teach strong engineering practices and vigorous collaboration. Employing TDD and Continuous Integration are a must. If the team is open to pair programming, I would definitely promote that as well.
Now, is this easy? No, it most definitely is not. But learning how to use these tools and work in increasingly small increments can be very powerful (IMHO).
I’m not sure I really offered any real, clear-cut solution there, but I think the common Scrum Smells like the one you mentioned can be the result of any one key behavior done poorly or the combination of many key behaviors falling just short of excellence.
I appologize if this ia poorly written or seems scrambled. I am responding from my cell phone 🙂
I would love to hear your thoughts on the benefits and painpoints associated with the XP engineering practices (TDD, CI, Simple Design, etc.). Do you think these practices done well can help with the Sprint pain?
Jordan
April 16, 2011
Actually, I don’t think that breaking things up into smaller pieces helps at all.
After all, regardless of how small the pieces are, 1/2 of them will have to be done in the last half of the sprint, and some of them will have to be done in the last day or 2 of the sprint.
I think this pain is endemic to the “4 stroke engine” mode of sprint compared to the jet engine I described in your other post.
No, I don’t think XP helps; if anything it exacerbates the issue.
I’m curious since we both agree that change should not be undertaken lightly; what was the criterion for accepting the change to Scrum?
What “proof” did you have of ROI? What %delta of improvement were you promised/expecting?
I am curious about that in general as far as corporate america.
Definitely as far as cooks, too many in the kitchen, and even worse, with Scrum and XP, they are taught to only fetch one ingredient at a time…certainly this has repercussions…
Jordan
Sean Heuer
April 21, 2011
Hey Jordan,
Sorry for the delay in responding. I started a new job this week and things have been a bit hectic.
I’m interested in digging into the issues you see with XP engineering practices. What about the XP engineering practices do you believe exacerbates the issues? I am trying not to make assumptions here (on my self improvement list 🙂 ).
Here is a quick reference for some Agile Proof data found in post by Scott Ambler, Answering the “Where is the Proof That Agile Methods Work” Question. There are also some great studies that have been conducted by Cutter Consortium, that show significant improvements when Agile is used.
-Sean
Jordan
April 24, 2011
That’s great. Is your new job at the same company or a different one?
That url doesn’t offer much in the way of proof….actually…. and I was asking about Scrum in particular not “agile” in general.
Nothing seems to substantiate the graphs that ambler provides.
Jordan
Sean Heuer
April 25, 2011
My new job is with a new company. I am now a part of the consulting world.
Here is a link to the data in Amblers post (http://www.ambysoft.com/surveys/success2007.html). I believe he provides details behind his collection methods and the actual data collected.
As for something specifically to Scrum, that may be tougher. I believe Cutter Consortium did a study that Michael Mah talks about in many of the keynotes he does. But, you have to pay for the detailed reports. Hopefully, my new boss will fund some research for me and I will be able to see these detailed reports, but until then, I’m stuck providing a link (http://www.cutter.com/forms/browse.html). I will do some more digging this week to see what I can come up with.
-Sean
Jordan
April 25, 2011
Well congrats 🙂 That makes us both consultants then. Are you telecommuting now 🙂
I think it’s amazing that there is little in the way of any proof that Scrum works, and yet Scrum is becoming the most widely adopted “Agile” methodology.
How can it be justified to have this conversion when there is little if any public proof that it is even effective?
Jordan
Sean Heuer
April 25, 2011
Haha… funny you should ask that. In my first day, I found out that the client didn’t have room for the team to be on-site, so most of them telecommute. They are actually working on building a team area for them to be collocated in. I’m hoping to get involved with that and gather some more data and feedback. I will definitely be blogging about it.
So, I did some more looking and I found someone in a similar situation with a team that wanted ‘proof.’ Here is his blog post on the topic… http://agilepainrelief.com/notesfromatooluser/2008/11/scrum-case-studies.html. There is also a case study that I found very interesting a while back, but they haven’t posted a ton of information or background yet (Shock Therapy: http://rapidscrum.com/shock.php).
I hope to be able to build a case study of my own to help enable other teams adopt Scrum. I have some good data that shows drastic improvements, but I haven’t attempted to pull it all together into a case study yet.
-Sean
Sean Heuer
April 25, 2011
more links…
Jordan
April 25, 2011
Well sumamrize them.. 🙂 are there any solid numbers in those studies or are they more paid advertisements like most I’ve read?
Jordan