In Part One of this series of my research project findings, I presented a new way to use an old model, McKinsey 7S, to evaluate the success of agile methods in organisations. I showed that organisations are still mainly concerned with ‘processes and tools’ instead of ‘individuals and interactions’ (from the Manifesto for Agile Software Development). Organisations that failed at delivering frequent releases of high quality had an unbalanced approach to transforming their organisations, ignoring the softer aspects of culture such as leadership style and shared values.
Welcome to Part 2 of the series presenting one of the most important findings of the study: when the team understood its organisation’s business strategy, typically by having an engaged Product Owner, the team learned how to prioritise work better and deliver the right products and services.
In my work with agile teams and leaders of organisations improving their use of agile methods, the pain point that I hear again and agin is that they want more engaged Product Owners. The common complaint is ‘they don’t see the reason for a dedicated resource to be embedded in each team.’ And yet, when the agile delivery team does manage to find someone who knows the business vision for the product or service under development, and has the time and willingness to be present for the rest of the team, the benefits are obvious.
The benefits became apparent in my research study, accepted this year by Henley Business School as part of the MSc in Coaching and Behavioural Change.
One research participant described his organisation’s CIO who communicated clearly the whole organisation’s focus — safety. The team’s representative, interviewed for this study, said:
The top one for [us] is always safety. It’s pumped into everyone, you must be safe. So if we see an idea for an app that we know is not safe, that gets kicked out straight away.
As a result, the development team can move quickly and focuses its efforts on the ideas that align to the organisation’s strategic objectives. The organisation, which must remain anonymous, has won industry awards for its innovative mobile apps. By the way, the same team also reported high instances of learning from trial-and-error.
To an extent, I feel foolish writing this because it sounds like common sense, right?
And yet I hear stories all the time of organisations that have separate organisations-within-the-organisation that behave as if completely separate. An us-versus-them mindset pervades and is evident in the language used and level of empowerment given to development teams.
A team representative in another organisation in my study described how he changed people’s mindset to create a balance between the team’s independence from and accountability to business stakeholders:
What I’ve been trying to do since I got there was to break the bureaucracy and chain of commands. To get the team to be completely independent, and at the same time answerable to the business.
So what’s keeping you from closing the culture gap between business and IT, and what could you gain by mending relationships? Get in touch to find out how to develop teams and leadership behaviours to meet the challenges of the future with confidence.
Expect a higher standard of coaching for your agile product development teams. We value ‘individuals and interactions over processes and tools’ and, unlike many agile coaches, have the professional coaching skills to help you turn that vision into reality. Our services can be customised and blended to get the right mix for your organisation, backed by decades of experience of transforming organisations and supporting leaders through change.