Business People & Developers Must Work Together Daily
“Business people and developers must work together daily throughout the project.”
– Manifesto For Agile Software Development – Principles
This principle emphasises the importance of regular collaboration and communication between business stakeholders and Developers throughout the entire project/product development lifecycle. In traditional project management methods, there is often a disconnect between the business stakeholders who define the requirements and the Developers responsible for implementing them. This can lead to misunderstandings, delays, and, ultimately, a product that does not meet the needs of its users. In contrast, Agile approaches like Scrum emphasise the value of continuous collaboration between the business stakeholders and Developers to mitigate such issues.
In the early part of my career, whilst I was a Junior Programmer, I rarely met the ”business people”. Requirements documents outlining what they wanted me to develop were regularly delivered to me by a Business Analyst. I did my best to interpret and implement their wishes. If I had questions, I would pass them back to the Business Analyst, who would talk to the business people and provide answers. There was typically a significant delay, and their answers usually just sparked more questions and further delays. The process did not work well.
A skilled Business Analyst can bring benefits. Ensuring a detailed view of what is required is created up front and helping explore things the end user may not consider can save time. But at a certain point, it makes sense for Developers to talk to business people directly. To get feedback on the work completed so far and to answer the questions that inevitably emerge as the work proceeds. At this point, a proxy, even a well-intentioned proxy, will unwittingly lead to miscommunication and delay.
This closer connection can bring some significant benefits. Both business people and Developers gain a common understanding of the design and purpose of the new system more quickly. Developers can provide insights into requirements’ technical feasibility and implications, helping users make more informed decisions. Feedback on the Developer’s work comes regularly as it progresses, allowing them to make adjustments as needed to ensure that the end product meets the needs of its users.
When planning and designing a new system, users typically don’t know what they need until they see something come together. It’s nearly impossible to design a new system in the abstract. Change will be inevitable as soon as people start to see how things work in practice. So, the best way to proceed is to build what the users think they want and then adapt the system through early and regular feedback. Issues and changes can be addressed much faster this way. It will also result in an increased acceptance of the new system from business people as they see it regularly while it is being developed. This will reduce unwanted surprises when they start to use it for real.
This will result in a more valuable product, built at a lower cost, in a shorter time and with less conflict along the way.