Global

The pitfalls of doing Agile versus being Agile

Jun 25, 2021

Share

Rebecca Hudson, Executive Delivery Director of Monstarlab UAE and founder of AgileUAE, provides her tactics for shifting the needle. She recommends not to simply ‘do’ Agile but encode Agile into the DNA of your team.

Companies in the UAE are hungry for transformation across their digital ecosystems.  From improving their online presence through powerful personalisation and marketing tools, such as Sitecore Experience Platform™.  Or transitioning nascent back office systems to embrace automation and paperless processing.

Many already have scrum teams in place in-house, or work with partners on Agile software development.  As a digital delivery specialist I know that Agile is a tried and tested methodology to help organisations gain valuable benefits:

  • Staying ahead of disruptors and competitors
  • Increasing quality and speed
  • Reducing cost
  • Staying ahead of new technologies
  • Increasing customer satisfaction
  • Improving employee engagement and attracting talent

However, there is a significant point of failure I see time and again, which is about the perception that an organisation is Agile, when the reality is that they are ‘doing’ Agile but not truly being Agile.

Back in the UK I worked as an Agile Coach for a multinational credit risk organisation, helping them as they rolled out a SAFe model to scale their Agile ways of working. One day a VP rather derisively told me it was all just a re-badging exercise.  On reflection, I feel he may have had a point.

I’ve seen companies set up Guilds and Agile Release Trains, re-title job roles, have enough scrum teams in place to justify Scrum of Scrums meetings, and still not have the basics in place to hit one or more of the key benefits of Agile.

Organisation don’t have to have undergone a full Agile Transformation to adopt an Agile way of working.  Agile adoption focuses on the practical tasks. As quoted in Kanbanize,

“embracing the new ways, the allocation of time and resources for hiring trained people or using the right tools.”

Agile Transformation is a “fundamental change in their work ethics, beliefs, and organisational culture to align and ultimately achieve greater business outcomes.”

Simply put, Agile Transformations take time.

So starting small with a few Agile teams is a great first step – and it’s happening in earnest all over the UAE.

However, the key to success and ultimately scaling and transforming the organisation, is getting the basics right.  That is being Agile, and not simply ‘doing’ Agile.

At the heart of this are two key factors – best practice and flexibility. 

Here are some pointers for Agile teams in order to avoid rigidly sticking to a prescribed way of working deemed as ‘Agile’, without focusing on driving value through a practical, best practice approach to Agile.

Stage 1 – Creating some ‘North Stars’ or guiding principles

For example:

VALUE – We prioritise features by the value they bring to real users.

TEAMWORK – We build our delivery approach around Teams not individuals, how we work together should be clearly defined and bought into by everyone.

QUALITY – We strive for the highest quality, QA doesn’t come at the end of development, but happens throughout, and is the responsibility of everyone in the team.

SUCCESS – We define what success looks like and ensure it is measurable, metrics should be clear and easily trackable.

Stage 2 – Retro your ways of working

Hold a retrospective on your ways of working.  Breakdown the key phases in your delivery lifecycle, discuss key practices and review them against agile best practices.

No alt text provided for this image

A Stop-Start-Continue exercise can be a useful jumping off point, and gets the whole team involved.  Below are some prime examples of things to avoid and things to adopt, which can be useful for this exercise:

Set up for success 

Teams thrown together to work on a project without the chance for proper onboarding rarely lead to a truly empowered, motivated or collaborative team dynamic. At the bare minimum, a Team Charter should be undertaken, and when new people are brought into the team, as may well happen, they should be onboarded with the Team Charter, and be able to contribute to evolving it. As with most things in Agile, it should be an evolving document.

Take what you need from the various frameworks, create your own approach  

One size does not fit all. Agile teams should use the tools and techniques from Scrum, Kanban, XP, Lean, etc, to create an approach that best fits their needs. Working in a digital consultancy, our approach flexes around internal and external factors such as:

  • Type of commercial engagement
  • Type of product / service being undertaken
  • Client’s requirements and objectives
  • Lifecycle of product / service
  • Digital maturity of the client
  • Region in which our client operates
  • Size and scale of the project
  • Type of skill sets / service pillars needed to execute deliverables

Agile is focused on getting early feedback and responding to that feedback  

We see teams falling into the trap of working in two-week sprints, but not completing a feature which can be demoed to stakeholders by the end of that sprint. If you work in time-boxed sprint cycles but don’t present anything to a client for feedback, don’t QA or do user testing sprint after sprint – you’re effectively doing waterfall by another name. This can happen when Work in Progress limits are not set, when the Definition of Ready or Done is unclear, or when the Product Backlog is not suitably prioritised.

Running Agile ceremonies without understanding the purpose

I’ve worked in a large organisation having daily stand-ups that were 30 minutes long, no one person facilitating, with eight plus people attending, each person was directed to say what they had been working on that day, and that was it. Especially over Zoom it was a nightmare, either dead air or everyone talking over each other. With no real focus to the conversation, at best it would be a vague meandering on various topics, at worst it was a finger pointing exercise.

In your Team Charter you should determine your delivery approach and thus the ceremonies you need. If you are using Sprint / Scrum Ceremonies, here’s a helpful article from The Digital Project Manager.

Here are some tips I stick to for running successful Agile ceremonies with my teams:

  • Plan meetings / workshops as far in advance as possible
  • Ensure you create an environment where everyone is comfortable contributing
  • Emphasise the importance of the session as part of the project work
  • Set clear agendas and timebox
  • Provide easily accessible notes
  • Meet in the same time slot as much as possible, to minimise disruption or confusion
  • Utilise the tools you have, such as the Kanban board, Miro, etc
  • Emphasise respect for your colleagues
  • Review actions from previous meetings to ensure you are all holding each other accountable to commitments

Stage 3 – It’s a mindset 

Adopting best practice and evolving your approach won’t happen overnight, so keep checking in on it.  Nurture and support your Agile teams to get to the point where Agile is encoded into the DNA of what you do.

It should become the norm, not simply a set of exercises and meetings, but a mindset.

There are a lot of articles out there about being not just doing Agile, as it is a perennial problem.  If you’ve found my take on this useful, please connect at AgileUAE, where I’m working with the region’s Agile Delivery experts to create a community for knowledge sharing and connection.

Latest Expert Insights View all

In order to improve this website, we use cookies. For more information please read our Terms of Service. To agree with the use of cookies on this website, please click the ‘Continue’ button.