BPMN for Profit and Fun: Seamless Teams Collaboration in Software Development
Clear communication is key in any area, but when considering the software development industry, it is even more important as it typically involves an audience with completely disparate expertise and backgrounds, all working towards a common goal.
In order to capture the expectations in a way that can later be referenced for implementation, many techniques/tools have been proposed over the years, such as the C4 model, UML, and the 4+1 view model. Yet it is still a challenge for many teams and projects today.
In this article, I discuss the use of BPMN as a relevant contender and explain how it can help bridge the gap between business and engineering.
Typical Challenges
“The single biggest problem in communication is the illusion that it has taken place” — Bernard Shaw
For context, let’s imagine that you have the following structure:
- Business: Come with desires that reflect the company’s goals
- Product: Collaborate with the business to understand how to achieve the goal by enhancing the existing capabilities of the company’s software products
- Engineering: Collaborate with the product team and the business to implement the necessary changes to the existing software artifacts
As we can see, each of the stakeholders has a different understanding and perspective when talking about the goal. Since there are likely going to be different products sharing the responsibility, each product and engineering team will focus on the functionalities that fall within their product’s boundaries.
Now, let’s add a common practice: Agile. Under its inspect-and-adapt cycle, each team will start working using mainly user stories, which divide the end goal into small features.
The main challenges of a setup like the one above are:
- Broken Telephone: As the information traverses, there is a chance of deterioration of the actual goal.
- Fragmented View: Each team’s user stories, sometimes the main or sole source of requirements, provide a limited perspective of only what is directly in front of them.
Both challenges have the potential to create invalid assumptions since each team lacks the overall vision of the project, even if they go with an iterative approach for developing and delivering the features.
How can we improve?
Let’s Add (The Right) Documentation
Documentation in software development is one of the many points where there are numerous disparate positions.
In the traditional Waterfall approach, the journey begins by capturing every intricate detail before moving forward. In contrast, the Agile approach appears to reverse this paradigm, where any documentation is sometimes viewed as counterproductive or a sign that we may not be fully embracing agility.
As the title of the section indicates, the solution does not reside in either extreme. It is about finding the right balance by providing sufficient documentation and continuously revising it as you progress through the project lifecycle.
In the end, it comes down to embracing the documentation as part of the development, like any other coding artifact.
Which aspect should we focus on? And what documentation standard should we use?
BPMN to the Rescue
BPMN, which stands for Business Process Model and Notation, provides a graphical representation that allows you to define, understand, and communicate business processes in a standardized and easily understandable way.
While not a new option, with the latest specification dating back to 2011, BPMN focuses on helping to capture business processes, as its name suggests.
This may seem odd and counterintuitive to the engineering audience familiar with UML or C4, which are often seen as the obvious choice.
The issue with UML or C4 is that they were created to capture the technical aspects of a solution, whether already implemented or planned. In the beginning, you often lack sufficient knowledge about what needs to be done.
More importantly, while the technical decisions are necessary, they should serve the business requirements and not the other way around.
So, instead of starting with a sequence diagram, which assumes some prior knowledge of the responsibilities/objects and has reduced value for the non-technical audience, why not first have an end-to-end view of the main tasks expected to take place?
This is where BPMN shines, even if you do not hold a traditional business analyst role.
It allows you to see, discuss, and interact with your product and business counterparts more efficiently. This provides you with a bigger picture of what needs to be developed, allows easy identification of dependencies, and facilitates discussions around responsibility boundaries.
Introducing BPMN into your Development Lifecycle
Learning BPMN is not difficult, the challenge lies in deciding who should do so and when.
Who
Product and engineering teams will be involved, with the product team ideally driving the first iteration and engineering helping in refining it.
When
Before the development is expected to begin and iterated through the course of the project.
The image below captures one possible flow:
In this proposal, the BPMN is a prerequisite for development and is part of the project kick-off.
In the case of a green grass project, the first BPMN version will be at a higher level. Essentially capturing the tasks involved, without necessarily worrying about service/domain boundaries.
Note that you are only describing the main scenario without including alternatives for unhappy paths or other major business decisions. A second iteration can expand on these.
It is important to highlight that if there are many possibilities, you should focus on the main ones to avoid overwhelming the diagram with excessive information. You can capture the other decisions in a separate document and reference them in the diagram.
Then, by interacting with the engineering team (architect included), refine the BPMN through a series of discussions where the end goal is challenged. At this point, swimlanes and pools within the diagrams are defined or redefined, and it is ready for the next phase.
This process would go on, and with each delivery cycle, the documentation would reflect the learnings and relevant implementation decisions made for the wider audience.
An additional benefit of this approach is its potential to engage the development team in discussions of the what and why, instead of focusing primarily on the how. And that, in itself, is a win.
Conclusion
Our software solutions are responsible for capturing ever so complex aspects of our evolving world. It is increasingly common to need to satisfy business requirements that span multiple domains and services in your company, and beyond.
Having a lingua franca to be used by all the involved parties is ideal, and while no single methodology or tool can capture everything, BPMN offers a valuable approach.
It fosters the use of a non-technical language, can be leveraged with minimal formality, and has the potential to provide a comprehensive view of the solution for the business, product team, and engineering team.
When combined with an Agile methodology, it can provide a reasonable starting point for development without falling into the analysis paralysis of the Waterfall approach. During each iteration, you can revise and expand the documentation as necessary to capture the specifics required for your solution.
This is not to say that the other approaches have no place or value, but they should be complementary, adding the technical details that are actually meaningful and can’t be easily taken by BPMN or the source code itself.
Additional Resources:
Editorial reviews by Catherine Heim & Sam-Nicolai Johnston.
Want to work with us? Click here to see all open positions at SSENSE!
