Agile Engineering

Agile practices can work in just about any organizational structure. The more you do agile, the more you'll identify areas in which you could optimize your organization to be more effective.

Let's first talk about functional organizations vs. cross functional organizations. In a functional organization, you have one group do product management, another do development, another for QA, etc. This made sense in waterfall because you handed off from one functional area to another.

At Agile 2008, Michael Mah of QSM Associates gave a presentation demonstrating the productivity gains that are possible with an agile approach. In the presentation, he focused on the successes we had at BMC and showed some numbers to illustrate. The video goes around an hour and a half. Starting at around 54 minutes in is an interview with me that goes to the end of the video.

Click here to see it.

In the last blog entry, I talked about the effect of moving to agile on individual contributors. In this entry, I'll talk about the effect on management.

Development Managers

The transition to agile is a disruptive one. It affects many core processes. It also affects the roles that people play. Both of these can be a barrier to its adoption. Bigger companies in particular have a natural resistance to process change. As to role changes, if a change was going to affect your day to day role, wouldn't you be nervous?

Agile tells us we should release frequently. Each release generates feedback which we can use to help guide us in what to do next.

In previous posts, I've talked about the importance of staying releasable. Staying releasable gives us options (i.e., allows us to be agile). The closer we stay to releasable, the shorter the list of things that we have to do to release. The shorter that list, the more time we have to do other things. And the more frequently we can release.

I just read through Google's introduction to Chrome (their new light-weight browser). The intro is done as a cartoon. One thing that's really interesting (the browser sounds pretty cool too) is how many references there are to agile development within it. You can find the complete intro at http://www.google.com/googlebooks/chrome/.

On page 9, they talk about their automated testing and the benefits of doing things incrementally...

When I'm running on the trails down at Town Lake or I'm in the gym working out, it is natural to take a look at those around me and see what they're doing. Are they running as fast? Are they doing as much weight?

• There is wisdom in crowds. The conference was kicked off by James Surowiecki (author of The Wisdom of Crowds). Crowds are very good at coming up with answers (assuming they meet some prerequisites such as having some understanding of the problem). There were many examples where the average answer of the crowd was better than the best guess of any individual. Diversity can really help in working through issues as it introduces new ways of thinking about problems / solutions.

Planigle derives from Planning Agile. While I was at the agile conference 2008 last week, I was asked whether that was an oxymoron. In other words, if you're planning, you're not being agile, right? Wrong.

How many backlogs should you have? As few as possible.

On one project I worked on, we had a backlog per team. This is an easy trap to fall into. It gives the team the ability to focus on their own part of the world with minimum interaction with the outside world. It gives the product owner of that team independent control over what they are doing.