This week I heard a fantastic podcast over at TheBACoach.com about writing high value user stories through structured conversations. In it Ellen Gottesdiener and Mary Gorman, authors of Discover to Deliver, suggested collaboratively working on process diagrams with your customers. In fact, they suggested encouraging stakeholders to break the diagrams!
The idea got me pretty excited about a project I’m currently working on and some workshops I had coming up. Although I’m pretty confident at diagramming as a requirements specification technique and have studied UML, BPMN and database modelling techniques, I rarely use them for elicitation purposes. And I have to say, however confident I am with the practice, I’m always worried that a stakeholder will spot the bit I’ve missed or will mention an edge-case that I didn’t identify. But Ellen and Mary were suggesting a completely different approach – hold your hands up and say it’s not finished, that it needs some polish and it needs input to be completed and allow your stakeholders to roll their sleeves up and participate in the drawing of your process diagrams.
So that’s exactly what I did, I thought back to some of my experiences of prototyping wireframes and some of the lessons learnt are very transferable. Mainly, if the prototype looks polished stakeholders will think it’s finished (and will often be far more critical). So, we used paper and pens to draw out a basic process flow, there were no swimlanes or beautiful straight lines that a tool would give you, but it was there, a vehicle for some structured conversation.
I put it on the table with some other pens and watched as the team looked at it, quite shocked at how bare it was (probably questioning my fee…) but straight away people started drawing on the missing elements. And then they took it further, “this bit is only happens if X is true” and “We want to be able to delay a step, in fact we’d like to be able to delay two of the steps.”
We were prototyping a process flow, well they were and I was taking the notes from all the business logic and constraints that were being discussed. And because I wasn’t holding the pen and doing all the work I was able to sit back and facilitate the discussion and prototyping, dipping into the 7 Product Dimensions [pdf], that I also learnt about on the podcast, ensuring that we had covered where the ‘data’ was coming from for an aspect of the diagram or what the ‘control’ was around another.
Now I was lucky, the team I was working with are pretty technical. In fact they are a mix of subject matter experts and other analysts, which made the job a bit easier. But even if your team aren’t expert diagram drawers, with your help they’ll be able to articulate enough to help you draw something that they can validate. Constantly ask questions like:
- Is this right?
- Is there anything that happens after this step?
- Is there anything missing that you can see?
Working with your stakeholders in this way will help them to feel empowered in the delivery of your project, it helps develop rapport between the team and will pay dividends over the lifetime of the project.