Gathering and then understanding requirements is essential in software development. This piece about “understanding” is where most of the problems are. We know how to gather requirements. What we are not so good at is understanding them. However, I have found a cognitive trick that works well, and it based on starting.
I call the technique Rehydration. It’s based on the cognitive phenomenon of inattentional blindness(IB). IB says you can miss what is right under your nose if you do not pay attention. You may have seen the video of the invisible gorilla. That is an IB demonstration.
IB says you do not build perception if you do not pay attention. In experiments, people asked to watch for blue dots on a computer screen focus on them, and do not see any red or yellow dots that appear. They just “miss” them since they are not paying attention to anything but the appearance of blue dots.
Starting turns out to be good for focusing attention and this, for learning. By starting we pay attention, and by paying attention we learn. For example, software developers usually do not pay attention until they start cutting code. THEN they start thinking about the project and that thinking stays in their mind 24 hours a day. At work, the coding is in the front of mind. At home, the coding is in the back of mind. Many developers think about code and dream about it while sleeping. Many bug fixes are solved while dreaming.
What does this have to do with gathering requirements?
In a typical facilitated session, you can generate about one user story per minute with a team. This means in about one hour you can get 60 or so stories done. Same thing with generating user-types, or personas.
What I notice is the duration of the meeting matters. A 1-hour session every day for 5 days is about 10 times better than one, big marathon-like 5-hour meeting. The 1-hour-per-day-for-5-days approach is simply superior to one marathon meeting or even 2 meetings of 2.5 hours each.
What we are basically engaging in here is super-frequent iteration with a group of people around a cognitive, sense-making task.
You get these advantages:
1. More engagement. People will come to a 1-hour meeting and if you make it opt-in you get much higher levels of engagement
2. The folks know the meeting is short and they show up ready to work
3. This one is big: they think about tomorrow’s meeting today, and tonight, and tomorrow morning. The requirements gathering stays in their mind for 24 hours. It stays in the back of everyone’s mind. Some of them even dream about requirements, much like a programmer with a bug to fix dreams about the code.
4. The folks feel refreshed and have a sense of control and progress. I have already described this to you in other blog posts and in my book The Culture Game (you can order it here).
5. By having the meeting every day for 5 days, you get a better cross-section of people participating since most everyone can find a way to set aside one hour at least.
The reason this 1-hour-a-day trick actually works has to to with IB: by spreading the 5-hour meeting across 5 days of 1-hour meetings, the time in-between is spent thinking about it.
People ANTICIPATE the next meeting and the one after that and the results are 10 times better for it.
Everyone stays engaged for a week !
By starting, you pay attention (for 24 hours, not just 1 hour). And by paying attention, you build perception and learning.
This concept of Rehydration (refreshing a neural pathway periodically) can be applied to any project. Simply work for at least 35 minutes a day on the project and the rest of the time you gain perception when it is in the “back of your mind”. For free.
This technique works especially good when you are trying to gain perception as a group around a project.