An Agile Journey (well Falmouth and back) Part I
Welcome to a short series of blogs reflecting on Agile on the Beach 2021 #AOTB2021 held in Falmouth in early September. Firstly, congratulations to everyone involved in putting on a dynamic and safe event in the current situation. These blogs are very much a personal view and reflection on the sessions I attended at the event, covering all aspects of Agile development.
Bear in mind that whilst my background (a long time ago) is as a developer, these days I am principally a Product Owner, Delivery Manager or Business Analyst working at the interface between business and technology.
From the sessions I attended I have chosen to distil my musings into several topics:
- Velocity & value – are we really measuring the right things?
- No ‘I’ in team? – a continued shift to embracing individuality
- Wagile – pure Agile is (mostly) a Utopian dream
So, with no further ado.
Velocity & Value – part (i)
Each topic is loosely based around the sessions I attended at AOTB. In this first blog I offer some thoughts on how to build a backlog of work – standard fare for any Agile Product Owner and how to deal with estimation of the resultant stories.
In a second follow up blog on this topic I consider whether concentrating on velocity really ensures you are delivering maximum value?
Defining a backlog
A safe choice but my first session on defining a backlog promised some interactivity within the attendees. There were no surprises in using a conversation to build a journey decomposed into many stories. The techniques to get to a shared understanding of scope and priority were standard and colourful with post its moving all over the place.
Especially notable however was the cull of stories and drive to get to a Minimum Viable Product (MVP) defined. I think it was a great lesson that MVP should be an absolute minimum – so you can deliver (or fail) in the fastest possible time. I believe you should even consider getting to something demonstrable that will show the (potential) value in the future even if not immediately deployable in a production scenario. Learn some lessons in the shortest possible time.
In one of the sessions, we learnt one company went as far as deploying a button for a new feature on their website with nothing behind it – deployed vapourware!! All that occurred behind the button was a redirect to a page saying thanks for showing an interest in our future feature. A novel way to gauge customer demand.
There are many advocates pushing the ‘shabby chic’ glamour of building a backlog or story as post its on a whiteboard or wall. I believe this interactive technique is ideal for up-front brainstorming and it is recommended when it is possible to get everybody in the same room. Using tools to allow remote collaboration loses that conversational aspect of building a journey and is much less effective.
I don’t have any answers here but hopefully as the pandemic wanes sufficiently we can get back to onsite interactive workshops. I think it is obvious though that remote working and delivery is here to stay, so some tool support, such as mural boards is a must for the future.
My preference, however, is usually not to start from a blank piece of paper (or wall) but define a high-level journey as a framework for discussion, presented in a low-tech way, such as PowerPoint. For sure it isn’t quite so sexy as other tools and there isn’t the capability for interactivity with the audience but it’s easy to generate and does the job. I do believe swanky tools can detract from the essence of the task at hand, which is generally to have a focussed conversation – too often the technology which is only a means to an end masks the real, required conversation.
Classic Agile thinking suggests that stories are estimated in terms of story points. Each sprint has a maximum number of points that can be delivered, and this limit is used to cream off the next priorities from the top of the backlog. One of the AOTB sessions used planning poker to drive to a consensus on estimates for each story. However, I am not convinced we really gained much through this technique in getting to a better view than an educated guess up front.
What it did emphasise is for estimation techniques to work you need subject matter experts present or at least some one able to clarify and adjudicate on scoping questions. I have tended not to use planning poker, or anything collaborative to generate development estimates. I believe these techniques have a high overhead in bringing in developers when they will probably know little about the subject matter and in my experience are quite reticent or nervous about submitting a view on estimates.
Yes, they would probably learn, but I am not convinced of the added value. My approach is either to rely on experience to estimate yourself and refine later or have a brief conversation with a technical lead or similar on the complexities to drive out a best guess.
One session I attended even went as far as to say that using story points is superfluous and just counting stories is enough. The argument was that even a wide variation in the size of stories does not invalidate planning by story count. I can see the value here in simplifying even further the estimation process, but it just doesn’t feel right.
- Story points give you a measure of complexity. Especially useful as an indicator that a story is too big and should be decomposed or even elevated up the food chain to an Epic.
- I also believe that the size of stories does matter in terms of the requirement to refine/ decompose. Each story ought to be deliverable within a sprint – even if the decomposition is a bit false (but measurable) e.g., design, development, test.
Our sprints tend to be two weeks in length because at one week the ceremonial overhead is too much, and at four weeks the review points are too far apart and changing direction is not so easy. This gives a good benchmark into how far you should go in refining epics/ stories to fit into one sprint before starting development.
I also think there is an element of practice what you preach in terms of estimates in Agile. Don’t be afraid to take a punt on the estimate for a story – have a conversation and refine that estimate if required. In fact, don’t be afraid to change estimates mid sprint as you learn more – both upwards and downwards. This is more akin to a Kanban approach, rather than Scrum, where there is a continuous stream of work and less sprint structure to the delivery. One valuable lesson, keep comments or an audit as estimates change – this is very useful (required) when you want to review things in retros if your estimating is diverging from reality.
Watch this space for the next blog instalment which will consider some of the conflicts and interactions between velocity and value.