How does this approach differ or complement design processes you’ve used before.
“Shared documents aren’t shared understanding.” — This is something that I have come to understand over many years of teaching. It is one of the great takeaways I have had from the experience. I went into tutoring in high school. Until that point, the only thing I had really ever done was to learn on my own. My parents and teachers were there to help but most of the time I did the greatest portion of my learning by reading textbooks and working through examples. I mastered the learning style that worked best for me and got good grades as a result. Teaching another student however opened my eyes to fundamental differences in how people think. Something that made complete sense to me might make no sense to someone else. From that, I learnt a few things. First of all, you need to understand how others think to be able to communicate effectively to them. But even then, you should always confirm that they actually understand what you explained to them by having them explain it back to you in whatever mode they feel comfortable doing so. Only then can you make sure everyone is on the same page. I think the same thing applies when working as a team. You can talk all you want but you must confirm in other more bullet proof ways if everyone really does agree.
“The real goal of using stories is shared understanding.” — I am especially conscious of that the fact that perfect documents do not exist. Instead, the value comes from the process of writing them as a team and making sure the understanding is there. Rarely do people go back and understand them word for word. The discussion that occurred while they were being drafted is usually what lingers in people’s mind afterwards and what brings the greatest value. The best thing you can do after any long design meeting is to recap it as a team. At that point, all the useless details will fall away. Instead you will be left with an incredibly concise summary of what truly matters. Everyone can refer to this document afterwards to remember. It can also be shared out to give people a gist of what happens. It can be a supporting document even though further explanations will be required.
“Good story conversations are about who and why, not just what.” — This is one of the hardest things to remember as someone with a software background. What matters is the problem we are trying to solve and the users who will be affected. Everything else if a function of that. It is too easy to get bogged down in technical details and let those guide your approach. In the end though, that does not matter if you are off base. We must also resist the desire to build for the sake of building and instead focus on building for maximum impact.
