I've been doing Agile for years in various organisations, but I still don't feel like we're doing it right?

Question

So in my current organisation for the past year we have been doing the "full-blown" Agile stuff to create software. From planning, refinement, daily SCRUM stand-ups, programming and testing in 2-weekly cycles, through to sprint reviews and even postmortems.

Our software chugs along and we make a reasonable amount of releases. As a dev team we are fairly happy because we go through all our rituals according to our Outlook calendar. Management are generally pretty relaxed because we have many small customers instead of a few large ones (losing one is not a big deal).

However, I feel like the biggest reason for Agile was supposed to be to bridge the divide between developers and management, and also keep customers on the same page - esp. with the Extreme Programming flavour. When my boss asks individual developers when they can expect a feature that is currently being worked on to be released for customers, we are dumbstruck and can't give an answer. We estimated based on effort, not hours - so we intentionally didn't communicate poor estimates to management. We know that our estimates are often incorrect, and we work to improve them. However, we still try to hide behind the guise of not telling management our estimates, as per many recommendations with Agile online and in books. We simply tell them what tasks we think we can fit into a Sprint.

As mentioned, this is all good, until a customer wants to know when it will be done so they can achieve some level of planning for their business. And management want to know because part of their job is to know. Furthermore, management never join our sprint reviews so we never get to talk about this kind of issue.

What are we doing wrong as developers / scrum masters? How do you suggest we could improve this kind of situation and feel more comfortable when the boss asks us an important question?

Answer 1

Providing Estimates

If a properly-sized story, feature, or fix is in-scope for the current iteration, then you can say that it's forecast for delivery by the end of the iteration. If it's a collection of features (e.g. more of a scheduled release or milestone) then you use agile release estimation to provide the answer.

Caveats

There are always caveats. A non-exhaustive list of examples that make agile estimation hard include:

• If your stories or backlog items are improperly sized, and don't fit within a single iteration.
• If your velocity or queue drain rate is wildly unstable then it may be hard to project when future work will be in scope.
• If you've decoupled development from delivery, then it may be rolled out earlier or later than at iteration boundaries. This is often a plus when done right, but it's something to be aware of.
• Treating estimates like money-back guarantees. Estimates (or forecasts, if you prefer) are only as good as the data and analysis that go into them, even in agile frameworks.
• A large cone of uncertainty, vague scope, lack of INVEST criteria, or insufficient domain knowledge. Without mitigations like story spikes or other tools designed to reduce uncertainty, your forecasts are more likely to be missed.

None of these examples mean that you can't provide delivery estimates when using agile frameworks. It just means that you need to ensure that you're leveraging your framework's full suite of estimation techniques, applying them properly, and inspecting-and-adapting in a continuous loop to improve the team's accuracy and reliability to within acceptable norms for the business.

There's no silver bullet. However, the practice of continuous improvement (or "kaizen") will certainly help mitigate the problems you've described.

Answer 2

"Do agile" has several interpretations. Have you gone through the core agile values?

A team that does daily stand ups, do not provide estimates in hours, works over iterations and have constant releases may be adjusting itself into the scrum ceremonies and roles... but forgetting the scrum values. Your project may be what I'm used to call a (fr)Agile project.

So, back to your main question - is my project agile? You can answer this question by answering the following questions:

• Are we valuing people and individuals over processes and tools?
• Are we valuing working software over documentation?
• Are we valuing collaboration over contracts?
• Are we valuing a fluid response to change over being strict to a plan?

If the answers for all four questions above is undoubtedly yes, then your project is very likely to be agile. If you are unsure about any of them, something may be not entirely agile.

Remember: You can consider agile as a tool to deliver value. If your project is agile and is delivering value, then you might redirect your concerns on how you can improve it, rather than if you're doing it or not.