My previous blog described “Requirement-Driven Product Development” (RDPD). One of my readers asked a very important and well-formed question:
“Lou, nice article. Are there any specializations to the approach for software systems? Would you say that Scrum process is consistent with RDPD?
I expect that everyone agrees that requirements must drive development. The controversy is about when and how those requirements are conveyed to, or obtained by, the developers. Does RDPF suggest how to do that well?
I think the Agile community would change “Going from concept to requirements” to “Going from concept to working software.” They don’t view having requirements as an intermediate milestone with different activities before and after. Is that view in conflict with RDPD?
My logical side is drawn to RDPD but my experience is that, as a developer, I don’t always get good requirements. If people would follow your advice, I’d get great requirements; but, they don’t and as you’d predict, I don’t get good requirements.”
In researching Agile (I can’t remember the source) I found the following statement: “Agile systems engineering and project management is about ensuring the right information is available to the development team in the right level of detail at the right time so they can build the right product.“
To me, this statement is fundamental and RDPD is consistent with this statement. The questions that need to be addressed include:
- What information does the development team need so they can build the right product?
- Who develops this information?
- How and what form is this information communicated to and within the development team?
What information does the development team need so they can build the right product?
The reason we define scope, including system concepts, is so we can understand the customer and other stakeholder needs and expectations. As stated in the reader comment, all too often, the quality of requirements you get from the customer are poorly written, incomplete, and ambiguous. This leaves the developers with incomplete information as to what they need to accomplish in this next iteration of the software. To do their job successfully, they need to know what the expected outcomes are for the iteration they are working in a clear, complete, and unambiguous form that clearly communicates those expected outcomes.
Who develops this information?
YOU develop a set of requirements for the software you are going to develop as part of current iteration. These requirements need to be appropriate to the level and clearly communicate the stakeholder expectations for the iteration you are working.. A process you can use to do this are addressed in my blog: “Going from system concepts to requirements.”
I consider this activity as part of “Going from concept to working software”. YOU work with the customer and get agreement on their expectations. Then YOU develop a well-formed set of requirements that will drive design and development for the software that will be developed for that iteration. This is not something you are doing extra. I consider this part of the development effort. What you are doing is deciding on and getting agreement on what this iteration of the software needs to do and how well it needs to do it. Notice I said “what” and not “how”. This is basically the marching orders for the developers. For this iteration this is what we agree we are going to do. This is what we need to design to, build to, and test to.
It would be a best to meet with the customer to get an agreement on the requirements YOU have developed. The basic approach is to say to the customer: “Based on our last meeting, this is what we understand you would like to see done – do you agree?” The difference is that YOU (rather than the customer) have translated your understanding of the customer expectations into a clear, complete, and unambiguous format. Confirming that you successfully translated the customer expectations before actual coding, is a way to mitigate the risk that you did not understand the customer expectations – reducing the likelihood of rework.
Another thing that YOU need to define and document upfront is the interactions (interfaces) between the software and other external systems as well as how modules within the software are going to interact. I go into more detail on this in my blog: “Managing Interfaces in an Agile Development Environment”.
How and in what form is this information communicated to and within the development team?
I believe that at the top, system level, this information needs to be communicated via texted-based requirements (“Shall” statements) as part of a formal agreement between the developers and the customer. The focus needs to be on the expected outcome and “what” is needed and not “how”. At the top level this is the contract between you and the customer on what will be delivered.
However, as part of the various iterations involved in actually developing the software, alternate forms of communication within the development team can be used other than just the traditional text-based “shall” statements. This form can be a combination of UML, user stories, use cases, graphic diagrams, story boards, data flow diagrams, screen shots, emails, and even verbal. As long as what is being communicated to and within the developer team is clear and unambiguous. With a clear understanding of what their marching orders are for the current iteration, the development team can then come up with a design and code working software that meets the customer expectations.
In the above discussion, YOU is meant to refer to the Agile development team as a whole. Which particular individual (Product Owner, Scrum Master, or one or more of the developers) performs these activities depends on the organization’s implementation of Agile. No matter who does this, for each iteration, the team needs specific well-defined marching orders on what is expected to be delivered for that iteration. Given different implementations of the overall process, each organization needs to go through a thought process and figure out what is best in terms of risk and performance. From my perspective, the team needs to clearly understand what is expected of them for the given iteration of the software. I would expect different approaches depending on the type of project, the customer, the team organization, and the organization’s methodologies.
As always, comments to this blog are welcome.
If you have any other topics you would like addressed in our blog, feel free to let us know via our “Ask the Experts” page and we will do our best to provide a timely response.
Tags: agile, interfaces, Requirement driven process, requirement driven product development, requirements, scope, Scope Definition, stakeholder, stakeholder expectation, stakeholders, system concept, use cases
By Paul Miller February 23, 2015 - 10:50 pm
When customer requirements are less than adequate it becomes a commercial risk issue that require preventative measures to be adopted to reduce that risk exposure. If the customer cannot be convinced, using win-win arguments during negotiations, that the job will need to cost in some time for requirements workshoping, then a commercial risk decision has to be made. Is this worth the risk? Are the terms and conditions of the contract conducive to a lot of change and potential late delivery if we have to go with the customers requirements? Will this be a Death March project? It’s a hard decsion to walk away when you need the work to make money and be viable, but the alternative can be an irrational gamble with impacts on reputation with customers and the goodwill of valuable employees who will be under immense pressure.
By Lou Wheatcraft February 24, 2015 - 7:59 am
Paul, you make a very valid and important point. In the end, it boils down to a risk decision. Not following any of the requirements related best practices results in increased risk to your project. A rational project manager, will keep risks within a manageable range and develop mitigation strategies early in the project.
For more concerning risks and requirements see my paper “Triple Your Chances of Project Success Risk and Requirements” http://65.60.53.34/~reqexper/new/media/papers/triple-your-chances-of-project-success-risk-and-requirements.pdf
The emphasis of this paper is to identify common requirement development and management risks that can have an impact on a project’s success, possible consequences of these risks, and strategies to mitigate the risks and avoid the consequences of those risks. Recognizing the fact that poor requirements represent a significant risk to your project and mitigating these risks can triple your chances of project success.