asking easy questions to find hard problems

07 Nov 2008

I had the pleasure of attending the third annual Much Ado About Agile conference hosted by Agile Vancouver. As a good example of our organizational agility, we divided up the conference sessions amongst ourselves and tag-teamed between attending sessions and working back at the office (or remotely). Ken Schwaber, one of the founding fathers of Scrum, delivered the keynote on Wednesday morning and I’m glad I was there.

To me, Scrum has always been such a good idea that I’ve taken it for granted. Sure, there are lots of guidelines and catch phrases on how to run scrums, but the basic idea of getting the team together every day for a quick status update just seems like a no-brainer. On a co-op job while I was in university, I worked at a mechanical engineering company and spent some time in the machine shop. Every morning, the machinists would get together to go over any safety issues they’d noticed, anything that could have an impact on productivity, and what work was on the table for that day. These quick clearing houses maintained good communication and kept things working efficiently. I remember thinking that it seemed like a good practice, but these guys had been using it for so long that it came easily, so I didn’t think much about it.

It was only later, after getting into post-academic office work, that I learned the awful truth about a lot of professional environments. Instead of a quick 15 minute stand-up meeting over coffee every morning, there’s the shambling behemoth of the weekly (or monthly) meeting where people drone on about their pet issues and rarely get anything done. Developers work more in isolation. Communication suffers. Cohesion suffers. Direction wavers. Productivity drops.

Enter Ken. His keynote was the first “authoritative” Scrum talk I’ve heard and I was a little surprised, but very impressed, by his message that scrum isn’t a silver bullet that will solve all your problems. He compared Scrum to inviting your mother-in-law to live with you. Instead of solving your problems, she brings them to your attention by reminding you about your deficiencies. Scrum won’t solve the hard problems by itself, but it forces you to ask the easy questions (what did you do yesterday, what are you going today, and what road blocks are you facing?) that shine the light on disfunction.

So why adopt some new practice if it’s not going to solve problems? Because identifying problems quickly and reliably is the first step to fixing them. Instead of one developer sitting in isolation banging his head against a problem until a deadline slips, you’re suddenly able to see that everyone’s running into the same problem, and the team can talk about how to fix it. Maybe someone has a good solution, maybe someone has a friend who might have an idea, maybe there’s a tool out there that will help. The point is that individuals and interactions are indeed more valuable than processes and tools.

Ken also talked about how Scrum may not bring value to everyone. He showed a graph plotting requirements against technology. I think he called it a “Stacey Graph” but I haven’t been able to find that on Google. At the base of the requirements axis, you have a customer with very established, straightforward requirements that never change (a hypothetical example only). As you move out, you have changing business requirements, feature creep, scope changes, and other realities. On the technology axis, you start at an old field-test system with no interconnections, then move out to new software with patch cycles, network dependencies, changing standards, garbage data, etc. Projects in the low complexity domain near the origin may be fine with a waterfall model of a big detailed design stage that carefully plans out each step of the development and stabilization (integration) phases. As long as the developers stick to the schedule, everything is great. However, projects out in the high complexity domain are less likely to be able to follow a pre-determined schedule. Markets change, technology evolves, new risks pop up all the time. Scrum and Agile, on the other hand, are an empirical rather than predictive approach. The buzzword is “just in time planning” so you have a series of smaller planning and development stages that self-adjust based on what’s actually happening in the project.

Imagine project that will take about a year and two possible approaches:
1. Spend 3 months on design, 7 months on development, and 2 months on stabilization.
2. Spend a few weeks on design, then engage in a series of 1 month iterations. Add in functionality every iteration and make sure the customer has something working (though incomplete) at the end of iteration.
Ken cited a popular statistic that over 50% of software features are rarely or never used. By splitting the project into iterations and tackling the most important functionality first, you may wind up with a “good enough” product after 8 months that can be released, cutting development costs and increasing cash flow. Or maybe after a couple of iterations it becomes clear that the project will never work and there’s no point in continuing it. Even than, it’s much cheaper to cancel a project after two months than wait until the end of the year-long cycle to get the “fail” feedback. Simply exposing problems is immensely valuable, even if you can’t fix them right away.

Scrum isn’t a silver bullet and it will take time to switch from a traditional model. Ken suggested that it can take about 2 years and requires a change in mindset. Management types become “servant leaders” who remove obstacles and help the development team work, rather than “command and control” leaders. Organizations that don’t adopt Scrum properly will risk imposing an iterative incremental death march if they don’t have the infrastructure and buy-in from all levels to fix problems as they’re exposed.

The overall message I took away was the value in what is, at its core, a pretty simple idea. Some nice side effects naturally fall out of having good communication within the team. Team members get more knowledge transfer, reducing bottlenecks. The customer gets more visibility into the development progress because everyone on the team should be able to talk to the customer about the project status, in the customer’s language. Ken ended with a story about a team of 17 people where he was using Scrum. There’s no way to get 17 people to get value from a 15 minute scrum. However, he couldn’t find a way to break the big team into smaller teams based on components or anything. Instead, the team went behind his back and found their own way to break into 4 teams and ran their own scrums before the main scrum with Ken. At first, he was shocked that they would undermine his Scrum Master authority, but then he remembered that the point of Scrum and Agile is to empower the development team, so it all worked out in the end.

add your comment