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.
