This post continues my ongoing series revisiting the principles behind the Agile Manifesto. This time we are focussing on the following Agile principle – “Business people and Developers must work together daily throughout the project.”
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 delivered to me by a Business Analyst on a regular basis. 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 a typically a significant delay and the answers they supplied usually just sparked more question 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 important benefits. Both business people and Developers gain a common understanding about the design and purpose of the new system more quickly. Developers can provide insights into the technical feasibility and implications of requirements, helping the users make more informed decisions. Feedback on the Developers work comes regularly as it progresses, allowing them to make adjustments as needed to better ensure that the end product meets the needs of its users.
When planning and designing a new system, users typically don’t really know what they need until they start to see something come together. It’s near impossible to perfectly design a new system in the abstract. Change will be inevitable as soon as people start to see how things really 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.
The result of all of this will be a more valuable product, built at a lower cost, in a shorter time and with less conflict along the way.
--
Hi, my name is Simon Kneafsey and I am a Professional Scrum Trainer with Scrum.org & TheScrumMaster.co.uk. I am on a mission to simplify Scrum for a million people. I have helped over 10,000 people so far and I can help you too.
Learn more at TheScrumMaster.co.uk and signup for our newsletter with 80,000+ practitioners.
