We should talk before we start writing code, and this doesn’t mean just documenting requirements. At Voxxed Days Ticino 2017, Lorenzo Cassulo is giving a talk about … talking. We asked him why we can’t just get our headphones on and start coding.
Who should you talk to before you write code?
To everyone who can influence or is influenced by the product outcome off course!
Software development is a conversation-based activity. Talking to all of your stakeholders allows you to understand their needs and goals better. The goals are what your stakeholders want: they want to get to the other side of the river in the most comfortable way, they don’t want a bridge (even if they ask for it), maybe a boat can be more effective instead. With our development activity, we want to provide business value and return on investment, not just a simple set of features.
The right questions that you can use to engage in conversation allow you to focus on the outcome of your product – and not on the product itself. Promoting discussions creates a collaborative and feedback based environment that keeps software development a healthy and fun activity. It also allows everyone to be involved and passionate about the product.
Maybe you will be not able to directly talk to all of the people that can influence or are influenced by the product outcome. However the simple act of understanding who they are and how to engage a conversation with them will bring you a ton of knowledge about context and scope, more than hundreds pages of requirements will. Ever.
What should you find out?
You don’t know and, like you, no one else knows, that’s the point!
Software development is a process of continuous learning and discovery. Right questions are a powerful tool. When you are at the beginning of development you, and all the people involved in the product, have a lot of questions. And often, you have very few answers.
My point is that sharing those questions, and engaging in conversations around those questions at the very beginning can bring to the whole community around a great alignment, more than hundreds pages of requirements will. Ever.
What is the biggest mistake you see in communication around development?
Coding before talking!
Pretending that, somehow, with some kind of process, we can predict the future or read other’s people mind. We simply can’t, deal with it.
I see a lot of developers start coding without asking any questions. I also see a lot of development activities starting with tons of documentation.
Pretending to have understood everything lures developers into writing code instead of asking more questions about the product and the business goals. Being humble and passionate about the business value is crucial in software development – don’t be afraid to ask.
Also upfront analysis and requirements documentation are dangerous paths to follow:
- They are difficult to read.
- They give you the false impression that every issue along the way is described in them.
- There is rarely a reference to business goals.
- They picture a static environment where business needs don’t change over time.
- Most importantly, they shut down any kind of discussion: “Why are you asking me this? Read the documentation!”
So, there is no return in investment when building these documents.
Developers usually love to code and they are happy to start coding as soon as possible. However this does not pay off when you start getting your product increment rejected by stakeholders. Or, you have to do twice the work on the same feature because it simply wasn’t right.
Alignment around scope and context is provided by conversation that happen before and during the development activity. The output of those conversation are the living documents that you create during those discussions and the working software that you deliver over time.
Alignment is not provided by static requirements documents, the only kind of conversation that they lead to are arguments.
For more, see Lorenzo’s talk at Voxxed Days Ticino: