Skip navigation

Hosting a Successful Open Space

The first weekend of January 2012, 30 Agile enthusiasts gathered at Agile Coach Camp Norway (ACCN). The participants had different background and experiences from Agile projects and arrived from many different countries; Even Japan was represented!

There was a reason it was called camp instead of conference. Unlike other Agile conferences I have been to, like XP and Smidig, almost the entire agenda for ACCN was reserved for the participants to fill themselves. This was done by so called open spaces. Open space is a fairly easy concept – once you have tried it. But if you are not familiar with it, it can seam a bit intimidating at first, especially if you’re used to going to conferences where you sit still listening to others the entire time.

Basically, a group of people with a common interest organize themselves into smaller groups to discus whatever topic they are interested in (there can also be games, presentations or whatever the group decides).

The open space sessions at ACCN 2012.

Dedicating most of the weekend to open spaces was hugely successful, being both fun and an efficient way of sharing knowledge, learning, stimulate creativity and coming up with new ideas together.

Based on our experience with open sessions at ACCN 2012, I would like to propose some suggestions for others who are considering or planning to organize an open space session – and it does not have to be Agile or technical:

  1. Start with giving a brief introduction of what open space is. Remind the participants of The law of two feet: if you feel that you are not contributing or interested, walk to another session (unless you are the one hosting the session, of course).
  2. Before the gathering, inform the participants there will be an open space session and ask them to think of a topic in advance that they would like to discuss.
  3. Provide enough rooms. We found that there would have been nice to have a couple of extra rooms for those times an open space was not naturally finished on time. That way, instead of breaking up an ongoing discussion, the next group could have use another room. (However, then there probably should be a way of signaling that the new open space has moved to another location.)
  4. If the participant are unfamiliar with the locations, give a brief tour of the rooms to show people where the different sessions will be held. We did not do this, but with more rooms that would have been useful.
  5. Provide enough facilities, like flip-boards for each team, tape to hang the notes and drawings on the wall for all to see, enough post-its and markers, preferably in different colors.
  6. Take pictures of the posters and publish them after the session. This will be useful as notes for both the participants and for sharing the outcome with those who didn’t get to attend.
  7. Finally, run a retrospective to get feedback on what was working and what could have been done differently, and share those experiences on the web with the rest of the world.

As a side note, I would also like to recommend the organizers to take advantage of Twitter. Come up with a hashtag and present it for the participants in plenum as to agree on using one single version. This way, the participants may tweet during the sessions and reach out to other interests outside the conference.

How many open space sessions you want, how long you want them to last and how many you want to run in parallel might depend on the size of the group, the topic, the rest of the program and other factors. However, open spaces tend to scale pretty good, and can even be organized with hundreds of participants. We discovered that three sessions in parallel worked pretty good, but if you have more than 30 participants, you might want more sessions as each group should not be too large. Roughly one hour each sessions might seem like a relatively long time, but worked well in this context.

Do you have any experiences, recommendations, views or comments on how to host a successful open space session?

The Lost Individuals of Scrum

One of the four principles of The Agile Manifesto is individuals and interactions before processes and tools. A decade ago, this was a refreshing statement to a command and control culture, and a welcoming change towards a more people-oriented model. Today, no one wants to admit they are doing anything but Scrum, Lean, XP, Kanban or whatever Agile methodology which puts the individual first.

Since ‘processes’ has such a bad reputation in the Agile community, practitioners insist on referring to Scrum as a framework. Unlike certain other Agile methodologies, like XP, Scrum does not tell us how we should implement code. Instead, Scrum provides three roles – team member, Scrum Master and Product Owner – with clearly defined responsibilities. A predefined set of meetings is also mandatory (as ‘meetings’ has an even worse ring to it than ‘processes’, we like to call them ‘ceremonies’ or ‘conversations’) with predefined agendas. In addition, the Scrum package often contains pair programming, TDD, continuous integration, refactoring and other XP related activities. However, some of these practices, no matter how good their intentions, does not always benefit the team members. You might have come across the introvert developer who always tries to avoid pair programming, who needs to be dragged to daily standup meetings where they stare at the floor, quietly murmuring something about what they’re up to. Or the one who is particularly good at one specific part of the system and thinks every other task is a waste of their time. Or you might have heard the history about the developer who left the organization because he couldn’t stand pair programming. Why won’t these developers behave according to Scrum?

