Joe White’s Blog

This was a small group, in a small room with a whiteboard, so it was fairly interactive. That means lots of Q&A, which means we jumped all over the place and it looks pretty haphazard in written form. Oh well.

How to Make Scrum Really Work
Joel Semeniuk
Imaginet Resources Corp

Scrum teams are 6.5 times more effective than waterfall teams. (Pity they didn’t cite a source. Anyone got a reference?)

How Scrum works

• Lots of feedback mechanisms: between team members, re quality of software, with user community
• Processes that support feedback mechanisms: daily scrums, sprint
• Sprint = iteration. Generally 2-4 weeks. Design, code, test, deploy.
• Sprint review: demo to customers, get feedback.
• Sprint retrospective: Not necessarily every sprint (though that’s debatable, see Juan’s comments). How did it go? How was the process? Did we feel like this was a successful sprint? What made it successful? If weak, what was the problem? Be constructive. Make sure everybody knows what the team did well.
• Scrum is a process framework: there are no absolutes beyond the key principles. Continuous process improvement (with the retrospect).
• House: “You don’t tell your dog to stop peeing on the carpet once a year.”

Roles:

• Scrum Master. Coach. They take stuff out of the way of the team, to make you more productive. Take away impediments.
• Team members (everyone involved in building the software, so includes QA, people who set requirements, etc.)
• Pigs and Chickens
• Chicken doesn’t have deliverables.
• Pig has skin in the game.
• When you make ham and eggs, the chicken is involved, but the pig is committed.
• In some organizations, at the daily scrum, only the pigs talk. Chickens can observe.
• Pass a token; only the person with the token can talk.

Is the scrum first thing in the morning? — Do all your devs get in at the same time? (Ha.)

How do you keep a daily scrum short? (Especially when remote.) — Scrum Master is the moderator, and will say, “Rat hole.”

• What did we do yesterday?
• What are we going to do today?
• What are our impediments?

Backlog

• Bucket of stuff that needs to get done
• Can assign backlog items to sprints
• Sprint planning: reconfirm what you have, do decomposition to make it more real
• If you do internal development, you can plan as you go. If you do contracting or fixed-bid work, you need to spend more time on planning.

Scrum is about what’s next. What about management wanting deliverable dates, when Agile tends to be about discovering stuff as we go?

• Ken Schwaber: Have a bigger preparation phase, lay out a vision
• Convince the customer that you can allow change
• Change is gonna happen
• We’re allowing the customer to change their mind, by re-prioritizing, changing the schedule, replacing features with others of the same size
• Prioritizing of backlog is absolutely necessary
• Track everything: changes in priority, changing out features. Just because we’re doing agile doesn’t mean we throw out best practices about change management.
• Might be able to win projects even if you refuse to do a fixed bid. Can’t fix all three aspects of the Iron Triangle, which makes for an adversarial customer relationship. Can say, “I understand your budget. We think it’ll be this much. Let’s keep features flexible, and stay aware of the business value of each one.”
• Sometimes Scrum isn’t the right model, especially when there’s a lack of trust.
• Aside: Every team should have a nap room.

Suggested story pattern: “As a <role> I want <ability> so that <benefit>.”

Team System plug-ins to help manage sprints electronically:

• Conchango
• MSF for Agile
• Lightweight Scrum Process Template
• eScrum template (Microsoft)

User stories

• Three things:
• What I’m trying to do
• Conversation about that user story: what fields? what reports? Record that in the work item.
• Acceptance test, in the terminology of the user.
• Suggestion: “Sprint 0″ = planning sprint.
• Product backlog: User Stories.
• Sprint backlog: tasks that need to be done to complete those user stories.

Estimation. One possible technique:

• Rate each story for:
• Complexity (1 to 5)
• Business value (1 to 5)
• If it’s got a complexity of 5, you must decompose.
• Rock/paper/scissors-style estimation. If you’re off by more than one, we don’t have the same understanding of the problem.
• Why use a made-up scale instead of hours? — Don’t want it to turn into a budget for the developers. “Student syndrome”. If it was estimated at a day, the programmer thinks they have a day to do it. Instead, the dev should do the necessary work, no less and no more.
• Try to discourange single-point estimation. (I think they meant single-axis, which is why they suggest rating both complexity and value. It’s been a few days, though, so I might be remembering wrong.)
• Another suggestion: minimum / most probable / maximum time.
• Another suggestion: estimate + certainty.
• The guy who did order-of-magnitude estimation does hours during execution: how many hours spent, how many estimated hours remaining.

Impediments (obstacles)

• They have a flag on their work-item database called “Issue”. That seems way too slow-response to me — shouldn’t you just walk over and talk to the customer?
• Risk management.
• Mitigate risk. How to lower impact or lower probability?
• Trigger. When is it not a risk anymore, and now a Problem? What’s the contingency?
• Mitigations are tasks in your backlog.
• Can become a rat-hole.
• Bottom line: anticipate problems.

Scrum of Scrums

• Each team has their own scrum meeting
• A few people from each team do a combined scrum, so the teams have some idea of where other teams are

What do you do when your backlog is hundreds of stories long?

• Consider feature-driven development. Major features, feature sets, features. Structure your backlog that way.

They don’t like teams bigger than 7.

Scrum scaling: “team of teams”. But even so, after about 50 people, scaling on team of teams degrades quickly. FDD scales better.

Amazon: Two-large-pizza rule. A team can’t be bigger than can be fed by two large pizzas. (So, two people, right?)

How to deal with scope creep? — Need a big, burly scrum master. Bring the customer in, lay the cards on the table, and ask what they want to give up. As long as you haven’t started the task, you can change the sprint by trading something out.

Time, Resources, Features: Pick 2.

Side quote: “Drive-by chickens”

So you do the estimates, make the commitment, more requirements emerge, and they don’t want to take more time for them? — Maybe you can’t do agile. Do requirements up front and then change-report the snot out of it.

If your velocity suddenly changes and you figure it out mid-sprint, figure out why. Don’t re-estimate; adjust your velocity.

Some metrics:

• Stories per sprint
• Complexity points per sprint
• Burndown chart

Audience suggestion: Anyone can stop the sprint and call a meeting to resolve something.

End of iteration and not done? — Cover it in the review, move it to the next sprint. Drop from sprint release; remove from the build. That work didn’t get done. Milestones: nothing is 82% done.

If you really don’t want wiggle room at the end of the sprint, put the end of the sprint on a Wednesday. Student syndrome — not thinking about it until the last minute.

This entry was posted on Monday, June 9th, 2008 at 8:31 pm and is filed under .NET, Delphi, Programming. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.