My software friends are talking about Scrum, Agile, Pair Programming and I knew nothing about it. I have a friend who even suggested that Agile could be extended to general organizational design and even leadership!

I read Henrik Kniberg's book, Scrum and XP (Extreme Programming) from the Trenches, on his suggestion and, well, he's right!

Kniberg's book is a concise "how to" on how his company implements Agile in their software development business. It's chock full of great ideas and details that come only from those that have actually practiced something. As such, I gained a good insight into how Agile and Scrum work, and you will too.

What I want to explore more, however, is the idea that Agile can be applied as a model for leadership, or, more precisely, how can the practices of Agile be applied more broadly to knowledge workers? I think the best way to think about it to briefly recap the points of Agile and at every point where you see the word "product" think "culture." Let's see how that works.

1. The Agile process starts with describing stories about how the product should work. The focus is not on how things aren't working but how they should work. Process step 1: collect stories.

2. In preparation for the sprint planning meeting, have the product backlog (the list of stories about how we want our culture/product to be) in shipshape. This means being clear about the outcome including an defined "when done." This invokes the element of clarity and measurability. When we do workshops on changing culture this reminds me of the step where I ask, "...and how would we know...."

3. Have the sprint planning meeting with the team. Allow the team to determine the scope of what projects will be included in the upcoming sprint. Principle: give control, don't take control. Corollary: move authority to information, not information to authority.

4. Determine overall sprint goal prior to closing the planning meeting. This ensures the necessary supporting condition of clarity is in place.

5. Launch the team and get managers, coacher, owners, out of the way. Again, giving control to the people who know (the coders, testers, developers).

6. Always test the product with a demo before saying "done." This emphasis on actual products is very helpful, especially when changing business cultures where sometimes there is a tendency to think in terms of vague changes in mindset. Instead, we should focus on specific behavioral changes that we can observe and measure.

7. Conduct an assessment of how the Sprint went and measure team velocity. This would apply to following up on whether behavioral changes are sticking or not?

OK, well, that seems clear enough but when it came down to it, what was the leadership team actually working on -- the parallel to the code the developers were writing? Well, I think the code (sometimes I call it the DNA) for the company's culture is written in the policy documents that give authority for making decisions and detail how we will interact with each other. The cultural "coders" work on these policy documents in the same way the software developers work on the code. ( )