I’ve lost count the number of times I’ve been asked by sceptical clients and colleagues about using Agile and Dev Ops methods in software delivery.  This is usually followed by …

“We can’t use that because …”

“That won’t work for us because …”

“Our teams don’t want to change because …”

“Agile doesn’t really work”

… I think you can see a pattern.

In response, I usually find it is best to recount my team’s story of how we were very sceptical of change and happy with our waterfall status quo before we started using Agile and Dev Ops methods, but making the change and giving it a go was when the real fun started.  If you’re sitting comfortably, here goes with our story …

Like most IT Professionals over a certain age with a background of complex legacy public sector traditional waterfall projects that lasted more than 6 months, usually resulting in going over budget whilst running into impossibly tight testing windows where the requirements would change (usually late in the project) and defects were expensive to fix alongside a mounting technical debt, we thought we knew how to do things right.  The project managers blamed everyone, the business analysts blamed the client, the designers and architects blamed the business analysts, the developers blamed the testers.  Just writing that down now makes me embarrassed to admit our arrogance.

In our minds there was nothing that we didn’t know about IT delivery.  With vast experience amongst us all (we once counted the IT experience in our team of 40+ people to be just over 1000 combined years!)  we all thought we knew what we were doing.

Then we were asked to deliver the impossible.  Everyone agreed we needed to do things differently and re-write our well-thumbed rule book.  So we made a plan with timelines and milestones and phases … in other words the same as before.  Then someone suggested that we try Agile.  Terms like scrum, sprint, standup, backlog, Kanban were thrown around and we all sighed, looked around at each other smugly, but agreed to give it a try – under our breathe we secretly thought it would never work.  We reluctantly agreed that as we were going to fail doing this in our legacy way, we might as well try Agile.

We trained scrum masters, set up white boards, agreed with our client who would be our product owners, trained our engineers in some Dev Ops tooling, introduced some automation and then it happened … OUR LIGHTBULB MOMENT.  We managed to achieve the impossible!

Collaboration with the client was seamless and they even integrated themselves into our scrum teams.  Our staff were learning new techniques and ways of working that broke down the barriers between ‘them and us’.  We removed the blame culture between the separate teams as our scrum teams were made up of designers, analysts, developers and testers – we were all in the same (scrum) team now.  All parties were working together with common goals, learning our lessons every sprint and taking ownership of our own areas of delivery whilst at the same time supporting our team wherever we could.  We recognised when we failed, but we failed fast and we failed together – so we fixed it without the need to produce and approve reams of paperwork to get changes agreed (working software over documentation for the Agile Manifesto purists).  We had the client product owner within our scrum teams and we were making decisions when they needed to be made.  Priorities actually made sense for once.

This was a few years ago now and we are still learning each and every day.  We now talk about how “it’s all common sense really and it’s just what we do”.  We have learned to be pragmatic with Agile.  We do what works for each and every project.  Sometimes we lean towards more purist Agile and other times we take what we need from a number of different schools of thought and adapt to fit the work.  The constant feedback loop is crucial to our success so we can learn and improve at every iteration.

We have happy staff – who have amazing relevant digital skills, who receive ongoing mentoring, training and development in Digital, Agile and Dev Ops.  Our team are now highly multi-skilled.

We have happy clients – who feel part of the process and don’t feel like we are trying to sell them something, but are trying to help them fix their business problems through amazing IT.

This has resulted in a very healthy pipeline of work as our reputation has grown and we are leading the way in how to effectively delivery digital solutions as well as a highly engaged workforce who actually enjoy coming to work.

The advice we usually give to our sceptical friends is …

• Start small, maybe with one project – don’t try to boil the ocean.
• Identify a problem and create a one problem statement, so you really understand what you are trying to solve and fix.
• Use Agile techniques appropriate for your delivery – be pragmatic.
• Up-skill and Multi-skill your teams, so they can work effectively.  Give them the autonomy to decide the best in class software and tools to use (unless the client has constraints we can’t move) – give your scrum team members a voice.
• Make the scrum team own their delivery and equip the scrum master to be able to take away the blockers and have leadership who can support the scrum masters and team members.
• Have a good product owner – we define this in it’s basic form as someone who knows stuff and can make a decision.
• Have open, honest and transparent collaboration.  The quicker you acknowledge the problem, the quicker it can be resolved.
• Create an environment of no blame.  If (when) there are failures and mistakes – learn from them and making them a learning opportunity, rather than turn them into an inquest over a failure.
• Willingly and openly give and receive feedback – listen to your teams – who knows better than those who are doing the work?  I can’t emphasise enough – LISTEN TO YOUR TEAMS !!!!

This isn’t an exhaustive list, we have found it works for us and it might bring you a lightbulb moment too.

Photo by rawpixel.com on Pexels.com