Here’s the paradox: How do you reconcile “Individuals and interactions over processes and tools” with the ceremony and seeming process-heaviness of Agile frameworks?

I think you can resolve this constructively by digging beneath the values, bringing  an assumption or two to the surface. In my ‘6+1 strategies’ paper (more on this at the end) I make this statement:

Agile assumes that software development is best … delivered through … processes that respect, support, and amplify the effective, deliberate, and timely interactions of skilled people

Even after editing some out, there are multiple assumptions at work here (“skilled”, for example), but it will serve our current purpose. It’s a statement that supports much (if not all) the Agile Process Heaviness Spectrum™, from the big frameworks near one end and most of the way towards “get a bunch of smart people together in one room” at the other.

Success is heavily dependent on the right conversations happening at the right time. If they’re not happening, some more process might help. More process might not generate exactly the right conversations, but there will at least be some more regular ones!

So the thinking goes anyway, but there’s a balance to be struck. Here are five ways you can try to improve that balance:

1. Do you have a recurring frustration that might be addressed through the implementation of some extra ceremony? Find one that fits, and introduce it as an experiment.
2. Before experimenting with any new ceremony, make sure you understand the assumptions beneath it. Does it address a problem that you actually experience? Will the benefits outweigh the cost?
3. Do each of your existing ceremonies “respect, support, and amplify the effective, deliberate, and timely interactions of skilled people”? If not, more experimentation needed!
4. Do you have an existing ceremony that seems particularly painful, either a poor use of people’s time or revealing problems only late in the day? As the XP folks might advise, experiment with doing it sooner and more often. Examples: Plan a non-painful planning meeting with frequent “pre-planning”. Head off painful code reviews with regular design conversations. At the extreme: planning on demand and pair programming, hardly ceremonial at all, and more achievable than you might think!
5. Can you see when conversations are overdue? For example, if it’s not obvious when there is “unready” or “unreviewed” work for example, then make those states more visible, eg with columns on your board.

6+1 Effective strategies for successful Lean-Agile transformation

The second draft of this paper is now out for review. All being well, the final version should be out next week. Register here for your copy.

Blog: Monthly roundups | Classic posts
Links: Home | Partner programme | Resources | Contact | Mike
Community: Slack | LinkedIn group | Twitter