Changing the way you develop software changes your organisation. In our practice as eXtreme Programming developers and coaches we have run into questions like: why can't the customer keep up with the development team and what can be done about it? How can we get a team to start unit testing? Is the lack of unit testing really the team’s biggest problem?
This was one of the 'hit' sessions at various XP Days in 2004 / 2005.
|Goal of the session:||Learn a systems thinking technique to understand your team/project/organisation better and to find better interventions|
|Intended audience:||anyone with interesting team / project experiences ;) (see Personas)|
|Experience level:||works for all levels of experience|
|Session Type:||simulation + workshop|
|Topic:||Process and Improvement|
|Max participants:||preferably: max 20; session can scale further but not everyone can participate in the simulation then|
[For the 10 year anniversary edition. This is one of the more successful sessions we ran around 2004-2005, it made a lot of people think. See for session reports http://me.andering.com/?s=systems+thinking+ball+game ]
Changing the way you develop software changes your organisation. In our practice as XP coaches and developers we have run into questions like: why can't the customer keep up with the development team and what can be done about it? How can we get a team to start unit testing? Is the lack of unit testing really the team’s biggest problem? What are the underlying dynamics of adding people to a project and how can these be used to increase project velocity?
We have found that systems thinking is a simple but powerful technique for making sense of these situations. Systems thinking is a way of seeing organisations, projects, and teams as systems consisting of interrelated and interacting agents. Systems thinking focuses on relationships and on the whole, instead of parts in isolation. It helps to see self-reinforcing feedback loops and not-so-obvious cause-effect relations.
You will learn to apply systems thinking, and in particular the Diagram of Effects technique, to different situations in projects, teams, and organisations; you also have an opportunity to share experiences in a structured way.
You can apply this technique e.g. in retrospectives, when you're introducing agile or when you run an 'intervision group' with your peers like we did for a couple of years.