Proactive + Reactive Processes

At present I'm playing the part of a shmagile coach for a medium-sized software company that's rolling out scrum processes across their entire development organization for their next big product release. We've got 38 scrum teams, so it's a non-trivial effort. One of the fundamental challenges is this: once you go away from having an up-front functional spec, how do you enable the various groups to stay abreast of what other groups are doing, without having so much communication that the signal-to-noise ratio goes to zero?

I'm finding that a good way to attack these sorts of problems is to define a proactive process, and a reactive process. The proactive process enables teams to identify obvious dependencies and shared issues up front. It's an 80% approach - you know you're not going to find everything, but you can at least get working without being willfully ignorant.

That's good, but in an agile environment you also need a reactive process - a chance for people to identify issues that were missed during planning, and to identify these issues as soon as possible - preferably as they're happening.

To illustarte this more concretely, before we began the current release cycle, the product management organization had a release roadmapping session in which they roughly mapped out which "epics" (big huge stories) were slotted into one of five "release candidates". The architecture group and some of the development team leads then spent a little time identifying technical dependencies between those epics. Again, the goal wasn't to find every dependency or hidden technical issue, but to proactively pick the low-hanging fruit.

Meanwhile, we have two different weekly "scrum of scrum" meetings attended by a representative from each of the teams. One scrum is for product managers, while the other scrum is for the dev tech leads. These forums exist primarily to enable others to learn about - and react to - changes from other teams as quickly as possible.

How well will does the proactive + reactive approach work in practice? I don't know yet - we just started our very first sprint. Stay tuned...

Meeting Sleepytime Indicator #2

Meeting Sleepytime Indicator #2: When you've been in a meeting for over an hour, and someone asks a question which would actually provoke a meaningful discussion, and the presenter shuts it down by saying "I just want to get through the rest of these slides...", it's time to take a nap.

Meeting Sleepytime Indicator #1

Over the course of the next few... years...(?), I'll be posting various Meeting Sleepytime Indicators (MSIs) as they are identified. When you're attending a meeting and an MSI occurs, it lets you know that it is now perfectly acceptable to stop paying attention and fall asleep, because all valuable conversation has ended. In fact, this may be the best way to engage in the conversation, because if you begin snoring it might prompt the other attendees to change the subject. So let's kick off the list!

Meeting Sleepytime Indicator #1: When two or more attendees begin debating the differences between "processes" and "procedures".