Cooperation between programmers and business

There are many project management methodologies. Each of them in its own way helps to achieve business goals. Often they are not simple to establish, especially at the beginning of a project, and are formed only during implementation. Agile methodologies have been developed in response to this problem, at the core of which is the frequent exchange of information between the development team and business representatives.

But what does this look like in practice? I will try to provide some real-life examples describing the importance of good cooperation between developers and business, and what problems it helps avoid. Many technical people will probably now think "there is a product owner in my team, I don't want to talk to the business". In an ideal world this might work, but the reality is somewhat different.

‍

1) Project timeframe

It will sound unbelievable, but sometimes the development team is not aware of the timeframe in which the functionality should be proven. This is one of the most important architectural drivers, which allows us to determine what architecture will be appropriate to solve a given problem. This kind of understatement can happen for several reasons:

Business takes the term for granted, e.g. Black Friday
Business uses holiday names, e.g. Thanksgiving (in Canada 11.10.2021 in the US 25.11.2021)
Business using the term Q2 has the beginning of the second quarter in mind, the development team is targeting the end of Q2.
The last example shows quite emphatically that such a frequent term as Q2 makes us have as much as 90 days of discrepancy in the meaning of a given term. That's quite a lot… That's why a common language is so important, and it can be improved by asking simple questions:

"By when should a given functionality be proven-what is the exact date?"
"What is this particular date based on?"
"Which of the project's functionalities is the most critical?"
"What happens if a given functionality is not proven on time?"

‍
A system that is supposed to handle the increased traffic on black friday delivered 2 days after the time is already useless, so it is worth knowing the time frame and the next point when developing a given software:

‍

2) The purpose of the project

Developers like to "close tasks." They get a specific user-story, estimate, write code, and close the task. At first glance, everything looks ok, but it happens that the task is not specified or "bites" with another task. It is worth asking questions in such a situation:

"What problem is our project trying to solve?"
"How does the task contribute to solving this problem?"
"Is the business aware of inconsistencies between tasks?"
"Is the given solution intended to satisfy the business or the end user?"
"Do I know a better way to solve this problem?"

‍
Many times the whole team would ask ourselves, "How will this task contribute to the good of the whole project?" Often we discovered a completely different perspective on the problem from the business and developer side, which we were not previously aware of. Knowing the purpose of the project, we as developers can also come up with better solutions:

Problem -> The business wants the default language of the application to be English, there is to be a language change menu on every screen.

Team suggestion -> We can pull in the language used on the user's device and thus set the language in the app, which can be changed in the settings. A small change, but for an app whose visual layer was extremely important, hiding the language selection menu was significant.

It is sometimes worth asking ourselves "Why?" before taking a task. We may see an inconsistency with the project's goals, and it may be worth going back to the business with our point of view. Ask about the origin of the task and whether the task in its current form coincides with the project goal. It's just a few minutes of conversation, and it can save many hours of programming, and it will help to improve communication with the business, which is the next point.

‍

3) Communication with the business

It is said that good communication is the key to a successful project, and I completely agree. When I listen to stories about "tragic projects" very often the problem mentioned is poor communication with the business. What does this actually mean? From my own experience, I can list some of the problems I've had:

Business is afraid to talk to the development team.
Developers are afraid to talk to business.
Chaos in communication channels - not sure what to do.
Many kinds of business - not sure which is more important.
Business imposes unrealistic deadlines.
Business does not understand our technology.
The answer to points 1, 2, 3 is to establish common channels of communication. It is important that there is one and common channel. It is good for other project members to be able to see the discussions and contribute to them. A single channel of communication ensures that bugs or uploads do not get lost in the depths of spam in a private mailbox, and if someone wants to change the color of the buttons throughout the application, everyone can read why, so that they can possibly opine something about it. It is worth adopting the principle that we play to one goal and the success of the project depends on joint efforts.

Points 4, 5, 6 can be solved by organizing "demos" after the end of the sprint for more stakeholders/businesses. It is also important to discuss priorities for the current and next sprint or business access to Jira (read only is enough). If there are any difficulties then you can show what the team is currently struggling with. I've had the opportunity to observe how, after a joint demo, representatives of relatively independent businesses among themselves determine whose functionality is more important, and sometimes manage to pull out the joint part and everyone is satisfied ?

Technical metrics in a project are very important, it's good to know what test coverage we have or the percentage of successful implementations. However, through the prism of time on projects, I also look at how the cooperation with the business went. It's worth doing a joint retro after the project is over and finding out what went well in communication and what can still be improved. At the end of the day, there are people behind the projects, not just metrics, let's make this cooperation fruitful and generate good emotions.

This is what I wish for everyone, that the cooperation between the development team and the business is smooth and natural. Building walls and rigid divisions in agile methodologies does little good - it's worth adding that a common or ubiquitous language greatly facilitates software development, as Eric Evans wrote about in his book on DDD.

Ps. It is worth adding that these are my subjective thoughts, as many teams as many problems and solutions. In agile methodologies, different people take on different responsibilities, and it's quite possible that in large teams a programmer may not even have access to the business. However, I think it's worth tearing down such artificial walls, and sooner or later there is a shortening of the distance between programmers and the business-it usually comes out good.

Have a great day! 🙂