Planning the next release
A while ago I was responsible for the implementation of the “B” system. The current release was coming to an end. The Customer (in the XP sense) and I had collected a set of stories for the next release. Every two weeks, we had a meeting with user representatives to discuss the current and future system. We would discuss the plan for the upcoming release at the next meeting.
Shortly before, I had followed a tutorial by Suzanne Robertson on applying creative techniques to requirements discovery. Whenever I learn something new, I try to apply it with my guinea pigs customers. So, before presenting the release plan, I tried to get some more “creative” requirements from the users.
Make a wish
I asked the users to “make a wish” about the system. It could be anything, it could be crazy, it could be impossible to implement, it could be very costly. I didn’t care. I wanted them to tell me what they really wanted.
I was met with puzzled stares.
Finally, one woman spoke up.
I wish…
“Well, I wish the behaviour of <this bit of the software> was not so annoying! I do this the whole day, when customers call. I want all the information available immediately, I don’t want to click through!“, she said.
“That doesn’t count as a wish, because we’ve already corrected this in the current release. Make another wish.“, we replied.
“Thanks. Well… then I wish the system would <do this> for me.“, she added.
“That doesn’t count either, this story is already in the plan for the next release. You still have a wish left.”
“Okay… then… I wish… the system would <solve this> for me“, she exclaimed.
She thought we wouldn’t have thought of this. She was wrong. That story was also in the next release.
She thought a bit more and looked at us with a slightly worried look: “Have you been reading my mind, or what?”
Mindreading 101
If you have a good Customer or Product Owner, the users feel as if the development team can read their mind. It’s like magic. Like most magic, there is a trick.
How did we know she was annoyed with that functionality? Simple: she had told us at the previous meeting. We had a look at how this functionality slowed her down and saw that we could improve her efficiency very easily. So, we decided to add this change to the current release. We had some time left, because we were going a bit faster than planned.
How did we know the users needed those other functionalities? Simple: we regularly went to the “Gemba“, to see how users performed their work, to talk to them, to really listen, to really understand, to really help. Genchi Genbutsu.
If you know of any out-of-work mind readers, contact me. I know several teams that are looking for a good Customer or Product Owner.
Meanwhile, they can already start to really look, really listen, really understand.
And I need to get better at stimulating users’ creativity. This was a really crap effort: we didn’t learn anything new. That’s the subject of a future entry.
