We are now living in a post-agile world. Gone are the days of not committing to dates and using story points to size up work. They may have been useful in the past, but stakeholders aren’t buying it. They want to know if you understand the problem, have identified risks and can commit to a reasonable date that the feature will be in the hands of customers. The world is moving too fast for any delays in communication, and trust between product teams and stakeholders needs to be repaired, and quickly!
by Mark McKee and David Wilks, 17th February 2025
Today we see the world very differently from when the Agile Manifesto was published in 2001:
- Most storage and computing power are in the cloud
- Online and mobile payments are the norm
- Open-source tech has changed the world
- We expect new features in a hearbeat
Engineers are expected to own delivery, understand the problem and manage quality and performance. If your feature is not being used by a customer, it has no value!
Where does this leave us?
Agile has lost credibility, despite great intentions: do we really want to pay for ceremonies and let dev teams control budgets?
Stakeholders do not understand story points or why people can’t commit to a delivery dates.
Why should you need to learn Jira: you just want to know when clients will get their features!
So, what’s the upshot?
We can move forward with collaborative teams with these lead people making it all fit together:
- Product Manager: determines value and viability of potential solutions
- Product Designer fixes usability and client adoption
- Engineering Lead gets the job done with available time, skills and tech
Above all else, the team needs to know what problem is being solved.
As it turns out, we need requirements documents – at least something that helps capture scope, use-cases and non-functional aspects – so the team can produce a solution design:
- This involves the WHOLE team so they get enough information to estimate well
- The need to prototype to validate assumptions and refine estimates
- They can still be showing progress demos, keeping an eye on committed delivery date
- RAID items are being owned and resolved
- Epics and stories capture specific details but should point to the wider context of a requirement document that everyone knows and has agreed to
How this looks in practice
- Anyone in the product team can succinctly explain what problem is being solved and for whom
- Story owners manage delivery, quality, performance and impacts on other parts of the system
- Any risk, assumption, issue or dependency per feature has an owner and a resolution date
- ETAs are based on all known information: they can change, but we must be transparent as to why
- Dark work is not tolerated as this will derail commitments
We still need a product backlog that is prioritised:
- To determine RoI, be honest about sunk costs of each feature
- Based on RoI, force rank the product backlog
- If a new business opportunity comes along that will improve the customers’ lives more than other features, then reprioritise!
Ask ourselves these questions every day:
- What problem are we solving?
- What is the net $benefit of solving the problem?
- Do we understand all the risks?
- Do we have the skills to deliver?
When it comes to producing an ETA that a team can commit to you are entering post-agile
Product teams need to assess FOUR Risks:
- Value risk: will the customer choose to adopt and use our solution?
- Viability risk: will what we deliver work for our business in terms of marketing, sales, compliance, funding?
- Usability risk: can our clients and users get to grips with the solution and get the value it brings?
- Feasibility risk: can we as a firm build this solution so we can support it, scale and manage non-functional aspects such as performance and responsiveness with the skills, tools and data we have?
In summary, if you are don’t understand the problem, value proposition, and risks to generate clear prioritisation, then it is hard to gain credibility with stakeholders and gain happy customers. If you really understand the customer’s problem and assessed the risks, then you should be able to commit to a production date. If you are releasing changes weekly or, at worst, every two weeks, then you are reducing risk and moving forward at the pace of post-agile!
Want to find out how this has worked for clients? Talk to us and find out more.
199 total views, 1 views today