In one guest blog post that we wrote for SkeltonThatcher blog (https://skeltonthatcher.com/blog/dealing-continuous-delivery-anti-patterns/) , we started talking superficially about a major negative influencer on delivery perfomance. We discussed how the business and technical staff having (de-)evolved into completely siloed functions, communicating almost always via email, specification documents or specification tools.
Now, we would like to specifically address this issue.
One might see this problem as related to Business analysts’ responsibilities, to Product Owner way of working or any other role the team might have. However, the point in this discussion is that we don’t care about the role.
What we have found important is that the team, as a whole, needs to clearly understand why and what is important, taking responsibility and addressing feature delivery as the mean to an end: to achieve a specific business value. In order to achieve this, the team needs to be able to answer some questions:
- What value this new feature brings?
- To whom this feature will bring value?
- How am I going to assert this feature’ completion?
And, we can see a direct relationship between these questions and the INVEST principles for User Stories definition.
Moreover, in order to deliver the best value, it is very important that each team member understands what are the priorities for delivering the features and why. This, translates into the well known principle: “Build just enough”. For this purpose, the team needs to garnish a broader view on the product itself, understanding users’ journeys, user’s objectives and difficulties.
Now, it may look like we are saying that every team needs a dedicated business analyst. Well, not exactly. All this information and understanding needs to be collected and built, but it should be done by collaborating and integrating different information sources, not exclusively by one person.
The software development team needs to take advantage of multiple times referenced T-shaped people, that can have some kind of extra knowledge on a set of matters, but are not completely siloed on those same matters.
Bottom line, these professionals, whether you call them Business Analyst, Product Owner, Business Interface, Client Representative, in order to build this knowledge, can take advantage of these techniques:
- Build a common language between “business” and “technical” mindsets. Using for example Behaviour Driven Development (BDD) can be useful, translating all the acceptance criteria for each User Story in a Given-When-Then clause. By doing this, both mindsets are using the same structured language and defining what are the expectations from both of them;
- Use a just-in-time approach to User Story specification. Following the “Build as needed”, the team should avoid big upfront specification. By assuming that we won’t have a fully detailed requirements specification, we reduce backlog clutter, creating a manageable backlog; improve team motivation as the backlog reduction is visible, improve flexibility when the unforeseen occurs. This way, the team is now able to incorporate acquired knowledge throughout the development cycle, and therefore, increasing the value delivering.
- Use the collaboration in analysis to improve team dynamics. The team is now part of the whole process, therefore increasing commitment and ability to understand and deliver the right features. By discussing business related questions and bridging them to technical aspects, both “business” and “technical” mindsets will commit to them, even if looked from two different perspectives. The point now is that those two different perspectives are now aligned and working towards the same goal.
Concluding, experience has taught us that in high performance teams, all technical elements have a bit of Business Analyst and vice-versa. Moreover, the techniques listed above ensure the creation and maintenance of such teams. Whether more focused on one single person or spread across several, it’s up to the team to decide, as long, as communication and collaboration exists.
If these techniques seem appropriate to your teams, drop us a message and we’ll contact you in order to find out how we can help you achieve a better software delivery performance.
