In software development, requirements are often the driving factor of the output. They are treated as the end all and be all. They are what the team is trying to deliver. Requirements are used to tell the team what it is that they have to deliver. Often are a stringent list of details, to guide the team to the final product. However, they often are incomplete. Could there be a better way? A way to guide work without telling the team exactly what to do. Could requirements not be all they are cracked up to be? Whats better than requirements? In the following, I discuss some drawbacks of requirements. Common problems with requirements. Issues from traditional requirement driven processes. I then discuss some alternative approaches. Ways that align with agile and help the team deliver.
Requirements Are Too Stringent Of A Guideline
Requirements are a definition to be followed. They are stringent guidelines of the work to be done. This can lead to a lack of creativity or a lack of innovation. The feeling is that the requirement is dictating the work and that is what must be done. This stifles the teams ability to build the best solution they can.
The rigidity of requirements is something that goes against agile methodologies. In agile, responding to change is a guiding thought. Following requirements strictly, and responding to change, are at odds with each other. This inflexibility is a drawback with requirements. But, whats better than requirements?
Before getting into that, I first have to go out on a limb. I would argue that requirements should not exist in agile software development. The information is needed, but the concept of a requirement is too stringent. Whats better than requirements? There are processes available that don’t follow strict requirements. They use goals, or actual user feedback to determine the work.
When Are You Done
With requirements, sometimes you don’t know when you are done. Conventional wisdom states if you complete the requirements that you have completed the work. However, without knowing the goal you are trying to achieve, you don’t necessarily know if you are done. The team is strictly following a path laid out before work started. It is unclear from requirements alone if goals were met. It is not always certain if requirements are still valid while the work is going on.
With requirements, the team can be lulled into a false sense of security, in that requirements are exactly what is needed. Surprise, sometimes they are wrong! Like anything, requirements have an element of error in them. Working off them strictly can lead down the wrong path. Requirements can be based on faulty assumptions and information. Strictly following them leads to errors.
Whats Better Than Requirements?
- Working towards goals
- Understanding needs
- Getting honest, timely feedback
Working towards goals gives the team the ability to see the endgame and visualize a path to get there. By understanding where they need to get to, the team is better able to build towards that goal. The team can create solutions with goals in mind, thus getting better solutions. Understand goals, and fill in with information to support the delivery on said goals.
Understanding needs has the same effect. It allows the team to build towards a goal, but to do so in a way that helps the user. There are lots of options for getting to a goal, but finding something that the user benefits from is understanding their needs. This is why goals and needs are whats better than requirements.
Getting honest and timeline feedback is how you fine tune the work being done. Build fast, fail fast, and learn fast, so that you can course correct. You will never know everything. Instead get useable pieces in front of those who will use it, and get their feedback. This lets you figure out how to fix what you have and how to add what you still need. Ultimately moving towards the goal of the finished product. This is why real feedback is whats better than requirements.
Final Thoughts On Whats Better Than Requirements
Ultimately, whats better than requirements, is a mindset that problem solves. A mindset that is flexible and adaptable. This is an agile mindset. Requirements are all about defining the work to be done prior. Knowing what is needed. Also knowing the tools to be used, processes, and how to go to the work. In the real world, this is not feasible. You have new work that is full of unknowns. There are changing needs and technology landscapes. These things don’t allow the team to know everything before they start the work. The way to approach is to work towards needs and goals, figuring out the best way forward at each piece of work. Also, getting good feedback from users and stakeholders. This is an agile mindset and approach. Whats better than requirements, is ultimately an agile approach to the work.
Whats Better Than Requirements – Further Reading:
Here I discuss some topics that can help improve an agile implementation. A Blueprint for Agile…5 Tips to Help
To help narrow the scope. Along the lines of incremental delivery and good feedback. Here I discuss Vertical Slicing. Vertical Slicing In Agile Is Key To Incremental Delivery. This slicing of work is whats better than requirements. Its a valuable method to break up work and work towards goals.
Also, good information at this post, on User Story vs Requirements. Whats better than requirements is all about how you present the information. Presenting in story form is a great tool for communicating. And for building context around the job to be done.