The Right way to do Agile Wrong
Agile was designed over 20 years ago for software development. Since then, the world has dramatically changed and, with it, the use of Agile. However, there has been a notable resistance against adapting Agile beyond its original parameters as this would be ‘wrong’. For many, if Agile isn’t working then you just aren’t doing it right. The truth is that Agile is being used in ways and on scales originally not imagined, and hence doing Agile ‘wrong’ may actually be the right thing to do.
Here's five ways of doing Agile wrong which might be the right approach…
1. Track and use milestone dates
Many Agile practitioners hate milestone dates. It’s just ‘so waterfall’. However, Agile does benefit from goal setting and some goals will inevitably involve milestone dates. To pretend otherwise is fantasy. If the team need to deliver certain value or other outcomes by a specific date, you need to ensure their Agile practices acknowledge and support this. Having Agile teams aware of key dates and using these to prioritise makes sense.
2. Don’t use Story Points
Story points can be a great way of estimating a team’s capacity and their likely velocity. However, there is a growing view in Agile circles that story points have paved a path to the dark side. The inventor of story points, Ron Jeffries, even agrees:
“I like to say that I may have invented story points, and if I did, I’m sorry now.”
Ron Jeffries isn’t against them, but does feel that much of their application in Agile is problematic. They can be overused to predict ‘done by dates’ and come with built in inaccuracies for predicting backlog item work effort. Just trying to manage the natural flux in story points by sprints becomes a cottage industry as you factor in variables such as illness, holidays and curve balls (such as major incidents which slow down the team).
Having just called out the short comings of story points, it is worth stating that they are not in themselves evil and can be a very useful tool. However, in Agile teams we should be very open to using other mechanisms to size work and set expectations. Dare I even say it, but the old school drafting of a plan/roadmap and setting a target date is as valid an approach as any other. Using time estimates instead of story points can also be very effective.
3. Have the Product Owner role in IT
Ideally the product owner (PO) should sit in the business area, but the practical reality is often very different. The product may be such that it belongs to multiple business areas and owners. The business owner(s) is unlikely to have the time to properly dedicate themselves to the product. They are also unlikely to have the right skills or experience to manage a product in an Agile way. In particular, they may lack the technical understanding needed to balance business and technical needs.
Having a PO in IT who gets the IT side and has the specialist skills to be the conduit with the business owners and areas can make a lot of sense. However, this often meets resistance from Agile lovers. There is the common sentiment that Agile is doomed to fail if the PO sits in IT because the product is not owned by the business. This is simply not true. The PO can sit in IT, where they are an expert in product ownership, and they can ensure that the business areas are properly engaged and invested. Many organisations have this model and is does succeed.
4. Tell the team what to do
Agile says that you should have self-organising teams where you trust the team to come up with the best answer. Whilst this can be an effective approach, for some environments it can be a step too far. It’s a bit like mobilising a football team and letting the players all work out for themselves where and how they play together. It can work, but it can also be a disaster.
What surely makes just as much sense is letting leaders be more hands on and directive, which is what happens at most firms. A study done by Google on what makes for effective teams actually found higher performing teams had “structure & clarity” with clear goals, roles, and execution plans. Actively giving a team greater clarity on its structure and purpose can be a good thing, just like a football team where the players may benefit from clear direction on what positions and style they should play in.
To be clear we are not talking about micro-management here, as letting the team input to decisions is part of any good leadership style. Leaders can and do provide great value when they are allowed to lead, make quick decisions and give the team direction on how they will best work. In contrast, whilst it can be great when an Agile team works out its own answers, it’s also a risk because the team may spend too much time trying to get there, and they may arrive at the worst possible answer. Decision by committee can be a dangerous thing.
5. Slow it down; do bigger releases
An IT director at a major UK retailer once asked me if the speed from the Agile teams was “always worth it”. He explained that his Agile teams were causing a lot of headaches as continuous change was frustrating users in some areas (e.g. Finance) and people were looking back fondly on the days of quarterly and even half yearly releases. Change fatigue was the issue. Agile naturally wants to deliver value as early as possible, with plenty of feedback loops, but there are cases when the customers of the changes may value fewer and bigger change releases. The right answer can be to hold back and bundle changes more.
I’m not saying that all the above would be the right answer for every firm, but I am saying that we need to be far more pragmatic about what we are trying to achieve and how best to get there. The focus should not be on implementing Agile, it should be on implementing the best operating model for changes. If this is the classic Agile we know for software development then great. But it can also be a more modern flavour of Agile where we adapt and consider other modern approaches that could be blended with the Agile thinking from 2001. Surely that speaks to an Agile mindset?
