Recently I’ve been helping out a friend with some questions about how he and his team can deliver value more quickly in his organisation, which works with a traditional SDLC.
He describes the process as “pretty much solid waterfall” and finds it hard to see how Agile methodologies would allow them to deliver benefit early. Most of their projects are, as he describes it, like an “iceberg”, with huge amounts of data integration and enrichment invisible below the surface before the internal customer finally sees the “tip” with a report or a dashboard/OLAP cube.
The requirements are fixed, and the customer is not interested in seeing partially finished solutions. They want it ALL, or it is not deemed valuable to them.
My friend envisages delivering multiple sprints with the customer getting decidedly impatient because they still can’t see anything useful. And then eventually in one of the later sprints the customer finally gets their dashboard. This doesn’t really solve their problem.
He is also interested in the #NoEstimates debate as the team seems to spend a lot of time estimating effort and, other than the estimates being used to raise a purchase order, the process doesn’t really make any sense to him. He wants to consider alternatives that can be used to give some scale to a project and enable the customer to raise the purchase order to get the work authorised. He wonders if this might be difficult to implement as the organisation is so cost (money) focused, but he at least wants to be able to float a few ideas.
He says there was a request from upper management for the delivery team to be more “agile” but, given the lack of desire for iterative/incremental delivery from anyone outside the team, this request seems to infer the old classic “we want our team to be agile” meaning “we want our team to deliver more quickly but don’t want to bother ourselves with sprint reviews every 2 weeks to give feedback on what they’re building“.
I explained to my friend that these kinds of cultural issues are not easily or quickly resolved. It sounds cliche but Agile transitions are a journey and require a buy-in across the organisation that things need to change, and a willingness to be open to do this. I told him that he will find himself in a frustrating bind if he tries to take a bottom-up approach to agility. Those that are failing to see the value in an early and iterative approach to the delivery of features are the ones that need to understand the benefits before any lasting improvements to effectiveness can be made.
This feeds into estimation too. If he can’t work iteratively, delivering in small chunks, he can’t really empirically measure progress toward the goal, leaving him with no choice but to be predictive and deterministic. If he can’t measure progress it’s difficult to judge if he’s “on track”, and will find himself continually estimating remaining work in order to update the project’s status.
So what can my friend do in this situation?
One thing he can do is to try and continuously deliver vertical slices regardless of whether the customer is interested or not. Put the system into a production-like demo environment. If the customer doesn’t want to look at it, no worries. It will at least allow the development team to iterate in their thinking over the design of the solution, and to measure their progress against a T-shirt sized backlog of work.
Something along the lines of:
- Here’s the backlog of work that needs to be done (try to make this goal-based rather than solution-based; solution can be agreed Just-In-Time)
- If absolutely required to approve the purchase order before the work starts, give an up-front estimate range based on how long other similar projects took and Maynard Keynes’ premise “it’s better to be roughly right than precisely wrong“
- Split “stories” into S, M, L and XL by comparing each to one another (relative sizing) rather than trying to determine how long something will take, i.e. “A seems bigger than B, C even bigger, D is about the same as C“, etc.
- Build one story from each size bucket (while delivering vertical slices if possible) to start building empirical data about how long stories within each bucket might take; from this a predicted end date can be extrapolated
- Put every new story that emerges into one of the size buckets by comparing it to a story that has not yet been built
- The “not yet been built” bit is important so that estimators don’t get influenced by how long a particular story took
- There will be natural variation around how long things will take, so to reap the benefits of relative sizing and empirical process control it is important not to judge the size of a task based on the result of a statistical outlier
- I wrote a blog post about this recently
- The more stories that are delivered the better the data will become – it will take several stories before a settled delivery rate and thinner cone of uncertainty is achieved
- Be transparent; Update the data and the stakeholders regularly, and warn early if the data is showing a high risk of not delivering within the allocated budget so that the appropriate steps can be taken and there are no surprises late in the game
I’ve written previously about the “barriers to entry” for working with #NoEstimates, and my friend is certainly encountering some of these barriers. However, there are always steps we can take to improve the way we do things, and sometimes these improvements influence others in a positive way.
It’s easy to just accept the perception that “they don’t want to change“, but mindful action in baby steps toward better can make a huge difference.