I’m at SD Best Practices this week to learn about the latest in agile development. I start things off with a speaker who I’m sure will be hard for others to follow, Jean Tabaka, who gave a 4 hour workshop on collaboration. And, in what I have a feeling is going to be a common theme of not only this conference, but of agile in general, she pretty much taught us that everything we know is actually completely backwards.

The first thing that I learned is that agile development is about collaboration (okay, maybe I already knew that one), and that to be agile, our leaders must act as facilitators. As facilitator, one has (or at least expresses) no opinions and makes no decisions. Instead, a facilitator’s role is to help others make decisions, which of course goes completely against the grain of technical leaders, who have been explicitly groomed to make decisions (and of course of consultants, who have been explicitly groomed to express their opinions). So, okay that’s going to be a hard one for us.

The next thing I learned is that with agile development and lean methodologies, we need to take the time to slow down decision making. Huh? What? Slow down? There’s no time for that, we have a deadline to meet!

So, of course, in the U.S. we favor a command & control style because it’s faster. If you’re going to take the time to ask all of the employees for their opinions, it takes time, too much time, we don’t have time for that. But, she explained, the problem with command and control is that the decisions don’t stick and sometimes for very good reasons. Sure, people might nod their heads and say they agree while their tech lead’s wrath is looming overhead, but a lot of times the real details are only visible to the ones actually doing the work and so they are aware of subtleties that may be completely non-obvious to the lead. If they’re not given a chance to contribute to the decision, the team could be moving forward, but in the completely wrong decision. So, 3 months later… you could find yourself back at square 1. Sure, you made that initial decision faster, but then how was that actually helpful in the end?

So… stop me if you already know this one. A software development team has a very bright and competent technical lead. When it comes time for planning, the tech lead figures out all of the tasks that need to be done because he knows those. And then he figures out the estimates, because he knows those too. And he makes the call on how those tasks should actually be performed because, well, let’s face it, he knows that as well.

You’ve probably come across 1 or 2 of these teams before – heck, you’ve probably been on 1 or 2 (or a lot more) of these teams before. And, in fact, one of these very teams was on a project that actually had a 2nd development team working in parallel. This second team, as it turns out, was also led by a very bright and competent tech lead used to making all the decisions. But, this 2nd team’s lead also understood the value of collaboration and so he suppressed that grooming to instead focus on facilitation, enabling the team to make the decisions. So, both teams are chugging along and we come to the end of the 5th iteration and this 2nd team has far exceeded their expectations for delivery, while that 1st team is miserably behind schedule and fighting a huge backlog of defects because they have major quality issues.

So, okay… collaboration good, smart hax0rs that "know" everything bad. Just keep repeating it.