In today’s software development practices, we have seen the paradigm shift towards agile methods. While effective, in the past years we went through the “trough of disillusionment” of the hype-cycle. A number of problems have been pointed out and as a result, improvement suggestions have been made.
The underlying core of criticism stems from two main issues, which were never intended by the authors of the Agile Manifesto. First, the “translation” of “we value more…” to “we do not do …”. The signatories of the Agile Manifesto actually intended to ask everyone to focus on value creation. Yet nobody ever claimed that value for the customer lies in code alone. Secondly, the manifesto addresses software development. Yet neither does an organization consist of software development only, nor does software solve all the problems of a company.
Coming out of the trough, which in my opinion currently is taking place, the value of other roles and tasks in software development is recognized once more.
One of these tasks is Business Analysis. In this article I want to shed some light on the value of BA, especially emphasizing the impact it has on quality.
The Importance of Input
No software can be developed without input as to what it actually should accomplish. Agile methods encourage continuous communication between the developers and the customer. To be clear: everyone having a task in developing the software is, by definition, a developer. It sort of corresponds to the IIBA definition of a business analyst, defining anyone doing BA tasks as one.
The understanding of what has to be developed comes from two sides: the customer and the development team. The customer is expected to tell the team what he needs. The development team shall critically review and understand these needs a convert them into software to check against the expectations of the customer. In the course conversations and iterations, many questions will be asked, covering the context of the communicated needs as well as specifics of the features requested. We can understand that as implicit business analysis, done by the development team.
The Issues of Implicit BA
One might say, that the implicit BA should be enough to deal with the requirements for the development. But experience shows us, that this is not the case. One of the shortcomings lies in the scope of the development team. It is typically limited to the software development in the designated area. Therefore they will mostly focus on their area and try to solve everything within their area of influence. That can lead to the following problems:
- Implementations into areas and software, where they do not belong
- Software solutions for problems, which would be better solved by a process change
- Local instead of global optimizations
All these points would also account for “bad quality” of a solution, even if the software development would be perfectly fine.
An additional issue of the implicit BA lies in the fact, that most developers and a high number of testers are unaware of the tools and methodologies of Business Analysis. This does not mean that they cannot do it, or that they are not able to do a business analysis. Yet it definitely promises better results, if someone has a solid knowledge of the methodologies, as to avoid common mistakes and to ensure a professional outcome.
The Value of BA
The work of a BA makes the life of a development and test team a lot easier. First, if done well, only things really worth implementing should actually reach the team. A solid BA will have the business knowledge and the technological background to explain the needs as well as the overall business context, which is imperative for high quality solutions.
Furthermore, a BA will typically have the knowledge to get more information out of the stakeholders and can also describe it better with regards to the goals as to the implementations. He won’t come up with actual implementation wishes, which happens rather often when talking to the stakeholders directly. Understanding the importance of not just implementing what the customer asks for, but the ability to understand the problem, formulating it and potentially reshaping it is the asset a good BA will bring into the software development process, enabling a better quality of the solutions and the overall implementation in the context of the enterprise. Understanding where, when and by what means a solution is how BAs definitely change enterprises and enable quality.