The pitfalls of doing Agile versus being Agile
Rebecca Hudson provides her tactics for shifting the needle. She recommends not to simply ‘do’ Agile but to encode Agile into the DNA of your team.
Companies in the UAE and across the Middle East 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 specialists I know that Agile is a tried and tested methodology to help organisations gain valuable benefits such as:
Staying ahead of disruptors and competitors
Increasing innovation and customer value
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.
In the UK I worked as an SAFe 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 a Scrum of Scrums model, and still they don’t have the basics of Agile in place. As such they are failing to realise any of the benefits above.
Organisation don’t need to have undertaken an end-to-end Agile Transformation to adopt an Agile way of working. Agile adoption focuses on the practical, day-to-day tasks involved in a software development life cycle (SDLC).
Agile Transformation is a…
“fundamental change in their work ethics, beliefs, and organisational culture to align and ultimately achieve greater business outcomes.”
Agile Adoption:
The act of a team adopting an agile project management framework such as Scrum, Lean or Kanban
Scaling agile to a pillar, department or discipline within an organisation
Involves very little structural change to the organisation
Agile Transformation:
Transitioning an entire organisation to a nimble, reactive approach based on agile principles
Agile becomes an organisation-wide operating model, not a simply a framework adopted in some parts of the business
Simply put, Agile Transformations take time.
Starting small with a few Agile teams is a great first step — and it’s happening in earnest all over the UAE.
The Middle East has seen a significant increase in digital and agile adoption across various sectors, including finance, retail, healthcare, and education. This growth is driven by factors such as increasing internet penetration, smartphone usage, and a young population that is tech-savvy. Companies in The UAE, Saudi Arabia and across the Middle East must ensure they are adopting agile best practice, to ensure digital transformations are delivered with maximum value.
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 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, it 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.
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. When new people are brought into the team, as may well happen, they should be onboarded with the Team Charter, so they can contribute to its evolution. As with most things in Agile, it should be an evolving document.
Take what you need from the various frameworks, and 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. This is potentially a controversial statement. There are definitely benefits to choosing one approach when a team is new to agile and adopting this approach for the first time. Sticking to Scrum, and implementing it ‘by-the-book’ could be the most sensible course of action in the early stages. Once the team has mastered the new agile framework, then they can start to evolve it.
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, without completing any working software during that, or subsequent sprints. If you work in time-boxed sprint cycles without presenting stakeholders with working software the team are simply working in a waterfall way and calling it agile. 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 acted as facilitator. There were +8 people attending, each person explained what they had been working on that day. And the was it. 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 work people had done, at worst it was a finger pointing exercise which devolved in shouting.
In your Team Charter you should determine your delivery approach and thus the ceremonies you need.
Here are some tips I stick to in order to run successful Agile events 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 time-box
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, Mural, etc
Emphasise respect for your colleagues
Review actions from previous meetings to ensure you are all holding each other accountable to commitments
Review, learn and act on the feedback and actions from previous events / ceremonies, ensure accountability
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.