Rich Linstead, Lead Product Manager from BCG Digital Ventures’ Sydney, discusses (and provides you with!) unit tests for Agile implementation in your organisation.
It’s official; pretty much everything is now Agile (not to mention probably being disruptive, too, — and certainly innovative). A couple of years ago usage of the term reached tipping point, and now it appears to be de facto jargon in every company statement and press release . When even my CFO mate drops the A-word, it’s firmly on the AGM buzzword-bingo card.
I think that’s awesome. The more agility we try to implement in every aspect of our lives, the better for us all. At the end of the day, the purpose of Agile is to embrace change, to enable us to release products faster, and, in so doing, to reach customer value quicker. It encourages us to accept that the more we try to pre-define the end result, the more we increase the risk of building the wrong thing.
So, first things first — I think that any actions that aim to help an organisation increase their capacity to be agile should be encouraged. The aim of this article is not to question the motivations and efforts of thousands of people in organisations around the world starting their Agile journey. I don’t doubt the intentions of so many companies and individuals, keen to try a new way of working.
However, there’s a huge temptation to take a purely tactical approach to this change, and it’s a road to disaster to confuse agility the motherhood-concept with Agile the development-philosophy. This is made harder by the fact that being agile sounds like such a good thing, and that methodologies such as Scrum are so clean and simple to understand. Why wouldn’t you encourage your Head of PMO to switch your projects to this process, which sounds so flexible, logical and cost-effective? And so, as an enlightened C-suite stakeholder (best case) or evangelist middle-manager (more likely) you institute an Agile Transformation project, forgetting the first rule of A-club…
There is no such thing as an Agile Transformation project.
True Agile involves a step-change in thinking, a complete re-structuring of the way we envision work. It is predicated on an organisation having a clear understanding of the customer being served, an ability to articulate and measure user value and above all, clarity on the nature of the product being built. Pretty much every ‘transformation’ I’m aware of is focused on changing the means of delivery, rather than the truly transformative task of challenging why the organisation does what it does. A change like this can’t be viewed as a project within the PMO. It has to be viewed as a complete shift of focus and approach throughout the C-suite.
I’m going to talk more about this philosophy and the inherent psychology behind the Agile movement in another article, but, to start with, I want to propose an initial way for organisations to baseline their current state. Can we create a universal test, — a standard set of questions to assess the robustness of an Agile implementation? Think of it as a set of organisational unit tests to check whether your system is functional. Based on my experience, and conversations with Agile Coaches and team-members in Australia, the UK and the US, here’s a starting suggestion. I’d love to hear thoughts on additions!
Ask yourself these questions:
Now, of course, in answering these, the specific detail will always change; true Agilists embrace that inevitability. That’s the whole point — individuals leave, technology evolves, scope alters, insights drive pivots. However the primary principles remain absolute:
● Without an actively-engaged and empowered owner providing real-time, insights-led focus and direction, it is impossible for a team to build what the organisation needs in an Agile fashion.
● Without final stakeholder input on an ongoing basis, it is impossible for them to have the level of understanding they need to effectively support the team, and to plan for the release of a product that’s being incrementally defined.
● Without the relevant resources, in an appropriate structure, a team cannot be cross-functional, self-managing, and therefore able to incrementally build a product.
● Without a defined product focus (and accompanying end-customer assumptions) there is nothing for the team to deliver. It is impossible to create value without a sense of purpose. In every aspect of life.
If you’re lucky enough to be able to genuinely say “Always” to the majority (let’s say a total score of between 10 and 12), then that’s awesome! As a team-member or Coach, make sure the tests keep passing! As an executive, great work — you’ve got an Agile production machine, now you need to make sure you feed the beast with a clear strategic direction for your product.
Based on the anecdotal evidence I’ve heard, most organisations will score less than 10 if they’re really honest about the way they currently work. So this is an opportunity to reflect and improve practices.
If the answer to any of the questions is “Rarely” then, honestly ask yourself if an Agile approach is relevant to you — to your business, to the project or product, to your people? If you feel it is, then analyse the failure area. Here are some initial thoughts to consider:
Fixing Test 1 sounds pretty simple: restructure, re-focus, or hire to empower and enable true Agility. In practice, finding A-players to fill a product ownership role is extremely hard. They have to be able to jump between a helicopter view and a practical implementation perspective daily and make complex decisions at the conjunction of technology and the customer value proposition. Then, on top of that hiring or training challenge, you have to change the command-and-control hierarchical nature of traditional organisations to empower that individual to be able to make calls on value delivery autonomously. Tricky? I know, but the reward is worth it.
Fixing Test 2 is the easiest: as an executive, ask yourself, how much does the delivery and development of this product matter to me? …A lot? Then this is the best possible opportunity you can have to understand and influence. It’s so much more powerful to attend a well-run showcase and feed back to a product owner and team, than to sit in another SteerCo or PMO session. I guarantee you will gain more value out of these timeslots in your diary than any other. On the other side of the coin, there is nothing more motivating to a good team than seeing their leader attending and engaged in their outputs. Quite honestly, just make it happen.
Fixing Test 3 is all about organisational structure and alignment. It’s tough because it usually requires the breaking-down of business silos, and fundamentally challenging a lot of preconceptions. That’s going to cause a lot of disruption in a company — not the positive, LinkedIn-buzzword kind, but difficult people-management issues. Reporting lines are likely to change and existing legacy ways of working and technologies will be affected (CI/CD is a pretty critical part of the process, for example). This is why an initial Agile implementation needs to focus on a golden thread through the business — a single, cleanly-defined product, a dedicated team, the capacity to deploy code to production in real-time, the remit to do what it takes to get to done. Creating the environment to allow an Agile team to work is a huge indicator of likely success.
Fixing Test 4 is the biggest, and, anecdotally, the most common challenge. Agile is a highly effective approach to delivering when there are a lot of unknowns — but the product proposition can’t be one of them. Lack of both business and product focus is the most common flaw in legacy organisations, and the biggest blocker to getting maximum value from the process. The un-owned gap between strategic direction and practical implementation results in ill-defined projects, and purposeless products. The reason start-ups beat incumbents hands-down is their laser-focus on a deeply-felt “why”, and a drive to achieve it as fast as possible before they die — all the other stuff goes out the window. While you certainly don’t have to be a start-up to deploy Agile, you’ve got to have a product vision.
I hope this has been a useful article for you, and I’d love to get your thoughts: Are there other tests we could add? Are there other strategies for resolving the big blockers? As team members, what are the most frequent challenges to your capacity to operate in a truly Agile manner? As an executive, what are your biggest questions or frustrations with your current Agile implementation?
Leave a comment below, or tweet it to me: @rich_linstead