I was recently talking to an Agile Coach who was visiting the Digital Transformation Centre, about how we apply agile techniques to our projects.  I mentioned to him how we were far from being scrum purists, but instead we were quite pragmatic about what techniques and approaches we applied to the different types of deliveries using a common sense approach including …

• Scrum
• Kanban
• Mega Kanban
• Uber Scrum
• Safe
• Nexus
• Scrum of scrums

When I mentioned our Pragmatic approach, he said ”you do realise that Pragmatic Agile is an actual approach”.  Of course I didn’t, I just thought it was us applying common sense and trying to use the best techniques that fitted what we were trying to achieve.

Once back at my deks, the first thing I did was Google Pragmatic Agile and true enough it really was a thing!

There are many definitions of Pragmatic Agile all over the internet, there is even a Pragmatic Agile group – who knew?

Finding The Best Fit

We have such a wide variety of work within our portfolio. All for different clients doing a wide range of activities.

Some of our work is more dynamic where we receive ongoing requests – Kanban fits perfect for this. Using tools like Trello or Microsoft Planner and a good old fashioned white wall and post-it notes.

Our software development or dev ops platforms projects are often better suited to scrum, where we can effectively plan a sprint and manage the backlog at the start of the sprint and have a clear Definition of Ready and Definition of Done. We tend to use Jira or VSTS displayed on the TV screens in each delivery bay as our tool of choice – as well as complementing with the white wall.

Overall governance is covered by our Scrum of Scrums which allows us to have an overall view of what is going on in each stream of work across all of the Centre. We all meet every morning at 9.30 including myself, the Centre delivery lead, all scrum masters and the operations team. This is one of the most valuable half hours of the day. It allows for total transparency across all of the teams. We focus on blockers and try to resolve these by talking and collaborating to find the best solution. More often than not, someone has already experienced the problem before and we can share our knowledge and experience. With this approach we can make decisions on resourcing, technology, approach and often it’s a great opportunity for the scrum masters to bring things to the table that just need talking through. It’s also a good way for everyone to know what visitors we have in the Centre that day and any new work, training or events that are going on.

We have a squad of around 16 Bionix Robotics Process Automation engineers who have within their own teams around 12 projects ongoing at any one time. To handle this they have a Mega Kanban 3 times per week which is similar to the scrum of scrums, but focuses on the many different areas and clients that come to them with their specific RPA and automation problems.

Every 2 months we host an Uber Scrum where I basically cascade and share interesting and useful info to everyone. These sessions allow full openness of two way discussions across everyone in the team and gives anyone an opportunity to raise any questions, bring some ideas out on the table and feel part of something bigger than their own scrum teams or squads.

Industrialisation – sounds very serious!

One of our latest apps to cloud transformation projects is going to be large scale using 3 scrum teams in the UK over 2 locations and up to 10 teams offshore in India. We need to make this seamless and consistent and are currently looking at the best scalable agile fit with either Safe or Nexus. We have had a similar scale project previously where we took (again) a common sense approach and took elements from different methodologies that worked for us. It is going to be interesting how this works out!

I do have concerns over Safe Agile as this brings back some of the layers and processes that look to be more waterfall than our current pragmatic approach to agile, but I understand with work of a certain size we need some level of governance and oversight. Watch this space!

Manifesto

If we look back to the reason why Agile methods were first introduced, the Manifesto fir Agile deliveries (to me) is very much in keeping with a pragmatic and common sense approach…

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Whatever approach to Agile is being used you must always review the approach regularly, for example as part of the regular delivery retrospective ceremonies or a specific approach retrospective to learn from what you have been doing and ask yourselves …

• What went well?
• What didn’t go very well?
• What can you do better?
• Any ideas for improvements?

Agile Guilding

Within the Centre our scrum masters have a self managing guild where they can share experiences, train each other, provide coaching and mentoring and most importantly give a safe place where they can collectively solve problems.

Anyone can take a problem to a guild and with the collective experience and ideas from the scrum masters they can help solve a multitude of problems including approach, agile tooling, metrics, resourcing, in fact anything that needs some attention and thought.

In summary, don’t get too bogged down by only being a scrum purist. Figure out what works based on your experience and knowledge for the different projects. Not everything fits into one box. That’s not to say you need to cherry pick or have a miss match for each piece of work, but don’t be afraid to make change and do things better. Constantly learn and improve !