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.

Duplication is not efficient – don’t encourage it

In the digital world that we live and work within, I find it interesting how some project management approaches are still encouraging the frequent use of pen and paper to capture requirements and track progress. Even Agile, a methodology which I adore and evangelize prefers this, but I’m far from convinced.

My biggest concern with this approach is duplication. The time spent to physically write requirements or tasks onto an index card is largely wasted as it will need to be reproduced within a software tool also. Having a physical sprint board hanging on the wall with the user stories attached may give a nice visual representation of progress – but for the team only. Again, this data will need to be reproduced digitally and, critically, updated frequently as stories move back and forth, get reassigned or closed.

From experience (and I appreciate that I’m generalising a little), a developer wants only to log into their task system, work on and complete a task that is assigned to them before closing it off or reassigning. The suggestion that getting up from your desk and physically moving a card from “in progress” to “done” is a little too idealistic for me to digest. 

It’s a novelty which will wear off quickly.

It isn’t just for requirements or user stories either. Considering that our tablets, laptops and mobile phones all talk to each other and share the same data, why make meeting notes in a notepad when you could make them digitally once and have access to them wherever you are. Distributing typed notes and actions from your iPad immediately after the meeting has concluded is efficient. Taking time to decipher your written notes, re-word and eventually get into the hands of those who need to see them is not. And that’s assuming you can find your notepad and single copy of your data.

I’m labouring a point – but it is true. Duplication is not efficient.

I’m not blindsided or stubborn enough to notice that there are some benefits to working with physical materials. Collaboration could be considered easier when sat around a table moving index cards around, for example. In addition, if your project team is working on internal development and does not require separate reporting (or in other words, your stakeholders are based in the same location and can visually see the sprint board) then duplication is minimal and it might work for you.

Weighing everything up, my point still stands. Digital companies spend a lot of time investing in automation and limiting duplication of work for one single reason – to increase efficiency. Why then, would you add a project management layer on top of this which forces keeping two different systems in sync and updated. Change something on a physical user story card also means tracking it down within the system and updating it digitally also.

If you can remove an hour’s worth of work from a Project Manager or Scrum Master’s daily schedule by avoiding the need to duplicate data, that is surely a worthwhile consideration for any sensible structure.

Agile is becoming the norm – coach it but don’t force it

In the last decade, we’ve seen many changes around the attitude towards the adoption of Agile as the default project management methodology when it comes to delivering software development projects. The Agile framework has gone from the untrusted, untested new kid on the block to the established veteran that the majority of modern development houses are adopting to deliver their software.

We’ve seen a huge shift in not only the way in which we tackle project management from a supplier point of view, but also the attitude towards Agile from clients. It goes deeper than that – in the past, the project management process used to deliver a project was just something that went on in the background. The client didn’t really care themselves with how something was delivered as long as they were supplied with an end product eventually.

When adopting an Agile framework, it should be treated as a selling point – a key ingredient in why your project is going to be a success. Gone are the days of the black box where requirements went in and a product came out – in the modern era, collaboration is key and it should be something that both sides of a project team should absolutely thrive upon.

As a company, you could have the best process in the world but if your client does not want to work this way then there is little point in trying to force them into it, or you’re just going to damage your relationship. Educating or coaching them on the process benefits however is something that should be encouraged, being careful not to undermine their current preferred way of working. In time, any of their concerns with Agile will be alleviated through careful coaching.

As Agile has become more known in the industry (at least, clients know enough about Agile to think that they want to use it), these barriers and uncertainty levels are starting to disappear. Agile, when implemented correctly, is every bit as professional and governed as the more traditional Waterfall or PRINCE2 approaches, and companies are starting to see this.

The proof, they say, is in the pudding. And if you’ve managed to work with a willing client on an Agile project, any remaining doubts are normally erased once the first sprint demo has been completed and the client can physically see what the project team has been working on. Project metrics still remain a critical element of tracking project success, but for many people there is no better metric than something tangible that you can see and interact with yourself.

This is now the way of thinking from a client perspective. Not only do they now have requirements in what they want delivered, but how they want it delivered is starting to become a factor. As more and more Agile success stories roll in, everyone wants a piece of the action. It’s our job, as project managers, as coaches, as anyone involved in software delivery, to embrace this, coach it and use it as another key reason for doing business.