In our work helping organisations to deliver successful Agile programmes we have encountered several Agile myths that prevent firms from reaping the rewards that Agile frameworks can offer. Expertly deployed Agile frameworks enable firms to thrive through achieving customer delight.
Amongst failing Agile programmes, these are some of the most common myths we hear, falling into 3 interconnected categories of Leadership, Product Ownership and Delivery.
Agile Leadership
Myth #1 Leaders can be passive
Agile leaders are repeatedly counselled on the merits of decentralised leadership and empowered, self- organising teams. This advice can result in leaders taking their hands off the wheel, inadvertently becoming disconnected and absent from their teams. Teams need continued leadership and support, and leaders need to stay active, setting direction, monitoring progress and supporting as they are needed.
Capable Agile leaders remain fully accountable for both organisational progress as well as project/programme performance, and must remain close enough to manage both well.
Myth #2 Managers are obsolete
As an extension of the above misunderstanding, new organisations and teams sometimes believe managers and management are no longer necessary. This is usually because new Agile managers are not given the right tools and approaches to understand how their roles have changed in an Agile world and what new behaviours are required to allow both themselves and their teams to thrive. So managers continue to execute antiquated command and control practices, working hard to micro-manage and control what they can, eliminating the autonomy that good teams need to excel.
Agile management practices enable managers to detach from micromanaging the day to delivery. By building competent teams that are skilled in delivery, Agile managers instead focus on removing impediments to their teams momentum. Managers become allies in delivery and eliminating organisational friction.
Myth #3 Agile has no governance
As many Agile transformations shun good management and seldom provide solid guidance for senior leadership, governance tends to fall by the wayside. Consequently, leaders find it extremely difficult to determine progress. Even worse, without a channel to access leaders, teams can find it nearly impossible to be transparent around the challenges that impede their progress and where they may need help.
We show our clients how to build and maintain lightweight governance practices, appropriate reporting and remain in consistent conversations with teams. This approach enables leaders to keep abreast of challenges and keeps the channel open and available for coaching, training and organisational improvement. Teams are not left to fend for themselves but remain connected and supported by leadership.
Product Ownership
Myth #4 Agile is about successful project delivery
A lot of firms still focus on successful project delivery to the exclusion of everything else. And delivering a project within budget, time, cost and quality sounds ideal – however neglecting customer value can mean that no one wants what has been produced. Firms need to be thinking about customer value over projects. Product thinking starts with the customer and works backwards to delivery. Successful firms ensure that they deliver valuable outcomes that are balanced by ROI. Don’t be the firm that spent millions building a product that no one buys.
Myth #5 Agile means no planning
This is probably one of the most insidious myths out there. The truth is that Agile frameworks recognise that static plans don’t stand the test of time. Doggedly sticking to an antiquated plan never works. Instead, Agile frameworks stress continuous planning and proactive risk management. Product thinking is about generating product roadmaps and strategy (coherent plans) that deliver valuable milestones – the idea is to consistently create and deliver good ROI for both customers and the organisation; this doesn’t randomly happen, delivery needs to follow well thought through dynamic plans. Solid Agile leaders, Product Owners and teams plan well whilst proactively managing risk along the way.
Myth #6 Product Owners write requirements and ensure utilisation.
Product Owners are sometimes forced into becoming story scribes, where 90% of their time gets sucked into endless requirement writing. To make it worse, Product Owners are sometimes forced to stuff the Product Roadmap and subsequent Sprints with work that keeps the team fully utilised. Good Product Owners are responsible for ensuring that the team understand what to build to best deliver the Product Roadmap, focusing on valuable increments instead of resource utilisation. Ensuring the team understand the work, the vision and the value, helps the team make better engineering and goal based decisions. Actually writing the Product Backlog Items (requirements) themselves instead of delegating to Agile BA’s or Developers from the team.
Delivery
Myth #7 Teams can do as they please
A constant worry for many technical managers, architects and leaders. They mistakenly believe that self-organisation means that the teams can devolve into anarchists, building what they want, when and how they want to. Although it is true that Agile teams self-organise to deliver complex products, they do so with a solid understanding of the overall product road map and subsequent goals. Teams self-organise to solve problems along the way to deliver valuable outcomes – they are proactive and driven to resolve issues, learn new things and keep the delivery engine moving but are smart enough to reach out for support when needed. Teams must subscribe to the organisations standards for product delivery because Agility is about entrenching quality into the day to day delivery so that solid architectural standards can be applied through the teams definition of done. Far from anarchists, Agile teams are highly disciplined.
Myth #8 Agile teams don’t document
The myth that Agile teams don’t do documentation probably originated from misunderstanding one of the Agile Manifesto values: “We value working software over comprehensive documentation.”
This value doesn’t outlaw documentation – instead the emphasis is on delivering working product to our customers – consistent delivery unlocks value. Documentation is treated like every other deliverable in an Agile team - if it’s needed, it gets done.
Myth #9 Agile doesn’t scale.
With the prevalence of large complicated and unfathomable scaling frameworks, you could be forgiven for thinking that Agile teams don’t scale well, because those behemoth approaches don’t work.
We have found that when teams are working well at the team level and are able to build product and release frequently, the practices that made them successful can be amplified and will scale. When scaling, firms depart from the principles that helped the teams become successful and instead optimise to deliver via specialist functions – through specialist security teams, UX teams, devops teams etc. The focus on highly specialist utilisation creates bottlenecks throughout the system, creating multiple handoff points, undue stress or pressure in specific areas.
Savvy Agile organisations develop their own scaling framework by staying close to Agile principles and managing delivery from a risk based systemic perspective – optimising the whole instead of just parts.
Conclusion
In isolation, the above myths (and resultant problems) may seem innocuous and surmountable, however, over time, these challenges accumulate and can stop an organisation in its tracks, causing vast and costly waste, frustration and an exodus of good people.
For 30 years, Fractal Systems has been supporting organisations in unlocking Agility and generating the returns they are looking for by creating effective Agile organisations and cultures which thrive despite market conditions.
Our Agile Performance Scorecard helps you understand how your programmes are performing against a set of high-performance Agile indicators. Along with your results you’ll receive practical written suggestions on how to make improvements so you can achieve the outstanding delivery goals you have been working towards.