There was a time, not long ago, where you had to get requirements in software projects. To develop software products, first, you had to go get the requirements. It was a necessity. It was just the way to do things. However, there are newer processes and tools, and it happened that requirements are outdated. At least in the way that we know them.
The requirements were a set of guidelines that told the team what to build. You would first have to figure all of these out, then you could start. The order of doing that, requirements, then building, was important. It could not be changed.
If there were changes to the requirements, that meant the plan had to change. Thank goodness this inflexible process has alternatives. Agile, and flavors of it, have become strong contenders to this process. Agile brings a flexible approach, where you adjust to best meet the needs. It also brings tools to help figure out what needs to be built. By means of its principles and values.
Requirements are outdated
As a concept then, the notion that you must figure everything out and create a plan, is no longer as effective as it once was. Requirements are outdated then, because there are newer processes. Newer processes that are more adaptable to change. Newer processes that are more forgiving in complex software environments, where you will never be able to “figure it all out” before you start the work.
Requirements remain, even in newer processes
However, requirements as a concept remain. Even in Agile processes. It is deeply embedded in software development practices. It is also a habit of use in most business cultures. Especially those not fully embracing Agile.
Well, let’s get rid of the concept and the term! Let’s start fresh and use that start to focus on better ways. So come along with me and let’s figure out why you should make this change. Ditch the concept, forget about the term, and focus on better ways!
Ditch the concept of requirements
But why you ask
Requirements are too strict of a guideline. They do not offer the flexibility to adapt to ever changing business needs. They are thought of as a rigid definition of work to be done. This kills the creativity and problem-solving ability of the team. Which, hurts the solution created.
Requirements make you believe there’s a Magic Bullet. A Magic Bullet for information that is needed. This Magic Bullet tells you what to do, you just have to find it. But in reality, there is no easy answer. You won’t find what has to be done hidden somewhere. Where you stumble across the answer. Instead, you must put in the effort. Ask questions of users and stakeholders. Put in the time to understand the needs. Only then will you get to the answers you need.
Also, Check Out The Modern Product Owner!
Requirements are outdated as they can impede discovery and learning
Requirements impede discovery and experimentation. It’s interesting that requirements are affiliated with discovery. It’s often thought that you take on discovery to find the requirements. Associating requirements with discovery is a bit of a misnomer in my mind. As team members must do the research. They arrive at an understanding of needs and goals. Then they will create the solution. They do not discover the solution, least of all in requirements.
The team does not discover a solution, least of all in requirements.
Requirements imply that the work is known. Often the work is unknown and must be figured out along the way. The goals need to be understood. So the team can figure out how to meet those goals. IE, requirements are often thought to be the “what” and “how” of the work. However, the “what” needs to be understood by the team, so that the team can create the “how”. Meaning that the team needs to determine how best to meet goals and needs. It can’t be dictated in a requirement to them.
False sense of security given from requirements. Having requirements often makes the team think that is the best way of doing things. They are given the requirement, and might not think creatively and critically about that solution. This can lead them to miss a better way, a better solution.
How do you make the switch
Understand that the work to be done has to be determined. The team puts in the effort to understand needs and goals. They then work with them and fill in with needed detail as they go. Constant communication and collaboration with the users give the knowledge needed to build what’s needed.
Be flexible and allow for changes. You do not know what you do not know. So you have to allow for the solution to evolve and grow over time. It will get to where you want it. It just doesn’t go directly from A to Z. It’s a process to get there.
Remember to demo, and adjust based on feedback. Real feedback is key. It will tell you more than any requirement can, and will do so more quickly. Getting feedback from users is the fastest way for the team to learn and adjust. Which lets the team get to the finished solution faster.
Additional reading and ebooks helping with requirements are outdated
