Collaboration

One of the four pillars of the Agile manifesto (https://agilemanifesto.org/)  is:

we have come to value:…

Customer collaboration over contract negotiation

At a basic level this means that instead of having a frigid, legal relationship between the business stakeholders and the development team, it is more constructive if they maintain a convivial relationship between them. Software development does not always proceed as planned and sometimes takes on a life and a direction of its own. If there exists a relaxed, friendly relationship between the customer and the developers, then this organic growth can happen. Otherwise, it can’t.

Various factors pose a challenge to forming a collaborative environment. For a start, there is the normal commercial tension between the supplier and the customer where each wants a “good deal”. Additionally, the business stakeholders and the development team both have different ways of thinking. 

Business stakeholders think in terms of generalities and business benefit.  “Putting up a slick e-commerce site would help boost sales.” 

Developers, on the other hand, think in specifics and look for elegant solutions. “What would be the best web development framework to use for this client’s requirements?”

Because of these differences, it is often useful to think about creating a collaborative environment as a pragmatic exercise rather than as in idealistic one.

Clear requirements

If there is one thing that the business stakeholders and the programmers need to agree about, that is: what the system is meant to do, what the system should look like and how the system should respond to user input. If the business stakeholders and the development team can agree on the exact system requirements then their different approaches can remain a source of reciprocal amusement, instead of becoming a project threat.

The following science-fiction short story demonstrates this reality, to an extreme that some business stakeholders would probably empathise with:

Isaac Asimov

“Reason” (https://en.wikipedia.org/wiki/Reason_(short_story)) is a short story by Isaac Asimov in which two astronauts are assigned to a space-station which orbits close to the sun. The purpose of the space-station is to focus a high-energy radiation beam onto a receiver placed on earth, thus supplying the earth’s total energy needs.

While the astronauts are on the space-station, the space-station control-computer comes to the conclusion that the power source of the space-ship is god, that it, the control-computer, is god’s prophet and that everything outside of the space-ship is merely an illusion and does not really exist. A new religion subsequently begins in which the robots manning the space-ship start worshipping the space-ship’s power source, with instructions on the correct mode of worship provided by its prophet, the control-computer.

A solar storm is expected, which will knock the radiation beam out of alignment, potentially threatening to incinerate populated areas on earth. The astronauts are barred by the robots from touching the ship’s controls, since they are not part of the control-computer’s religion. When the solar storm does hit, the astronauts are relieved to find that the robots maintain the exact alignment of the radiation beam. Since part of the control-computer’s religion is to maintain the measurements that indicate correct alignment of the radiation beam, the robots take the required corrective action to maintain the radiation beam’s alignment, as part of their religious obligations. This despite the robots’ belief that nothing outside of the space ship actually exists.

The astronauts realise that their job has been taken care of for them. It is irrelevant if the robots perform their function because that will enable the earth to receive energy safely, or if the robots perform their function because that is part of their religion. In summary, so long as the “system” generated the correct output, both the stakeholders (the astronauts) and the system engineers (the robots) were able to happily coexist despite their very different perspectives on what was actually happening.

Similarly with regards to software development, whereas it is vital that the business stakeholders and the developers agree what is being developed and how the software should behave, it may not be all that important for the two teams to think about the new system in the same way. If the software means increased revenue to the business stakeholders, but means a funky open source based project to the developers, that’s OK as well.

Software quality

If clear requirements are the linchpin of collaboration, then investing in system fidelity and quality engineering is the bane of peaceful coexistence between business stakeholders and developers. Simply put, this is because the business stakeholders just want a “result”, but the developers want to create and work on a “nice system”.

Business stakeholders couldn’t care less, on the whole, how elegantly engineered the system is. As long as the software produces the correct result, they reason, it will result in the desired business benefit. Developers, on the other hand, very much care how well engineered the system is. For a start, they want to work on a clean system because that will allow them to think naturally about the problem domain, without getting clogged down in convoluted legacy code. Secondly, the cleaner the system is, the easier it will be to extend the system in the future without anyone having to pull their hair out.

In fact, it is interesting how difficult it is for software developers to sell the idea of quality software development to business stakeholders. The same business stakeholders have no problem in understanding why they may pay more for a quality product in other areas in their lives. It is natural that a Bugatti or a Rolls Royce should cost many times more than a cheap hatchback, which can effectively do the same job. This is understandable not just because the more expensive car looks better, it is also understandable because the more expensive car is better engineered.

Why then is it so difficult for developers to sell the idea of quality software engineering to business stakeholders?

Universal and local quality

High quality manufactured goods are universally accepted currency. Regardless of which country you’re in, driving a Bugatti down the high street will make people’s heads turn.

The converse is true also, however. It is exactly because high quality goods are universal currency that people know that, when they buy them they’re getting a valuable, quality product. This is because our assessment of product quality relies as much on other people’s response to our ownership of that product, as it relies on our understanding of what comprises a quality product in the first place.

This rule of reflected glory breaks down in the world of software engineering, however. Software quality is very difficult to demonstrate objectively to anyone who is not working on that particular software system, and therefore you can never get that confirmatory “Ooh!” which tells you that you have indeed spent your money on a quality product.

The reason that software quality is very difficult to assess objectively is because every software system is unique in the balance required between

• overall design simplicity and component complexity,
• ingenuity and straightforwardness,
• conciseness and being self explanatory and
• data normalisation and data access complexity.

Since software quality is not demonstrable to anyone outside of the organisation that is developing the software, business stakeholders are left simply having to believe the developers concerning what constitutes quality in this particular piece of software development. 

Trust

It takes a great deal of trust for business stakeholders to invest time and money in software quality whose value they do not really understand. This means that ultimately business stakeholders have to acknowledge that they are not in a position to place a direct econometric measure on the value that is being generated by the development team. 

Instead of treating the software development team like a manufacturing facility, the dev team must be allowed a certain amount of breathing space. Practically speaking, this means that there must be a certain degree of disconnect between the perceived commercial value of the dev team’s output and the funding that is provided for them.

With clear requirements and an atmosphere of trust, it is possible to develop the right quality software, on time, with no-one being injured in the process.