Scrum: What We Were Missing

Last week was an interesting one for us.  We finished our first sprint of the new year using a few new Scrum tecniques, and I discovered some interesting lessons about Scrum, and how they pertain to productivity.  We've been trying to practice Scrum for a few years now, but things never felt quite right.  Here's what I think we were missing:

• Close contact with business owners.  Only recently have we had business owners working with us to plan sprints and attend the daily standups.  This boosts productivity in a few ways: first, the close involvement of business owners gives developers someone to work for.  I can try to re-transmit the needs and pressures of a business owner, but there's nothing like having them around, in person, keeping things on track in a way that provides the most value for them.  Second, without business owners we're left on our own to make dozens of small decisions each day about the direction of a project.  Hopefully we've learned to do this well, but having someone help us make these quick, small business decisions has already proved useful in pushing things forward more quickly.
• Demos.  We had our first demo on Friday, in front of a number of department heads and other interested parties.  It was wonderful.  I can't believe we haven't been doing these from the start.  It gave the developers a chance to show off their stuff, and people clapped -- when else does that happen in a programmer's life?  It provided them with "positive pressure," as one coder put it, that motivated them to complete the tasks on time.  It gave the business folks throughout the company insight into what we'd been up to for two weeks.  And it gave me great satisfaction watching both sides learn more about each other.
• Developer involvement in implementation decisions.  Previously, our tasks would be presented to us as implementation directives: "Add a link to the order page to show the user more purchase information."  Now we're moving to a more agile approach, where we talk about user needs and stories, and let the developers have a say in the final implementation.  In talking to people on our team about productivity, micro-management has been mentioned by a few of them as a productivity killer.  The opposite, autonomy and control, are offered as productivity boosters.  I think giving them more say in projects will motivate them to accomplish more with their time.

We're also trying out a few techniques that aren't necessarily prescribed by Scrum, but which are nonetheless already proving helpful:

• Break everything into half-day to one-and-a-half day tasks.  This has a few advantages.  First, it forces us to plan out those nebulous blobs of work up front, so the group as a whole can brainstorm about the most efficient approach.  Second, it acknowledges that the bigger a task is, the harder it is to accurately estimate the time it will take to complete it.  With more small tasks, we get more accurate estimates.  Finally, it provides a greater sense of accomplishment.  It's purely a psychological trick, but accomplishing five small things is a lot more gratifying than one big thing.
• In sprints, first decide on a group of goals, not a group of tasks.  Previously, our sprints were a hodgepodge of 20 different, unrelated tasks.  It's hard to prioritize 20 separate projects in any objective way.  It's a lot easier to prioritize goals.   And then you can come up with a list of tasks to accomplish those goals, and schedule those for the sprint.  And when you reach the end of the sprint, you don't ask yourself, "Have I completed all my tasks?"; you ask yourself, "Have I reached all my goals?"  In many cases, the two answers are different.  You may have finished only 80% of your tasks, but accomplished enough of your goals that you're ready to move on.  So you're left with a system that naturally filters out low-value, time-consuming work, and consequently boosts business productivity.
• Have success metrics for every project.   As a company grows, the number of new ideas and potential projects grows with it.  Anybody can come up with 100 new ideas for a company.  But asking the simple question, "How do we know if it worked?" is a powerful way to tame the circus of possibilities.  It focuses people, and forces them to consider how their abstract idea can be tied back to something tangible.  It also gives developers insight into the real-world value of what they're doing, and so provides a sense of accomplishment and motivation.

I'm excited to continue using these new approaches, and refine them further as we go.