Some reflections on the path agile is taking to adoption through organisations, drawing on some recent experiences and pain points. When organisations begin exploring agility as a key capability, there is a fairly well trodden path of discovery, until efforts stall and teams begin reverting to old behaviours. Starting with software and digital teams, where the adoption is relatively painless, Agile methodologies bring a breath of fresh air and employees feel empowered. Once the success stories start to appear, the discussion of taking agile into non-tech teams begins – the first brave souls, backed by senior leadership as champions make the leap. At first, progress is great – things seem to move fast when uncoupled from the former ways of working, protected by air cover from above, this new way of working spreads fast. But soon an undercurrent of dissatisfaction starts – was it all too good to be true?
Don’t skimp on the basics
I often see non-tech teams taking time to consider the 4 core values of agile and working hard to make them fit their own circumstances – it isn’t too hard to do, in fact Gartner did a good job of giving us a starting point. But less often do I hear a team co-creating an understanding of how they will embody the 12 principles of agile. These principles cannot be defined elsewhere and handed down without debate about exactly what they will mean to this team, in this context. Why do the principles matter so much for non-tech teams? Because they act as a behaviour guide for when teams reach a crossroads – they help answer difficult questions and help the team push back against senior stakeholders wanting them to cut corners. If you are a non-tech team starting out with agile, here is a great guide to how to get started with your own contextualisation of the agile values and principles regardless of context. The last line of the article echos my own mantra, often repeated to dogmatic scrum masters in the early stages of a project:
“Agile is not a dogma. It’s flexible and focused on value delivery to the customer while embracing change and listening to the customer. Agile is designed to be tailored to the specific context of an environment, culture, and goals.”
Any team embarking on an agile journey of any flavour needs to put this at the heart of their understanding! Values and principles should be your line in the sand – the things you don’t break – everything else is up for grabs IMO.
Agile is not a lone wolf
One of the biggest myths about agile – especially non-tech teams agile approaches – is that it is a recipe for chaos. Little planning, little strategy, just a race to be fastest. Nothing could be further from the truth – the level of rigour you need to run an effective agile team is something that often shocks people new to working this way.
As an isolated methodology, agile is a fun and rewarding way to work. When you start looking a bit further at what makes agile successful for more mature teams in the software development field, you actually find an intertwined set of disciplines that are the real game changers – DevOps and Agile are a powerful duo. As are Agile and Lean. Business agility lacks these running mates – which in some cases means that teams are not considering the ongoing effort needed to move between chaos, complex, complicated, simple (in methodology terms this could look like moving between Lean Startup, Agile, Lean, Automation to achieve the best results). In this instance, I am referring not to the to Stacy matrix that is often used to understand project delivery, but rather to the Cynefin model, for reasons that you can read more about here.
Day-to-day challenges cause drag
Here are some of the most common that I’ve seen – they vary by team depending on the level of knowledge and maturity, the commitment to really change ways of working and how tolerant the surrounding organisation is of the new interloper.
- Too many part-time team members – context-switching its one of the biggest drains on an individual’s productivity, let along a whole team who is switching in and out of different projects. Scheduling time together for true collaborative work becomes harder, the basic ceremonies of agile become an overhead and the team can struggle to make headway.
- Work isn’t truly iterative – often non-tech teams are working on a series of sequential tasks written on cards, to look iterative. This is one of the toughest nuts to crack for a non-tech team. How do you make strategy delivery a truly agile endeavour? How do you ensure you are shipping something usable/valuable each sprint?
- No clear quality standards – when shipping software, the measure of quality can be as simple as reducing the number of bugs in a production launch. But if your shippable products are a strategy document or a data architecture, how will you measure the quality of your work in such subjective circumstances? This is particularly difficult for the Product Owner – of course, first off, there is no product, so what they own is not always clear to everyone. Second, they are the link to the business, which in a non-tech team probably means they are not a specialist. Pairing them with an expert who can coach them in areas of quality, subject matter, service or process design and more technical fields is essential to their early success in role.
- Lack of decent fit-for-purpose tooling – tooling is a tricky subject even for software development teams running agile – it has created some big and somewhat bloated tools, such as Jira or GitHub Project Management, which are too complex for business agile teams. But the lighter tooling of Trello or Microsoft Planner are just blank canvases that require knowledge, practice and experience to configure to work well enough (a great starting place for inspiration is always the template catalogue that Trello offers).
A final read, this time from HBR – have we taken agile too far? The answer is, naturally, yes – a tool of such promise is never kept within the bounds it was intended for. With agility being added to every discipline, in the same way as ‘digital’ was a few years ago, the dilution of values, principles and practices is inevitable as it spreads. But non-tech agile is not too far – it can and does deliver spectacular value to customers when deployed with forethought and care.