We’ve been to affinity
This week we went ahead and constructed our Affinity Diagram. Julian led us though the process and made a very good job of doing so. Thank you Julian, here’s pictures of us in action.
It was particularly interesting to do the exercise in silence. I thought we worked together brilliantly in cooperative synchronisation. We were like ballet dancers, gracefully and elegantly moving around one another sorting and structuring our system requirements into functional groupings.
A form of structured brainstorming
This method was essentially a structured brainstorming session. Structured in that we started with a fairly tightly defined question:
“As an allotment holder, what do I require of the allotment system?”
We would have needed to have a less tightly bound question if we have a great variety of stakeholders present, for example the Council, who are landlords and also have statutory requirements on them to provide allotment facilities. The Allotment will have a quite different purpose from their perspective than it will from an allotment holder’s.
Also structured in that once we had brainstormed our requirements, we sorted the requirements into categories. This was an interesting process and there were some silent disagreements in the room over what level requirements should be categorised to. Here is a representation of what we built, just click on it to expand.
Where’s our boundary?
One interesting reflection for me is that even though we spent a previous session trying to work out where on our Context Diagram we should redraw our System of Interest boundary, when we came to the Affinity Diagram exercise, we almost had to forget about where we had drawn that boundary and to brainstorm requirements as widely as we could. Next week, when we structure requirements into the Tree Diagram we can revisit the Boundary question and decide what to include in the new diagram and where to draw our Boundary. It’s an iterative process.
If we had been viewing yesterday’s requirements generating session from the perspective of a wider range of stakeholders, then part of the power and value of having created the Context Diagram and thought about where to draw our boundary is to help us understand which stakeholders to invite to a session to create an Affinity Diagram. The Context Diagram does do more than that, it leads us to define flows between stakeholders and objects as well, but the identification of stakeholders is one useful feature.
It’s interesting that we’re beginning to see how these tools work together and compliment and help one another.
Happy faces – A job well done.
We’ll draw a tree
Next week we will take our categorised requirements and construct a tree diagram from them. This will give us a structured understanding to the system’s purpose. Once that is done, we could then look at the real life allotment and determine to what extent it fulfils our required purpose, or use it to identify alternative ways to fulfil the functional requirements.
I think we will probably refine and redraft out grouping headings as we work our way through this and probably have some debate about what the hierarchy or relationships between purpose, sub-purpose and requirements should be. That’s good and is partly the point of the exercise. It will push us to think hard and to take various views into consideration.
The Tree Diagram paper is here for you to read in advance of the session.
Julian is kindly going to type up our outputs from yesterday and we’ll use those as the basis to begin constructing our Tree Diagram from.
Enjoy your weekend. I’m off to London to attend the a Systems and Cybernetics in Organisations (SCiO) Development Day on Sunday and then Open Day on Monday. Really looking forward to interesting presentations and, conversations. I’ll update you on the highlights and/or any particular insights.