Many organisations struggle because the developers “live” in an agile world but management want a due data on a fixed specification.
The stakeholder often known as Product managers is often the bridge to management and the key stakeholders. The main focus from stakeholders is to deliver it as fast as possible and as quick as possible to the lowest possible cost and at the highest possible quality.
The bridge between management and development team is the Product Owner, in some companies the same person as the Product Manager but in a different role. The Product Owner focuses mostly at decoding the requirements from the stakeholders to ensure the development team is building the right thing that the company needs. The main challenge here is to understand and set the expectations and ensure that the delivery dates are reasonable and reachable. One of the main tasks for a Product Owner is to split up the specification up into user stories. A user story shall never be bigger than it is possible to estimate within a given period of time, like 1 week.
One of the most important tasks here is to be able to say NO, for task that are not possible to resolve within the expectations.
The development team mainly focus on solving the requirements given from the Product Owner in a prioritized order. The Scrum Master must ensure estimations and that correct resources are assigned to the team. This often lead to a close communication between the resource management, department managers and Product Owners. The main focus for the development team is to ensure we build the product the right way to avoid maintenance problems. The new components shall fit into the existing architecture , and if needed the existing software be refactored to ensure quality. A core part of the Development team shall be QA and test management. From the very first day the Test Developers shall be included to start create test scenarios, test structures and facilitate test from the very first line of software is written. The key to success here is really automated test, in this way the tests can be run automatically on every build and ensure that every build is testable and potentially shipped if needed.
To ensure that the expectations are met, estimations are crucial and that’s often the main factor for delays. Lack of good methods for estimations is often leading to a guess on delivery date. Estimates are often difficult to do since the Product Manager want a specific date for the delivery and developers are afraid that it is used against them. It is therefore important to use methods like Poker Planning or T-shirt sizes to describe the size of the solution before any detailed estimations can be done.
My experience from estimations is this often speed up the development because it forces everyone to keep the original detailed specification on a user story level. But in the agile mindset we shall be able to deliver what the customer needs, and changes are welcome, but then we just estimate again. Scope creep are then often avoided and often a basic design is needed to set an estimate. In this way the project become more predictable and reliable.
If you don’t talk about and handle risk the project will seldom succeed.
During estimation it is crucial to talk about risk and even if the developers are not the ones that shall interfere if this is the correct product for the company, it should be allowed to ask clarified from Product Manager / Product Owner. In this way everyone are more engaged to make the suggested product.
Below i have created a drawing to illustrate the flow of ideas->solutions that describes how new ideas and projects should flow through an organisation.
It does not help to push to many tasks to the team since the team can only resolve a certain amount of tasks at the same time. Be sure that the team do the right tasks at the right time is crucial.