BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Agile 2012 Session: Dynamic Organizational Modeling

Agile 2012 Session: Dynamic Organizational Modeling

This item in japanese

Catherine Louis and Raj Mudhar presented an interactive workshop titled LEtGO your Organization - design a best-fit large Agile Organization.  Using their Dynamic Organizational Modeling approach using LEGO blocks to let participants model and visualize organizational change.  This half day session was attended by over 100 people.

The purpose of the session is to let participants model and visualize organizational change using LEGO bricks or other tools such as pipe cleaners and balloons.  The tactyle nature of the tool helps teams make visible the changes they need to make, and design how to achieve them.

The session started with Catherine & Raj setting the scene, explaining the toolset and purpose and letting the participants group into teams of 8-10 people. The briefing covered the purpose (identify the current dynamics of a large, distributed organization using agile practices with some identified challenges, build a model showing how the teams are structured and look at how it can be improved).

The first round involved all teams using the same company (using a briefing note provided by the presenters), building their models for 25 minutes, then they held a "tradeshow" in which one member of the team remained with their table and the others circulated to see what other teams had done, gather ideas and ask questions. The teams had to consider when building their model: 

  • the goal
  • the current state
  • skills needed
  • scarce skills
  • distribution
  • constraints
  • scope

 Key questions the presenters asked the teams to consider when building their models included:

  • How can you move decision making as close to the source as possible?
  • Do you work with 3rd party suppliers? Is any organization truly healthy and happy?
  • How can we improve communication?
  • Where should decisions be made?
  • Are there any legal constraints/compliance rules to take into account

 As the teams worked additional pointers were raised, including

  • should testers be in the team
  • what information bottlenecks should you consider
  • what timezones need to be included
  • what are the escalation paths for the remaining blockages

After the first tradeshow the presenters asked the teams to examine what they had done, taking into account the use of the different LEGO parts - the use of color (how many teams used red bricks to represent testing), weapons (a number of Product Owner roles were represented by weapons), bridges to connect teams, spaces between teams . . .

 Having taken the teams through one cycle on a case study organization the remainder of the session was spent examining organizations selected by the participants - some teams chose their own organization, others picked from a set of case studies that the presenters provided.

 After the session Catherine & Raj answered some questions for InfoQ:

Why LEGO?
When in toy store looked at lots of options, and LEGO was best bang for buck - lots of shapes, lots of options. Important to make it physical. Also use pipe-cleaner. Everybody understands LEGO, there no need to teach syntax and the simple nature of the tool allows us to focus on the message rather than the product.  We also use things like pipe cleaners and other simple tools if they will help teams envisage their environment and the flow of work.

What surprises you with the outcomes?
Observing the use of color and different types of LEGO bricks. For example many groups use green bricks for developers and red for testers, the subtle message about Go/Stop can be very enlightening when they explore their models. The use of height to show/make important roles or individuals stand out. Sometimes the lack visibility of the scope of their work - for example just modeling the development team, without awareness of customers and source of work.

How does this work when done internally in organizations?
When doing this internally the model remains intact - it stays behind. The simple tool exposes the reality of complexity - one model took 4 hours to build and people stood on table to view it and there were a number of "aha" moments as they realised just how complex their environment actually is.
By visualising the change, it is possible to convince people that change is possible.

What was different with the public nature of this session?
Surprised that only 2 teams wanted to model their own organization, hard to be brave. We did bring scenarios, but they are not as effective. Use of words - "designer" in Two scenarios, one is technical one is graphical.

What are some important pointers for groups using this approach?
- make sure you use a 2 dimensional model, look at both structure AND flow
- pay attention to body language and team interactions
- ask if the teams have tested the model by flowing work through it
- ask where the customer is, and how information flows into the groups represented in the model


 A number of attendees indicated that the session was enlightening and enabled them to visualise what changes they needed to make to help their organizations adapt to new ways of working.

 

Rate this Article

Adoption
Style

BT