Websters dictionary defines negotiating as “to confer with another so as to arrive at the settlement of some matter”.
In many Agile Software Teams, there is usually the business(or customer) stakeholders and the technical(development) stakeholders. The person at the center of conferring with the business and the technical team, is usually a Product Owner or a Business Analyst. The role they play may require deep technical knowledge or deep business subject knowledge depending on the type of project. A good number of Product Owners and Business Analysts come into the role from prior experience as business or technical practitioners. For consistency in this article, we will refer to the Product Owner.
The Product Owner in Agile software projects is tasked with being the voice of the customer and the business to the Agile Development team. They prioritize the work item backlogs and help the Agile Development team understand the value of deliverables. This means that the Product Owner is often is situations whereby he or she has to confer with business and development stakeholders as they at times have differing points of view on backlog items.
Often, the hurdle in such situations is communicating in terms that all stakeholders involved can understand and deem valuable to the overall project goals. Take the case of a project whereby during the Backlog Grooming session, it became apparent that the scope of the items being pushed from the business, would far exceed the Agile development team’s capacity to deliver by the planned release date. This required further review of the priority and discussions around the delivery of items that will constitute a successful release.
The Development team flagged items that they deemed to do with optimization, as candidates for a significant scope reduction, in order to meet the release date. The main driver of these items from the business team was reactions to news articles from a competitor’s product having performance or optimization issues.
The first approach by the Development team for scope reduction was deeply technical in nature with references to “throttling the API” to “Profiling the database calls” among other jargon. The business did not find the case compelling enough to de-scope the project.
In further deliberation by the Development team, one of the team members noticed that although the competitor’s product had performance issues, the business did not have a comparable product. It would therefore be better to express that squeezing optimization items into the release, would lead to a delay in product release.
The message this time was in terms of articulating that the proposed scope reduction, will provide a product at the point of usability for revenue generation. The delivery time frame will be much shorter and facilitate adoption of the existing business customer base while capitalizing on the competitor’s disgruntled customers who currently don’t have a comparable substitute. Performance and optimization feedback from product use after the release will then be addressed in a first-in first-out basis by a KANBAN support team. This approach and wording netted a reduction in release scope to the Development team.
The perception of value by all stakeholders in an Agile team can be crucial in negotiating aspects of projects. In the case described in this article, the first approach from the development team did not convey value in terms of how the business perceived value. The second approach was understood by the business and was conveyed in terms that would initiate a compromise that would satisfy the Agile team’s goal.