Delivering Value

It’s fundamental to Agile! The first of the Manifesto’s principles is “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”; Modern Agile has four principles, which includes “Deliver Value Continuously”; Heart of Agile says “Deliver small probes initially to learn how the world really works. Expand deliveries as you learn to predict and influence outcomes”.

So who defines what’s valuable? I expect it would usually be your customer (conveyed by the Product Owner) but identifying them can be tricky. Not everything in the product backlog is destined for an end-user; you could be building internal tools (then your customer could be other dev teams) or for yourself. The key thing is identifying what “value” means – this helps the team understand why the work is important as well as where they’re heading. User stories should focus on the “why”, the goals and benefits.

Once the goals are clear, how does a team deliver value? Incrementally, getting frequent feedback to allow them to make adjustments towards meeting the customers’ needs. I like Heart of Agile’s additional mention of “small probes” – taking small steps at first, as you discover more about the goals, technology, etc. As the team become more confident they may want to take larger steps but, in my experience, even when you’re “100% sure” what to build next there’s always a surprise in store. It’s like gambling: don’t risk more than you’re willing to lose – don’t build more than you’re willing to throw away once you get feedback.

Happy Birthday Agile

It’s twenty years since the Agile Manifesto was created in Snowbird, Utah. There’s obviously been lots of people posting about whether it’s still relevant, whether it should be revised, and so on, but I think it’s still important and applicable.

It starts with: “We are uncovering better ways of developing software by doing it and helping others do it.
It doesn’t claim to be definitive; “We are uncovering” means we still have room to learn and improve how we do this. There are many “flavours” of agile, including Heart of Agile and Modern Agile, and some organisations develop their own take on agile (but “hybrid” agile-waterfall monstrosities don’t count in my book).

The next few lines (i.e. the rest of the manifesto) seem to be problematic for some people because they don’t fully understand “we value the items on the left more” – the manifesto’s authors even spell it out by saying “while there is value in the items on the right” and yet some people still think “Agile means we don’t do documentation”.

The first of these, “we have come to value: Individuals and interactions over processes and tools” is one I’ve see many organisations fail to grasp. It’s a long-running joke in the community that “installing Jira” equals “adopting agile”. I’ll refrain from ranting about Jira because the point is that any tool is not the way to become agile – it’s about people. I remember another coach saying “If a company doesn’t understand that it’s all about people then they don’t deserve agile”! 🙂

The next line, “we have come to value: Working software over comprehensive documentation“, is the one I see people misunderstand most – I wonder if that’s because so many people hate writing documentation? If you think about the two extremes, neither is ideal: documentation without software is clearly not a useful product, but also software with no documentation is rarely desirable (a simple tool with no user interaction might just about be ok, but even then anyone trying to fix/enhance the code is likely to benefit from some docs). That’s why we value working software more than documentation but not instead of.

I think the third line is easier to appreciate if you’ve ever worked on a waterfall project where we’re expected to blindly follow the documented specifications and hit deadlines, even if it means delivering something we know to be wrong. By valuing “Customer collaboration over contract negotiation” it means we would rather work with our customer, e.g. show them demos (or better yet give them something they can use) and get feedback early and often. If you don’t work with your customer and respect them, then how can you expect to keep them as a customer? (Ignoring monopolies/cartels, obviously; add banks to the list of rants I’m avoiding in this post!)

The final line, “Responding to change over following a plan” is closely linked with the previous one – in an ever-changing environment like software development there is always going to be change, whether that’s feedback from the customer “course-correcting” the direction of the product, or how the team works together (e.g. coming out of a retrospective), or the tools/technology that we’re working with. To ignore those changes is to say that we can’t learn anything during a project; I can’t think of a single instance where that’s been true, even working on tightly constrained legislation/standards-based projects – there’s always something discovered along the way. However, just like documentation, that doesn’t mean we work without plans – we need to understand where we’re heading and how we think we can get there… but we also need to revise the plan when things change. We need a roadmap (i.e. a destination and options for getting there) rather than a single route set in stone … but that feels like a future post 🙂

Coaching backlog

One challenge as a coach is deciding where to spend your time – do I help team A or team B or split my time between them? If I had the capacity to give both the attention they need then it’s not a problem but of course there’s never enough time to go round. Like so many things, it comes down to prioritisation… but what goes in the backlog? Personally, I tend to think in terms of experiments, e.g. will smaller stories improve the team’s ability to respond to changes in direction?

(I should add that when I say “team” I’m actually thinking about the people in the dev team, the other people they work with, the stakeholders, and the system which encompasses them.)

But who creates the backlog items? Obviously, there are things which come up in conversations with the team members and stakeholders, but there’s also observations and comparisons between the current system and a potential “next level”. Now, we all know there aren’t actually “levels” but there are things we tend to observe in high performing teams compared to relatively new teams. I’m not going to touch on “assessments” here – I’ll save that for a future post.

In order to share this backlog with the coaching stakeholders (which includes the team) rather than a simple backlog of Stories, something like a POPCORN board can help support the conversations around which experiments to try and what the outcomes were. POPCORN is a backronym for: Problems & observations; Options; Possible experiments; Commitments; Ongoing; Review; Next – you can watch Claudio Perrone, aka Agile Sensei, present POPCORN at Agile Testing Days 2017.

Big changes, little changes

Some recent conversations have included questions around whether small changes or large changes are “better”. Unsurprisingly my answer was “it depends” 🙂

Even though our goal might be to achieve a big change, I would recommend making a series of small changes to get there because we might learn all sorts of things along the way, including whether we’re actually going in the desired direction (it’s possible our small change has taken us down a side road) and whether the goal is still the goal.

OK, but what kind of changes does this apply to? All, I think. For example, if the aim is to change the users’ experience by adding a new feature (that sounds like a big change) we would usually break it down into epics and stories, and maybe think about multiple releases … but we probably want to start with some experiments to see if we’re building something the users want, i.e. get feedback early. So the large change is broken into smaller changes (releases, epics) and then into even smaller changes (stories, experiments).

But how does the team learn to do this decomposition? Well, learning a new skill can be a big change, so let’s break it down into small changes too. There are different techniques, so pick one, learn it (e.g. read about it, watch a video) and practice – ideally this includes getting feedback from someone with experience of the technique.

This principle can also be applied to coding: small, frequent check-ins make it easier to spot problems – when a test fails you’re only looking through a few lines of code, not pages and pages. It also reduces the chance of merge conflicts because there’s less time between pull and commit, which means a lower probability of someone else changing the file you’re working on.

So, back to the original question: are small changes or large changes are “better”? Well, I think the answer is small changes are what enable you to make large changes, so it depends on whether you’re looking at the end goal or how you’re going to achieve it.

[Here’s the video of the domino chain reaction]