2024 Public Training Schedule
November 18 – 21, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
December 9 – 12, 2024 – Agile Analysis and Design Patterns
Half-Day Sessions
Follow me on Twitter:
Blog Post Categories
- Announcements {19}
- Articles {2}
- Bits and Pieces {74}
- Blogosphere {1}
- Bonuses {2}
- Build in Small Batches {27}
- Collaborate {38}
- Create CLEAN Code {34}
- Implement the Design Last {11}
- Integrate Continuously {30}
- Off-Topic but Interesting {3}
- Rants {82}
- Refactor Legacy Code {24}
- Say What, Why, and for Whom Before How {22}
- Seven Strategies {38}
- Specify Behaviors with Tests {17}
- Write the Test First {27}
Archives
Privacy Policy
(c) 2024 To Be Agile
- September 10, 2015
- Say What, Why, and for Whom Before How
In traditional software development, up to half of all development time is spent writing, maintaining, and interpreting requirements. Even more than bugs, requirements are the single largest time sink in developing software. But what’s the alternative? How will developers build what the customer wants if they aren’t told what the customer wants?
The full answer is too long for a blog post. I cover it in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software (http://BeyondLegacyCode.com). It involves making development a discovery process where developers and the Product Owner engage in discovering what the customer really wants and by looking at who will use the software and what their goals are.
This might sound like a shoot-from-the-hip process but it isn’t. It’s a highly disciplined approach. There are many techniques one has to practice to do this successfully. But unlike requirements, it isn’t a rigid process so it leaves room to take advantage of new insights and learning in order to build something better than what the customer originally asked for.
Few developers can visualize a complex system before it’s built. And we do this for a living! What hope is there for non-technical people to fully visualize and describe exactly what a system should do before it’s written? This is not what humans are good at.
What we’re good at is recognizing if what we see is what we want, so let’s do that. Let’s build a little and ask for feedback. Let’s work through a couple of examples together. Let’s personify our different users by giving them a name and a back story so we better understand their needs. Let’s discuss why they want a feature in the first place and use our skills to exceed their expectations.
When we do this two very important things begin to happen. First, people get engaged. Customers see developers responding to their feedback so they become more invested in the solution and they’re much more likely to accept, use, and value what’s being built. After all, it was their idea in the first place. (I learned this trick from my wife, who’s a video producer. For more on that see https://tobeagile.com/seven-strategies-for-customer-collaboration/) Developers are also more engaged as a result. Secondly, knowing why a customer wants a feature gives developers the freedom to come up with a better solution that addresses the customer’s real concerns. Often, we end up delivering something better than expected.
Most of development is about learning and only a part of our effort is about embodying that learning in code. The longer we work on a project the more we know so we’d like to use development to learn how to better satisfy our customers. But too often requirements become the centerpiece for development that must be adhered to even when we discover something better.
Throw away requirements documents and replace them with a knowledgeable, responsive, passionate Product Owner who can describe what the customer wants and be there to answer the myriad of questions that come up in the course of development. This will help keep the team engaged and focus development on the things that matter most to your users.
Previous Post: « Build Once Then Enhance
Next Post: Ideal Days Aren’t Ideal »