On Making Scrum Work

A few random thoughts on Scrum that I sent to an old friend:



My 2 cents based on what I've seen here, and what the process was like there when I left:

<soapbox>

Adding more pomp and circumstance to the monthly sprint meetings is important for everyone. I know some of the Scrum people talk about limiting prep time to 20 minutes for sprint reviews, but I think that allowing a 2-3 day transition period to complete a sprint, hold the review meeting and the retrospective, and then move into sprint planning is really important for sanity and productivity.

Make the success or failure of a sprint dependent on meeting the Goals, not completing Backlog Items (or work tasks!). It's all about using the right level of abstraction in each meeting (are we talking about goals, backlog items, or tasks right now?) The goals have to be discrete and clearly define their 'done' criteria (Goal: Complete the port to Postgres 8.1. Done when then installer can successfully perform an update to 8.1, and JBoss can successfully instantiate a connection in the connection pool.) I start the sprint review by reading the goals aloud, then everybody shows what they worked on, then I ask the project manager one by one if he thinks we've met each of the goals. If you're focused on the big picture in the sprint review, and not on individual backlog items that could have slipped, you're setting yourself up for success.

Make Rob (big boss) attend the sprint reviews, but don't allow Rob (big boss) OR Kris (dev. manager) to attend the retrospectives. Here, I've usually been able to consistently preach 'sustainable pace' and leaving at the same time every day. Just the pressure of having the other developers and the big boss present at the sprint review has almost always been enough to make people personally invested in meeting deadlines. Holding a formal retrospective, but only inviting Pigs was important here in creating a safe environment for people to be self-critical.

Have real sprint planning sessions. Everyone (Kris, Jon, developers AND qa) needs to sit around a table together and stay until it's done; individual estimates really have turned out to be less accurate than group estimates, even when the person to do the coding is known ahead of time. Ideally the ScrumMaster needs to show up with a prioritized list of backlog items, and the main focus of the meeting can be providing high level estimates and negotiating on which items will be put into the sprint. Definitely don't leave the room without story point assignments to every item in the new sprint, and have a good solid line between the last-priority item for the current sprint and the top-priority item for the next sprint. Developers can brake down story point estimates into hour estimates over the following hours or next couple days (preferably all together, definitely not all alone).

Have daily standups with a printout or poster or big monitor showing the current sprint where everyone can see it. The meetings are much more productive when centered around the TASK in the sprint backlog that someone was working on rather than just reiterating their own description of the backlog item every day. It isn't valuable to hear: Yesterday I was working on the Unicode conversion. More of the same today. More valuable is: Yesterday I spent 6 hours on the 'Get variable reporting to use unicode strings' task, and it's done now. I spent 2 hours on 'Convert variable reporting xml data in postgres from ASCII to Unicode; that's going fine, and the new estimate is 3 hours. This morning I'll finish that up, then move on to 'Write the JUnit test to validate the Unicode conversion' task. My impediment from yesterday is cleared because Jared is back in the office and showed me how to set up the new JUnit framework'

Here at xyz, just seeing that the scrum process get kick started and having 2 back to back sprint reviews where we exceeded expectations did more to change the heavy handed management than anything we could have negotiated ahead of time.

</soapbox>