An important task for a development team is to collaborate effectively with business stakeholders. They have invested in the project, and they know why. As developers, we should help them reach their investment goals. To do that, we must understand what these are. Users are not the best source for that, it's business stakeholders you need. This article is about some ideas for improving the business stakeholder collaboration needed for that.
Good collaboration with business management and within the team is vital for project success. Without it, your chances of providing them with the product they need are slim. The product that will help them solve their business problems. Help them reach their business goals. The profitable product that represents a good business investment.
As software developers, we have always learned to talk with the user, and to make the user happy with what we give them. Most of us are pretty good at that.
Users can tell us what they want out of the system. That's good! But is that the same as what the business as such wants the system to do for them?
In most cases it's not. That's because typical users don't know what the relevant business problems and goals are. They are experts on their own jobs! They seldom have the overall business view.
The business manager's view
That view is the business manager's view. It's also the view of manager assistants and other subject matter experts. So these are the people you need to talk with about problems and goals. And also about business structure. This picture illustrates that from an agile development perspective:
Do you want the structure of your product to match that of the targeted business? You should, because that brings a number of great benefits to the product. Short term, but even more important long term benefits. For information on business structure, business stakeholders is your only true source.
They could help you get your structure right. You could show your initial structure to the business people. You could ask them if it matches their view of the business's structure. This would create a healthy atmosphere for these discussions. The result of that would be super business-oriented feedback. Which is the basis for great software-to-business alignment.
That in turn would bring other benefits. Business problems and goals are almost always attached to parts of a business structure. When your product's structure matches the business structure, good things happen. It will get you more and better information about these goals and problems.
Which is bound to help you get excellent requirements around problems and goals to work from. And without that, how could you ever build a product that helps the business?
What's great about it is that you don't have to do much to produce these structure descriptions. You already have what you need in your product backlog. All you have to do is give them a business-driven structure. Consider this diagram, a clip from Azure DevOps Services:
If this view doesn't match the business people's view, they will tell you about it. They will share their view with you. Which will then be a perfect basis for goal and problem discussions.
It would be even better if you could produce another view, based on the one above. There are tools you can use for that purpose. Lacking one of those is no big problem, though. You could use any proper tool that you already have to produce something similar:
You could use these tools for internal communication too. There's a tremendous value in having all team members know what you're really building. And why you're building it.
There's an old story about this.
It's about a man coming across three masons chipping trunks of granite from large blocks. He asked them what they were doing.
The first man answered "I'm hammering this stupid rock, and I can't wait until 5 when I can go home."
Skipping the second man, the third man proudly answered "I'm building a cathedral."
You can read the whole story in an article called Best Practices for Business
Conclusion
Most teams can do a much better job on their collaboration with business stakeholders. Showing these the right pictures of what the team is doing and planning can help a lot with that. And it's not difficult to do. Most of the business boxes you need should already be in your product backlog.
Getting the business structure right as early as possible can help a lot. It's the same with business problems and goals. The sooner you get a structured view of these, the better will the project go.
Getting it right will result in a better product. Getting it right early will result in a product faster shipped at a lower cost. It will also result in a less frustrated customer. Guaranteed!
Your structured product backlog can help you improve your collaboration with users as well. We might publish an article about that as well later on. If not, the online training and certification program contains a good deal about it.
By the way! When we're on about users and the UI we'll develop for them, look out for another article coming soon. It's about the ongoing micro frontend revolution. It's something you don't want to miss.
