Being Agile: What Good Looks Like

BrandPost By KPMG
Sep 18, 2019
IT Leadership

You want to be Agile. I get it. But whenever a business leader tells me that they want to be u201cAgileu201d, my first question is: u201cWhy? What does that mean to you? And how will you know if youu2019re making progress?u201d

shutterstock 698794381 14998
Credit: KPMG

By John Roy

You want to be Agile.  I get it.  But whenever a business leader tells me that they want to be “Agile”, my first question is: “Why? What does that mean to you? And how will you know if you’re making progress?”  

Real Agile transformations are hard…. really hard. They require organizational fortitude, tough prioritization choices, institutionalized trust, and a team of leaders who is willing to constantly encourage small failures. 

There are 3 phases of agility:

  1. Knowing Agile 
  2. Doing Agile 
  3. Being Agile 
doc6 copy KPMG

 Knowing Agile is providing academic information about business agility and Agile practices.  It starts with training and education, and often includes some level of certification or recognition that training has been completed.  It typically does not include practical knowledge or experience.

Doing Agile is practicing Agile rituals and ceremonies.  Stand-up meetings, bi-weekly demos/reviews, sprint planning, Kanban boards and story points are all indications of “Doing Agile”.  But simply performing some practices which are recognized as Agile does not translate to an Agile work environment, high-performance teams, better quality or faster time to market. 

Being Agile is truly working differently.  It includes a drastically new decision-making structure, fully integrated business involvement, persistent teams, product focus (not project), DevOps and a Shift Left culture.  Ultimately, it means converting those rituals into daily habits which drive action.  


Some of the practices that we recommend in advance of an Agile Program launch include:

  • Shift to a product-driven organizational structure. Products rule the world, and software eats the world. Software will likely enable or envelope virtually every aspect of your business, and that’s a good thing. Even the most traditional products and business models have been disrupted and digitized in the past two decades. Think of each product team as its own little company, and your job as a senior leader is to empower, nourish and mature that company. 
  • Fund innovation. Often, in addition to product teams, companies need to fund an innovation lab, design studio or similar team who can incubate product ideas and features- some of which will develop into new products and some will end up on the cutting room floor. The key is that they are given the resources and latitude to be creative.  
  • Train everyone in your company on Agile – seriously, everyone. Start with a simple two-day course (there are plenty of them available), and expand out so that everyone is trained on the new methodology and ways of working within six months. Develop a role-based curriculum which allows for a gradual progression and long-term adoption model. 
  • Select a Scaled Agile Framework that allows your company to function properly, and that flexes with your organization. SAFe, LeSS, DAD, Nexus, Scrum@Scale and Spotify are all examples of such frameworks. 
  • Implement a new set of metrics: Objectives and Key Results (OKRs) are the value metrics which should be tracked at the top of the house. They are derived from your strategic themes/objectives and have specific results with targets (hard numbers) that can be measured.


Once the Agile Transformation Program has been developed, there are a set of practices which will facilitate successful implementation:

  • Establish an Agile Delivery Office (ACOE, ADO, LACE, etc.) staffed with people who really “get” Agile. This is not a repurposed PMO.  While this team may perform portfolio management and reporting for you, they need to understand the new ways of working in order to implement it properly as you scale, and guide it as you grow.  
  • Release new product features more frequently – often faster than you are comfortable with. Short-cycle delivery is one of the most important principles of Agile. It is not mini-waterfall. Quarterly releases are not short-cycle. Every two weeks (or more frequently) is the industry recognized standard for short-cycle delivery to production.  Ultimately, you will fail fast and fail small, with a backup/back-out plan.  
  • Embrace DevOps. An investment in DevOps tools and integrations provides the grease that turns the wheels.  DevOps and continuous integration / continuous deployment (CI/CD) capabilities allow teams to release features in a pre-determined and disciplined manner, this minimizes failures, automates testing, satisfies audit requirements and predicts potential issues with a documented back-out plan.   


As the Agile Program expands and matures, there are several practices which can be employed to help organizations improve:

  • Trust your teams. Directionally, senior leadership sets the strategic objectives and OKRs, but self-organized and self-empowered teams (led by autonomous and authorized Product Owners) will determine the best approaches, technical architectures and all of the “how” when developing, testing and launching product features. This means that there are no more Steering Committees; escalation procedures change dramatically, and issues get resolved at the lowest possible level (team level). 
  • Practice transparency. This applies to status, roadblocks, deliverables, stories…. everything that the team works on.  Transparency should be a mantra for all Agile teams, as well as their leadership.  All deliverables are works in progress, therefore should be open for inspection at all times.  They key is for Product Owners to set expectations with senior leadership about the nature of those deliverables and how they are being delivered.  The best measure of progress is working software available to users. 
  • Manage progress indictors differently. Stop managing by status reports and eliminate date-driven mandates. You can select product launch targets and MVP milestones, but they will not be fixed scope; they will be more thematic in nature without specific features fully defined.  Information radiators (as they are referred to in Agile-speak) are incredibly important.  Transparency is an Agile core principle, and as such, it should be built into every transformation.   

For those who are habitually agile, seeing failures is proof that you are learning, constantly improving and getting closer to your customers.  Those who think in an Agile mindset put trust and transparency above all else in their culture.  So, look in the mirror and ask yourself if you are truly agile, or if you are simply going through the motions.

For more information on how to be Agile, please click here.