Scrum promotes a way of organizing teams, where each Scrum team should concentrate on a specific functionality rather than a component. Instead of having one team of architects, one team of usability guys etc, we try to compose the teams with a mix of skills. Rotating tasks among team members is also recommended. A natural consequence of this is that each team member has to perform a broad variety of tasks. These cross-functional teams therefore work best when everyone knows a bit about everything. Scrum promotes the generalist and degrades the specialist – unless they are specialized in several fields. The advantage of teams consisting of generalists is there is always someone who can step in and pick up any kind of task where the last one left off, and the team is not dependent on single individuals. (Naturally, someone will be better than others in certain fields, but that’s not a problem as long as that person helps out the other team members, and everyone do whatever they have to in order to complete their commitments before the end of each Sprint. After all, software development is a team effort and we are all in the boat together.)

Agile practices also emphasize collaboration and face-to-face communication, which is supported by open office environments, pair programming and daily meetings. And in order to collaborate, managers sometimes even figure we need team building activities! – to get to know each other better. Social activities are made mandatory. Needless to say, this way of working requires a certain degree of social skills, as well as a willingness to socialize with others, which can be hard for some of us to swallow. Especially when we are forced to.

Ironically, strictly defined processes and rituals have in many ways become a means of achieving better communication and to help us collaborate and communicate better. In fact, Scrum might have become more rigid than some of its practitioners like to admit. Although that was never the intention of The Agile Manifesto, the industry has in large scale tried to implement Scrum by the book and, to say it harshly, ‘forced’ many of its practices down the throat of the team members, as well as not giving room to the specialist. The specialist don’t get to fully use their potential, and we as a an industry suffer from a waste of knowledge. The reluctant developer suffers, which can lead to stress and lower performance and further affect the whole team negatively.

Where traditional development used to involve a dedicated project leader with coaching responsibility, the Scrum Master is specifically urged not to do any coaching. This does not mean that Scrum Masters shouldn’t care about people; it means that the team should be more responsible for itself. These self-organizing teams give the team more freedom and responsibility. But like leaving a bunch of kids on their own (and it’s not that I’m making a point out of developers being childish – but grownups can sometimes be selfish and inconsiderate), there is always the risk that this one kid is going to be left outside the game.

There are some common characteristics of those most likely to be left outside of the game (and in the literature blamed for making Scrum teams dysfunctional):

  • Those who insist on performing only one kind of tasks
  • Those who work on tasks outside the scope of the iteration
  • Those who are reluctant to attend meetings or perform other Agile related activities

Obviously the solution is not to put the ‘dysfunctional’ team member in a cave and let them work on whatever they please and deprive them of their right to speak to any of the other stakeholders. We still want clear communication between all interests, and that requires some sort of interaction. What I would like to suggest is that the Scrum Master should reclaim some of the coaching role of the traditional project leader, as they are most likely to spot the ‘dysfunctional’ team member. After all, it is the Scrum Master’s responsibility to make sure the team is fully functional, which it will not be with ‘dysfunctional’ team members.

There are some adjustments that can be made in order to become more pragmatic and take better care of the ‘human resources’ – as managers often like to refer to their employees (and which might explain why the team members sometimes are treated as, well, resources):

  • First off all, do not enforce pair programming. No one, especially not stubborn computer geeks like to be told what to do, and not everyone perform well sharing their keyboard with others. Even though it’s encouraged and valued by many practitioners, let pair programming be optional and respect those who do not wish to take part in it.
  • Introduce symbols to signalize when someone do not wish to be disturbed. One way of doing this is to put on headsets.
  • If it’s not urgent, which it seldom is, don’t interrupt a developer (or anyone else for that matter) who is clearly trying to concentrate. Valuing interaction before tools and sitting together in an open office landscape is not an open invitation to poke your colleagues on the shoulder instead of sending them an e-mail or using instant messages.
  • Do not require the whole world to attend Scrum meetings. Yes, the team should gather and discuss progress every now and then, but it’s not crucial for all stakeholders to always attend all meetings.
  • Focus on tasks instead of individuals. Let daily standup be about Sprint progress, not on what each person is up to. Having each person answer three questions about what they are doing can sometimes feel like a productivity contest, and can easily turn into a status meeting for the Scrum Master to report to the management.
  • Provide an office environment that reduces noise, e.g. rooms dedicated phone calls and discussions. In the case of multiple teams, give each team their own room.

It’s not about some developers being too specialized to work in a Scrum team or computer geeks being too socially incompetent to interact with others. It’s about team members becoming ‘resources’, where personality and personal preferences are not taken into account. Sure, their competences are taken into account in order to make functional oriented teams, but their personality, needs and working preferences are seldom mentioned. And the literature does not say much about adjusting Scrum to the people involved in making the software. The human aspect of software development teams is therefore easily overlooked.

A decade after of trying to implement Scrum into our organizations, the first principle from the Agile Manifesto still needs to be repeated: Individuals and interactions before processes and tools. And remember: developers are individuals too.

Thanks to Thomas Kjeldahl Nilsson for proofreading.