These days in agile development teams there is more emphasis on design, implementation, testing towards delivery rather than the production of clear requirements. Requirements often times can become the stumbling block for either incorrect or slow implementation, as well as a complete misdirection in delivery. In agile principles communication is key between stakeholders and developers. However, such communication in requirements needs to be clearly written down and mapped out for clarity sake. Also, what is required needs to be translated into implementation. There is a translation step required here at point of functional and non-functional requirements. There are two critical points of communication failure in agile teams. One being between stakeholder and developers. And, another being between developers in the team. Often times the emphasis is on getting the correct information from stakeholders but not fully translating them between developers. These days the members of agile teams use various tools for such communication flows. In all fairness, development teams need to understand the fact that people cannot read their minds especially if such teams are working in distributed and co-located environments. And, without sufficient translation of clear requirements in written form it becomes very difficult for developers in the team who are tasked at implementation to manage and understand them. Furthermore, the speed with which the implementation is progressed can also suffer which impacts the delivery time scales.
Perhaps, a suggestion in such matters is to keep communication simple but clear. There should be no level of complications in the requirement translation and they should not read like a puzzle where the developer has to spend time trying to decipher what another lead developer or stakeholder has actually asked for in terms of implementation. In going forward there needs to be a set of work flow targets that are agreed between team members so the progress can be smooth allowing for less issues in communication and more clarity towards completed work. There are various ways in which such issues can be taken care of. However, it depends on the willingness of developers to allow for more clarity and understanding. Often times developers stress more on the technical aspects of their work rather than trying to improve their own effective communication skills. In a lot of ways, BDD (Behavior Driven Development) improves upon such issues as it tries to relay more acceptance work from the get go of implementation and testing. In tools like JBehave, Cucumber, and Spock such approaches can further be integrated and automated with continuous integration tests. Even going further, the work flow can be outlined and mapped using agile tools. Additionally, elements of risk metrics and other methods can be incorporated in the process. JIRA is a very common project tracking application which comes integrated with other
Atlassian tools. However, when a ticket is produced the actual verbiage that is added in as an issue or story needs to be defined clearly and synthetically. My proposed approach is to automate such requirements using specific keywords using a full work flow system where such issues and stories can be mapped and managed centrally with little effort. The specific keywords can be applied through script files and be modifiable based on team requirements of project work. For example, such keywords can be used in simple defined sentences: "for", "in", "out", "allow", "apply", "change", "remove", etc. All these words imply a specific task in relation to the work that needs to be applied. Notice the two sentence phrases below. The second one is clearer than the first in what really needs to be implemented and what really is implied from the stakeholder to the developer within a JIRA ticket.
- Filter out id that is not in the list of ids
- Filter for id that is in the list of ids
If one gave such requirements to a developer especially to a new starter, without any real knowledge of the system architecture other than the programming language, they may in fact get quite lost in terms of what was actually implied in the sentence. Moreover, if the written requirements do not agree with what the lead developer, architect, or stakeholder actually wants you to implement then that will increase the confusion not to mention frustration even more. Plus, relying on verbal communication to a limit is acceptable but may hinder the understanding even more as well as defeat the purpose of having formal requirements specifications as a way of tracking work and building automated acceptance tests. The first one reads with a double negative and almost like a puzzle. The second clearly states what needs to be implemented. Notice the keywords like: "for", "in", "out", "not", "list". These words make a big difference and not only that but the order in which they are put in the phrase can too. The first one implies to use for-each loop step to remove from a list. However, the second one implies for-each loop step to add into a list. The general terms like "out" can be translated to imply remove from and "in" to imply add in. But, obviously such keywords are based on context. Going further, if such keywords were added into a script file and the process of requirement production was automated it may in fact help speed up communication as well as correct implementation of requirements. If one is using JIRA this can be a fairly productive aspect for a team. Utilizing work flow modeling and Java, Groovy, or Python for integration and NLP for linguistic translation. The impediment from lack of requirements or indecipherable requirements could be reduced. The very same keywords can be linked to BDD acceptance testing criteria as well. When communication can be broken down into simple granular level with agreed use of words it can help developers understand and link requirements to implementations quite rapidly in an agile process. Requirements are an important step in the software engineering process. Such requirements need to be elicited, analyzed, specified, validated and verified in the process of delivery.
