Despite how mature and technically advanced our IT teams are when it comes to Agile ways of working, it’s critical to have our business on board to realise full benefits. By involving our business teams upfront, this ensures solutions are designed and structured in a way that can be delivered incrementally. Given Agile provides many benefits to our business stakeholders, it’s often hard to understand why they don’t want to adopt this way of working. A recent experience put into perspective some of the business concerns with Agile ways of working which were generated by a perception issue. The key learning we took away is that IT teams need to play an important role in managing business perceptions of Agile, as the perceptions our business stakeholders have can be either a key enabler or blocker for adopting these principles across the full delivery pipeline. The Experience Where we were at in our Agile journey: The IT team we were working with had reached a level of maturity where they had collaborative, adaptive ways of working and the technical capability to go to market faster. The problem: Solutions the business stakeholders were designing required as many as 3 months build effort (with multiple dependencies). Despite taking a design slicing approach to breaking the work down and highlighting the benefits of delivering faster, we couldn’t get over this hurdle. Because of the way the business stakeholders were working, they were designing solutions with a very traditional waterfall mindset. Next steps: We aimed to encourage the business stakeholders to work in an Agile way to define solutions which could deliver customer value faster. We found however the stakeholder was completely anti-Agile and had no intent or desire to adopt this way of working. By spending more time understanding the business concerns, we found that the stakeholder went on a recent trip to Silicon Valley to visit a number of industries leading innovative organisations to see how they were working. The Stakeholders Perception Visiting these organisations, we’d expect this to paint a picture of Agile success and get our business stakeholders wanting to start their Agile journey immediately. The reality was the opposite. What the business stakeholder saw was bean bags in open collaboration spaces and developers working on a vast array of ideas that didn’t seem to align to a business outcome. They didn’t see the developers working in a way that had business alignment, direction and structure to ensure the organisation was meeting their customer needs. These are common perceptions business stakeholders have with Agile adoption. Business stakeholders commonly feel that Agile is an IT led initiative and it doesn’t translate into their business world or consider the challenges they face. We found it hard to counteract the stakeholders feelings based on how they described what they saw – despite knowing this isn’t what Agile is about. If we put ourselves in their shoes and think about what they need to achieve within an existing enterprise with millions of customers to serve and government regulations to meet, the ways of working they saw were not acceptable for their organisation. The Reality When seeing Spotify Agile coach Anders Ivarsson speak, this provided a point of view, or a framework that explains the bean bag sitting ways of working, in a way that could be used to bring context to business stakeholders and reality to these perceptions. Anders spoke about a 4 quadrant model of alignment and autonomy, which we have reproduced below: This model represents well how their business moves between the different quadrants with context to where they are and what they are trying to achieve as an organisation. Our business stakeholder had visited these other organisations when they were in the bottom right quadrant and had no context of why they were in this quadrant and the fact that the organisation doesn’t operate like that all the time. In fact, the organisation operates quite like their own most of the time, particularly when there were defects/production issues. Another business perception of Agile is that it creates chaos and this is what the stakeholder believed they saw! The reality is, by being Agile and having an adaptive organisation which can move between these quadrants easily, you are able to align the way your teams work to achieve maximum business value. Numbers have been overlayed on the four quadrants diagram to link up with below dot-points to describe the ways of working: Low alignment – High autonomy: When the business is trying to come up with new ideas, new products and generate a creative mindset, they are in the bottom quadrant. The low levels of alignment and high autonomy encourages brainstorming without constraints. High alignment – High autonomy: Ideal operating rhythm is the top right quadrant, teams are working towards an aligned and agreed goal, but are able to operate with a level of freedom and autonomy which means they can achieve maximum output. High alignment – Low autonomy: When there were production defects or any issues, the teams operated with a higher degree of alignment and lower autonomy. This is typically through higher levels of reporting and governance to ensure resolution (particularly within strict SLAs). Low alignment – Low autonomy: Finally, the bottom left hand quadrant no one ever really wants to be in – you have low autonomy and low alignment. Essentially your team isn’t achieving much and would be quite unhappy. Lessons Learnt The key learning out of this experience, was when showcasing Agile principles we need to think about the broader picture and put ourselves in the shoes of the business stakeholder. While we might be thinking this is a great and innovative way of working and be excited from an IT perspective, the perceptions our business stakeholders leave with might be completely different. Without the right context, we might be doing ourselves a disservice in our Agile adoption journey by visiting these large organisations and not asking questions to understand their way of working from a business perspective. It’s important to understand the way of working in context to what the organisation was trying to achieve at the time we are visiting. If we do this, we ensure our stakeholders leave with a higher appreciation for the ways of working, which make sense to them from a business perspective. A negative perception of Agile can make the Agile adoption and journey so much harder. In short, by not thinking holistically and panting the big picture, it is a much more challenging journey to enable Agile adoption. Using this four quadrant tool is a great way to explain the adaptability that Agile brings.