The four indicators of poorly implemented Agile

“Being Agile, not just doing Agile.” A phrase that I hear often, and often I question what does this mean for each of the organisations that I work with? Agile is truly effective method when done correctly, and I’ve seen the word Agile used widely as a gold standard for problem solving complex systems, but at what stage can an organisation define themselves Agile? How long does this take? What changes do they need to make? Etc. Each and every one of the implementations or transformations that I’ve worked with are on different journeys, this is what makes my role so varied, challenging and rewarding.

What I have learnt is that badly implemented Agile, or just having Agile as a buzzword as an aspiration for your software development, and expecting ‘Agile’ to be the solution to fix all your problems only causes confusion and misperception, and builds on the resistance towards Agile adoption. Just by using the language that resonates with the Agile philosophy without much of a thought towards adopting new valuable practices is a real challenge.

So how can we identify Being Agile vs Doing Agile, and what are the indicators of poorly implemented Agile?

1. Rebranding Waterfall into smaller iterations, or Sprints

• How quickly can you adopt and implement any change? Can you adopt to changes to customer needs, legislation, market trends, competitors to benefit your organisation?
• Is your ability to deliver working software available to the customer, or end users, sustainable? Or is there a huge, high risk, manual effort to get releases over the line?
• Are you doing a number of iterations, or sprints, to meet business deadlines without measuring and testing incrementally to ensure the products quality and that it meet the clients’ needs?
• Do you have separation between all tasks to complete a work item i.e. development, testing, release?

2. The Agile philosophy is not understood across the organisation

• Does everyone in your organisation have an understanding of the Agile philosophy so they can demonstrate Being Agile?
• Is there a variety of methodologies in your Agile teams, and how is this impacting end to end delivery?
• Are your employees aligned to organisational priorities and do they have buy-in on metrics, deadlines, value, and processes?
• Are decisions and choices based on these priorities, or are you reactive (not proactive) to meet

3. The teams are disorganised and idle

• Do your teams constantly face challenges from behaviours, dynamics, and location?
• Are there too many people on the projects?
• Is there a high turnover in the teams?
• How valuable, creative and self-organised are your teams?

4. Customers and/or end users aren’t involved

• How much of an influence do your end users have in the decision making?
• Do you have a strategy in place to meet, and adapt, to customer needs?
• Is new functionality available to users to validate iteratively, and bringing the customer on the journey with you?
• Are your customers aware of the business objectives in the roadmap (if you have a roadmap!)?
• Is there a feedback loop for the teams to speak with real users of the product?

If you’re questioning and are curious about these statements, then you’d certainly benefit from Agile training that is necessary to minimise these mistakes and make sure the benefits of Agile is unlocked for the whole organisation. If you're serious about adopting this Agile mindset, it will drive further changes and incur extra costs, yet without proper training, this extra cost will become a waste if it's not built sustainably.

Robbie Ross
Agile Practise Manager, Jumar