Last month at the Paris Scrum Gathering, a colleague and I ran a workshop on designing an Agile organization using Lego. We have done this type of design modeling for several years now. We’ve learned a great deal about organizational dynamics by both going through this process ourselves, and facilitating organizational design with teams.
We licensed the method under Creative Commons and have made it available to everyone. We call it Whole-Team Dynamic Organizational Modeling. When teams engage in designing their own organizations, they are much more likely to accept the trade-offs they have to make in order to deliver their products and services to the market. No organization is perfect. Each model creates its own set of silos. Each model is tuned to be effective within a particular organizational culture. All solutions have a messiness that is unavoidable. The usual reason for re-designing an organization is improved throughput and higher value delivery to customers. Sometimes, the organizational design is crafted to achieve a specific outcome related to culture or product architecture. Goals vary, but the act of building and testing an organizational model reveals consistent insights.
You can find more information at wtdom.org, including a facilitation guide to help you plan and deliver your own modeling experience.
Yesterday, Catherine Louis and I delivered our three-hour workshop on “Whole-Team Dynamic Organizational Modeling” at the opening of the conference. It was well-attended–standing room only. Our colleague, Neil Johnson wrote about in his AgileSOC blog here. InfoQ wrote an article about it here. Thanks to Shane Hastie of InfoQ for attending and sharing our work with everyone.
For Agile veterans, this list of failure reasons is not new. But it never hurts to be reminded of what they are. So here is the list by Clinton Keith and Mike Cohn. I wish everyone would read this list and post it on their bathroom mirrors. You can find the source document here.
Don’t trust the team or agile. Micromanage both your team members and the process.
If agile isn’t a silver bullet, blame agile.
Equate self-managing with self-leading and provide no direction to the team whatsoever. (Good leadership always matters!)
Ignore the agile practices. They don’t apply to management. (As a manager and leader, this is my favorite.)
Undermine the team’s belief in agile.
Continually fail to deliver what you committed to deliver during iteration planning.
Cavalierly move work forward from one iteration to the next. It’s good to keep the product owner guessing about what will be delivered.
Do not create cross-functional teams. Put all the testers on one team, all the programmers on another, and so on.
Large projects need large teams. Ignore studies that show productivity decreases with large teams due to increased communication overhead. Since everyone needs to know everything, invite all fifty people to the daily stand-up.
Don’t communicate a vision for the product to the team or to the other stakeholders.
Don’t pay attention to the progress of each iteration and objectively evaluate the value of that progress.
Replace a plan document with a plan “in your head” that only you know.
Have one person share the roles of ScrumMaster (agile coach) and product owner. In fact, have this person also be an individual contributor on the team.
Start customizing an agile process before you’ve done it by the book. (Another favorite of mine.)
Drop and customize important agile practices before fully understanding them.
Slavishly follow agile practices without understanding their underlying principles. (I call this one Agile-By-Rote).
Don’t continually improve.
Don’t change the technical practices.
Rather than align pay, incentives, job titles, promotions, and recognition with agile, create incentives for individuals to undermine teamwork and shared responsibility.
Convince yourself that you’ll be able to do all requested work, so the order of your work doesn’t matter.