(update 12/7–I received an email that I’m describing in great detail something called bikeshedding. Fantastic read!)
I’ve noticed over the years projects that appear simple sometimes end up taking a long time. Why?
For most of my career I’ve worked with very talented people. Many have coded industry firsts and many hold patents. Obviously, skill wasn’t an issue for any of them. I’ve also sat in code reviews where some of the people attending clearly didn’t understand the code being explained to them and despite the authors best efforts, I’m not sure they’ve ever caught on. I’ve been one of those people that didn’t understand things on occasion; I learned long ago if you want to learn anything you have to accept you’re going to look very stupid to someone every once in awhile*. On some level though, everyone knew what was going on and knew when to keep their mouth shut (or ask non-stupid questions) when appropriate without unnecessarily bogging things down.
What I started to notice was the more people who knew a great deal about the subject matter were involved in a project, there was a marginal increase in how long that project took. Everyone wanted to leave their mark on the project. In the case of the highly technical projects, things moved faster because the people involved didn’t have the knowledge necessary to provide “deep” input into how we should engineer it. I’ve never heard my observations used as a reason for keeping scrum team sizes to a minimum, but it really works out well. Five to ten people with exceptions at both ends of the scale to keep communication clear and keep everyone focused on the same problem. That focus isn’t easy to keep with alot of people in the room.
I’ve also noticed smaller Sprint Reviews also tend to be more effective with small groups of customers. The tendency is to want to load up as many attendees as possible to get as broad a range of opinions as you can, but you risk missing the point of the Sprint Review–feedback. You don’t want a room full of people telling you blindly “Good job!”, but rather a small group actually using your product and providing in-depth information as to how it could work better or what they would like to see next. If your customers are tripping over each other to talk to you or aren’t even allowed to use the working software you might as well just provide screen shots and skip the review altogether.
Bigger isn’t better in Agile.
*If anyone in engineering says with a straight face “I know what I’m doing”, redouble your QA efforts on any code they touch.