5 ways being 'wrong' about Agile could help get the most from it
Agile theory can seem intimidating when approached as a concrete doctrine, set in stone – something which can see businesses use it in inappropriate ways. Harry Vazanias, a Director and Co-Founder at Enfuse Group, argues that businesses need to worry less about getting things ‘wrong’, if they are to get the most out of the operating model.
Ironically for a methodology with such a name, many of the proponents of Agile working remain rather rigid when it comes to its application. According to Harry Vazanias, that may mean that many leaders are missing out on new ways to apply the mode of working in a world that is vastly different, from when Agile was first developed.
The Enfuse Group Director explained on the firm’s website, “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.”
Founded in 2015, Enfuse Group is a management consultancy specialising in delivering high performance digital transformations and solutions for companies across the industrial gamut. This means that over the years, Vazanias and the firm have been well-placed to glean a number of best practices, when it comes to implementing Agile change. According to him, there are even five instances where doing Agile ‘wrong’ might actually be the right approach.
Track milestone dates
Traditional Waterfall working breaks down a goal into isolated phases that flow into each other, while Agile advocates iterative development cycles in which multiple lifecycle phases can run in parallel. While Agile’s advocates might usually reject using milestones, then, Vazanias first noted that traditional milestones might sometimes have a place in Agile planning.
“Many Agile practitioners hate milestone dates,” Vazanias explained. “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.”
Avoid story points
Story points are units of measurement used to determine how much effort is required to complete a product backlog item or any other piece of work. The team assigns story points based on the work's complexity, amount, and uncertainty. While they “can be a great way of estimating a team’s capacity and their likely velocity,” Vazanias added that there is a “growing view” that they can be more trouble than they are worth.
“It is worth stating that they are not in themselves evil and can be a very useful tool,” he went on. “However, in Agile teams we should be very open to using other mechanisms to size work and set expectations… 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 [or other] major incidents which slow down the team.”
Place Product Owners in IT
In an Agile organisation, the Product Owner (PO) is responsible for prioritising and overseeing the development team's tasks and making sure the company derives as much value as possible from the team's work. Where to place the PO is a matter of debate though, and while it is considered ideal that they sit “in the business area” of the product, many products may belong to multiple business areas. At the same time, business owners are unlikely to have the time to properly dedicate themselves to the product, or “to have the right skills or experience to manage a product in an Agile way.” Here, the software development origins of Agile methodology may give a clue of where to situate a PO, then.
“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,” Vazanias said. “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.”
Give the team guidance
Contrary to popular belief, autonomy and collectivism do not have to mutually exclusive. While Agile theory states that businesses should have “self-organising teams where you trust the team to come up with the best answer”, Vazanias suggested that guidance is still needed, comparing it to “mobilising a football team”. Just letting the players “all work out for themselves where and how they play together” can occasionally work – but more often it can “be a disaster.”
“To be clear we are not talking about micro-management here,” he elaborated, “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. “
Slower, bigger releases
Finally, it is worth noting that speed is not always a plus. If Agile makes a team into a machine of perpetual motion, that can be a recipe for burnout. Releasing products constantly can wear down teams, and product users alike – when “change fatigue” becomes an issue. According to Vazanias, while Agile “naturally wants to deliver value as early as possible, with plenty of feedback loops,” there are always cases when the customers may “value fewer and bigger change releases”, in which case, the right answer may be to hold back and bundle changes more.
Ultimately, there is no one-size-fits-all application for Agile that guarantees success. Even the previous tips are not necessarily “the right answer for every firm,” Vazanias admitted. However, he concluded, the most important thing to take from all this is that there is a greater need for pragmatism when it comes to applying Agile than many leaders have previously permitted.
He summarised, “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?”
