An interesting snippet from a post I read yesterday:

As I read this it really got me thinking. In most of the process agile / lean related books that I’ve read there seem to be a few common themes:

• Trust people to do the right thing for the company
• Give them freedom and authority to work the way they want to
• Push decisions down the chain as far as possible
• Work in small batches and change things that aren’t working
• Allow those who are capable of leading to lead, no matter what their title or position is
• Put quality checks in place - whether it be test-driven development, or quality checks at each step in an assembly
• Fix problems at the core and stop the line as quickly as possible - in development this would be TDD and automated builds. Once a problem is found, find the root cause and put a test or quality check in place to ensure it doesn’t happen again
• and finally, Trust people to do the right thing for the company

This is definitely where we're being led at MindTouch (if we're not already there). We do rapid iterations of releases (once a month for minor updates, and once every 2 or 3 months for major releases).

I've never read a book on Agile development, but maybe I should (or maybe it'd be like my avoidance of Ayn Rand, since I know I'll just agree with what's written, and the last thing I need is an echo chamber).

I'm a firm believer in "push decisions down the chain as far as possible", even though it requires a huge leap of faith when part of your development team is in Russia (especially if your ass is on the line). However, it's worked beautifully - I just give a general guideline of the goals I'd like to achieve, and leave it up to the dev to figure out how to get it done.

One thing I've noticed about Agile, is that although you're pushing the responsibility of decision making down the pipe, it doesn't absolve you from deferring all responsibility to the developers. The role I've found myself filling at MindTouch increasingly is to reduce the cognitive overload developers face in our "Agile" system. For example, because developers are now forced with the responsibility of making more decisions, it is up to me to clear the path to implementation for that developer.

For example, at MindTouch, we switched our SVN versioning to something that would support the more rapid iteration of our product cycles. Previously, there was way too much top-down decision making, which didn't work. (The jury is still out whether the change I championed is successful; we'll see a few releases from now) This change increased the risk of critical bugs on our primary production branch (trunk). To counteract this, bug reports were required for every bug fix that went into trunk (cognitive overload for developers). However, because we're now managing multiple branches on trunk (which is an achievement in itself), the categorization of bugs can get tricky. What may have been a bug fix for the 1.9.1 release may actually be moved to the 1.9.0 release if a service pack is being issued. This is where the Agile manager has to step in - the role is to reduce the pains for keeping the Agile development going, and to reduce the stress that developers may feel as a result of their implementation (bug regressions, etc.).

I dreamed of creating a system and process where everything would automatically work - developers would get bugs, they would fix them, QA would do regression testing, and product releases would get done. I wouldn't do anything - it'd be all automatic! I could then micromanage the UI developments. This most certainly is not the case. Besides the pressures from above (a post I'll save for another day), there's still a lot to do in making sure things get done, behind the scenes.

Developers need to constantly be reminded of the system (herding cats!), decisions on bugs need to be constantly made, and one needs to make sure that problems aren't be introduced. Problems early on in the cycle need to be caught and fixed - which is something I've been struggling to do with the QA team (although improved, our QA process is not where I'd like it to be). Every bug and issue found needs to be examined with this question: "How can we avoid this in the future?"

I find developers living in a bubble, unaware of the greater landscape, helps them focus on the task at hand. Giving vague milestones and the freedom to architect a stairway to heaven, developers will do as such. Once in a while, you have to be an asshole and tell people what they're working on is pointless and pull the plug.

I guess speaking more generally, the role I find myself doing lately:

• Being the equivalent of Adam Smith's "Invisible Hand" by guiding development forward, with as minimal input as possible
• Dealing with the stresses of individual developers (making technical decisions, making product decisions, helping people deal with design limitations from other parts of the stack). A big part of this is to never bubble those stresses upwards - the decision makers above do not need to be burdened with those problems
• Planning the broad strokes of the future by allocating resources accordingly, nipping useless projects & ideas in the bud, and having a rough idea of schedules (so far, I only plan for the next release, which means I only have visibility roughly 2 or 3 months ahead)

The better you are at Agile management, the more invisible your job is. Because technical decision making is delegated down, and you're only guiding those decisions which affect the overall direction of the product (which nobody acknowledges - everybody seems to assume it's the natural path), you won't actually be able to point to something and say "that's me!" Probably the best mark of an Agile manager is somebody who is seen from the engineering side as being a great mentor, and being seen from the product side as not doing much (but somehow products ship on time).