Just how Agile is Santa?

Santa only knows how to do a “big bang” delivery. At first glance, it’s easy to suggest that Santa isn’t very Agile at all. But the more we inspect his actions leading up to the big day, it’s evident that he’s been reading an Agile blog or two.

We can’t fault Santa for his Just In Time techniques. He only asks for his requirements a few weeks before delivery, giving his millions of stakeholders plenty of time to figure out what their highest priority items are. And they’ll inevitably change frequently.

You might view Santa’s approach to requirements gathering as succinct. Whilst it is true that there is often no clear definition of done and some gathered requirements can be vague (I always used to ask for “some surprises” at the end of my list), it’s great that he takes it upon himself to talk directly to his customers. Many modern implementations of Agile rely on a proxy Product Owner, often meaning that the development team never communicates directly with the business.

Self-organising teams are fundamental within the North Pole workshop. We’re all well aware by now that Santa’s workshop is filled with cross-functional and multi-skilled little elves, all working together and co-located. They’re trusted to do a job and empowered to get things finished in time for delivery; whatever it takes.

I’d like to think that every Boxing Day, Santa, Rudolf and the rest of the team sit down to hold a retrospective. If they didn’t do this, I can’t see how else they could continually adapt to the changes within their industry. Continuous Improvement is key within any Agile implementation and without it, Santa today couldn’t do the same job he did 50 years ago given how different the world around him is (think; more children, more advanced toys to make, less houses with chimneys, etc).

Even if your practices are perfected, industry trends could change things in an instant.

Santa operates in a regular sprint rhythm. Whilst his sprints are long, in 12 month cycles, this routine ensures that not only his team but critically his stakeholders all have clear expectations of when they can expect the next delivery. Setting expectations, and meeting them, is key.

So whilst Santa isn’t the perfect advocate of Agile, there are certainly more good Agile practices involved in his tight operation than initially meets the eye. You could argue that the extensive feedback loop is by design, but try telling that to the child that got some eggnog for Christmas instead of the Xbox that they asked for.

Ultimately; the seeing is the believing. And that’s the true magic of both Christmas and a successful Agile delivery.

Delivering maximum value means being comfortable with unknowns

It’s interesting to observe that a lot of Scrum teams put a heavy focus on what the definition of done should be. A lot of time is spent meticulously ensuring that their customer has thoroughly defined through acceptance criteria what will signify a completed user story.

One element that often gets far less attention than the definition of done, if at all, is the definition of ready. Arguably it carries more importance than defining done because after all, if we don’t know when we should start then we have no chance of knowing when we are finished.

Agreeing as a team what the necessary requirements are before you can comfortably commit to writing your first lines of code is critically important before every project starts. It can be easy, however, to get so caught up on defining what ready means that you start to lose value in what you’re producing. Or worse still, wait and wait for that “perfect moment” to start that you deliver no value at all.

Andy Hiles visualises this perfectly with his graph:

photo1 (11)

Finding the sweet spot is key for maximum value delivery

It reminded me that more often than not, you need to get to a place where you’re comfortable with the unknowns that are ahead rather than try to understand everything before you deem something ready to work on. If your knowledge is too low however, then it’s going to cost a lot for the team to discover the details as they go. Similarly, if you spend too long mitigating the unknowns before you begin, you’ll bleed cost in other ways.

The sweet spot is somewhere in the middle. Know enough to be confident in what you’re about to embark on, but keep some of the decision making for when it needs to be made. Finding a comfortable level of unknowns (and a required base of known knowns) can push creativity and importantly ensure that you’re not waiting too long or wasting valuable time before you start sprinting. A team sat doing nothing is of course delivering no value at all, but comes at a cost all the same.

As a team, it’s important that you find a level of unknowns that you’re all comfortable with – but it is important you find that level and consider any risks that might be associated. For example, if your ideal definition of ready is that a technical specification document is present, but instead you have are solid user stories and technical people who you can ask questions of, ask yourselves if you can deliver value with what you have.

The chances are that you can. The chances are also that if you don’t accept a reasonable level of unknowns, you’ll lose a tremendous amount of potential value along the way.

Continuous delivery shouldn’t just be convenient

One of the many benefits that an Agile approach brings to the table is the concept of continuous delivery. Often overlooked as simply a matter of course when running with an Agile process, the impact that continuous delivery can have in shaping the success of the overall project is huge.

If you’re not familiar with the concept, it’s simple: continuous delivery makes it possible to introduce new development features quickly and reliably by creating, testing and releasing code frequently in small increments.

It feels natural if you’re working in a two-week sprint window to release what you’ve completed at the end of each cycle, but the importance of doing this is much more than just convenience, simply because it’s ready. Continuous delivery not only allows for instant feedback but also empowers stakeholders to make decisions on product direction based on real working software, rather than generalised assumptions.

Stakeholder or user feedback is often a key performance indicator for the success of the project. By releasing functionality piece by piece, you can see quickly whether stakeholders are responding to it. Releasing new features little and often, and building in solid feedback loops, will be a much more effective reporting method than simply using progress charts to establish if the project is on track or not.

Being Agile is all about being able to respond to change quickly. In the IT industry especially, new laws and regulations can be introduced and market trends can come out of nowhere. Continuous delivery allows you to embrace last minute changes, implement them and release them to a live environment without hassle or affecting other elements of the project.

Responding to change and regularly introducing new functionality could give your product or business the competitive edge that is so desperately sought in an often over-crowded and ultra-competitive market space.

The constraints of older Waterfall-led projects meant that mid-project changes had to be handled via often complex change control processes – and even if the change request passed through quickly, the subsequent release could not happen until other developments are completed and tested.

Using Agile and the continuous delivery approach will help ensure that not only is the final product fit for purpose (at the time of delivery, not at the time of initiation), but will also that regular releases keep you ahead of the game and, more importantly, your direct competitors.