The traditional ways that we describe how to build something, whether it’s a blueprint for an office building or the specification for a computer program, it always involves a document that describes WHAT to build and often includes information on HOW to build it.
However, these documents are often missing critical information on WHY these features are wanted in the first place and WHO they are for. Both of these pieces of information tell us a lot about what to build and knowing them we can often build better features for our users then was originally conceived.
This is the whole point of Agile and of getting feedback. We want to get feedback on many levels. We want to know from users how we can make their lives easier. We want to know from stakeholders if our software is meeting their needs. We want to find ways of excelling and delivering more than what was asked for.
This is a bit of a different approach than the hard-core negotiating business contract deals that are sometimes made. But I’m seeing more and more software written under contract using Agile methodologies. Clients are recognizing that a block of time from a highly productive team will always yield valuable results.
When we understand WHY a feature is wanted we can often build a better feature than was originally specified. This is the whole point of feedback in Agile, but we have to connect our feedback to the people who can do something about it, the developers on the team.
I always encourage development teams to connect with their users, whether it is at a conference or a tradeshow, or driving down to visit users in their offices because I know what a profound effect it has on both the users and the developers. Users feel really appreciated and they begin to really open up and give us valuable information on how to improve our products. For developers, I see their eyes open up in many ways for the first time as they begin to really see how people assimilate the code that they wrote and use it in the work or in their lives.
Who we’re writing code for also should have a big impact on what we built. We want to visualize being the user or the client of the services that we’re providing so that we can make it straightforward to use our services. This concept was echoed by the Advice from the Gang of Four when they said, “Design to interfaces.”
As we move from thinking about what to build to why we’re building it in the first place, we get to challenge some fundamental assumptions that we may be making. We may also get to validate that what we’re building will really satisfy our customers before investing in actually building it. This helps us spend our client’s resources most effectively. We end up building a system that satisfies more of the customer’s needs by understanding what those needs are up front and ideally embodying them in a set of acceptance criteria that we can automate through acceptance tests.
When we understand why features are wanted and who they are for, then we have the information we need to build better features that addresses the needs of our users more fully.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Product Owners.
Previous Post: « Use Development for Discovery
Next Post: Describe What You Want Not How to Get It »