In knowledge work it's usual for ideas to need to be shared. In software development a common direction of travel for concepts is from one set of people with a vision for a feature to another set of people who will bring it to life. Sounds simple, right?
But it isn't simple and many ways exist to try to address that lack of simplicity, including thick wodges of functional specification and layers of sign-offs through to terse sticky notes, a chat, and iteration. Whatever the approach there's one constant: a commitment of time from the idea holders.
An anti-pattern common in our industry is that these individuals often also have emerging and urgent tasks which trump the merely important ones ... such as the sharing of ideas. Despite our best intentions we've seen it at our place too, and it impacts the quality of the thing that we can build in the time available to us.
Naturally, this kind of problem can be tackled at all sorts of levels. At one level, I was interested to find something with the potential for immediate effect, at low cost, and that I had sufficient clout to influence without requiring systemic change or permissions.
This is how my thinking went: first, while the people with the notion of what to build won't know everything up front, they usually have a good idea of their core wants and pieces of scope they'd be prepared to trade.
Second, while they may be time-poor, they can be persuaded to spare time for a short meeting with the promise of an outcome which doesn't require preparation by them.
Third, while lack of time might be problematic, deliberately constrained time can be a helpful forcing function.
So I asked if we could try experimental meetings on nominated candidate projects where scope was unclear, with these inspirations:
- Three Amigos: a small-group conversation with folks bringing varied perspectives
- Example Mapping: a goal of generating constraints, examples, and questions
- Essentials: a focus on core ideas, not specific implementations
The format we've arrived at is a 30-minute facilitated meeting. The time box is an enticement to attend and a motivation for staying on topic. Conversation and facilitation reduces up-front cost to attendees. The facilitator keeps things at a scope level, encourages participation, and records the findings on a whiteboard which is set up this way:
- at the top of the board, write an agreed one-line description of the project
- on the left, enumerate constraints; things that are in or out of scope
- in the centre, generate use cases for constraints
- on the right, record questions or requests for data
At the end of the meeting, the board (and the non-shallow shared understandings) serve as a starting point for a wider kick-off and an initial envelope for the project scope. It's not perfect and it sometimes fails spectacularly — usually when it becomes apparent that we don't have consensus on what the project is about. The fact that we've continued to do them is evidence that the relatively small investment is perceived to return sufficient value to justify it.
Some reflection: Although I started this experiment around 18 months ago I'm writing these notes in the context of the DEWT 9 peer conference on Testability that I attended a a couple of weeks ago.
At DEWT we talked about how arguing for change in terms of business value is more likely to succeed than talking about testability itself.
When I presented my DEWT notes to my team at Linguamatics it was suggested that many testability factors are also developability factors and I think that holds true here. The gains that we've got from this experiment are across the team. And that's an idea worth sharing!
https://flic.kr/p/HTSP
Comments
Post a Comment