Making Agile Work: A Guide for the Rest of Us

By now everybody has crossed paths with Agile, that wonderful, elegantly deconstructive way of delivering technology projects - focusing on humans and teams rather than dry documents and specifications, and full of organic freshness! If you’re like me, you’ve been in turn impressed by the clarity, bemused by the jargon, amused by the rituals and occasionally frightened by the fanaticism of some of it’s missionaries, this may be a useful piece for you. 

There is no doubt that if used correctly and in the right context, the Agile methodology can deliver great results. But it’s equally important that we understand how to use it correctly and the conditions under which Agile thrives. And also some of the challenges you will face, working with Agile and it’s practitioners. This post is written for everyday managers in businesses who are not developers, agile experts, scrum masters or even agile familiar. 

A Quick Recap 

According to the Agile Manifesto, Agile is a way of developing software in a manner that delivers on time, on value and embraces the reality of change in requirements. It also strips away the bulwark of documentation, and relies much more heavily on working software. It focuses on the maturity of the team - to plan, execute, and reflect, and values simplicity and face to face communication. It is in direct contrast to the more traditional ‘waterfall’ approach most commonly used before agile. 

In order to execute against these principles, the Agile approach uses a number of techniques and measures. These include sprints, scrums, burn down charts, velocity, stories and epics, retrospectives, minimum viable products and many others. Often, when we first engage with agile teams, this is what we see - the visible rituals of agile, that can make us feel like we’ve stumbled into a meeting of a secret cult. 

A New Religion 

It may not be a cult, but it is my view that for enterprises, adopting agile is deceptively difficult. In fact, adopting the rituals is easy. Adopting the philosophy is incredibly more complex. It requires a huge mind shift. It’s harder than supporting a new football team or changing your favourite sport. It’s like changing your religion. It requires you to think about things in a new way, almost from ground up. It’s important that we understand this and be conscious of both the benefits, which are many, and the significant challenges, which I’ll try to highlight shortly. 

Why is Agile Better? 

First, though, let’s remind ourselves of the benefits of agile. The reality is that in the fast changing world we live and work in, today, linear and waterfall projects invariably run the risk of going through an endless series of change requests, rebudgeting and re-design effort. Especially when it comes to new services and products, market innovations and digital initiatives where breakthrough technologies and new user behaviours are commonplace. Even traditional enterprise software - such as sales and CRM systems are better delivered with an agile approach for these reasons. 

So why is it so hard then? 

No Agile Team is an Island 

The first challenge to consider is how to make the enterprise agile. If the development team is switching to agile, the enterprise needs to as well. As such, it’s not just a software development methodology, it becomes an enterprise manifesto as well. It becomes the way you launch new software, roll out new processes, and make changes to the business. If you think that you can run an agile IT team without impacting the way the rest of the business runs, you will be running the ship aground very quickly. You may need to create a very clear handshake (or API!) between the agile and non-agile parts of the business anyway, especially during the transition, but getting the business to think agile is critical. 

The Challenge of Metrics 

The CFO has a problem. In a traditional waterfall world, she knew how much money she was investing and what the expected returns were. Most agile experts will tell you that you can’t pinpoint exactly what features will be delivered 12 or 18 months down the line because the methodology is an emergent one. The reality is that given the likelihood of changes that any project would go through, the agile project will invariably deliver more than the waterfall one. But the CFO, nonetheless, has to make this leap of faith. The industry needs some metrics which have gathered date across a number of projects and established via benchmarks that agile projects on average deliver 20% more (for example) than traditional ones. This does not seem to exist today. In fact, most agile projects can’t even tell the CFO what budget they will burn through over 12-18 months. 
Similarly, the business owner would like to ensure that the product gets to market before that of the competitor, or that the CRM upgrade is delivered at an industry standard cost. What she will probably get from her agile team is a zen like response about the team finding it’s own velocity and burn rate. These are interfaces that need to be built, or the CFO and Business owner have to be agile exponents themselves, and work out their own metrics for investment, risk and competitive parameters. 

This is not to say that agile projects don’t have metrics. There are plenty of metrics used by agile teams across the board. In my experience these are very useful for the self regulation and management of the agile team, but less useful for external reporting. Often therefore the misguided marketing manager is asking for a gantt chart for the app so he can share it with the external agencies, much to the bemusement of the scrum master. 

Realistically, any business needs metrics for development and product creation that are predictable, comparable (with other businesses) and compatible (with other metrics that exist in the business). Agile projects often struggle to deliver all of these metrics outside of the core development metrics, which are internal to the team. Unless of course the organisation itself switches to an agile mindset and uses different metrics. 

Practical Stuff - Contracts

As a significant percentage of IT work is delivered via external partners - software shops, agencies or System Integrators (SIs), these relationships are governed by contracts. Most of these contracts are still written with traditional, pre-agile work structures and accordingly their governance structures and risk-reward mechanisms are not aligned with agile philosophies. Potentially, we could get to more iterative contracting to reflect the agile approach and philosophy. A big part of this is the issue of trust. Agile works on mutual trust and maturity and most contracts are built on more adversarial terms. 

Skill & Maturity Levels 

Last but certainly not the least, you need to think hard about the skill levels and maturity. If you’re used to a more traditional waterfall approach, using a global software partner, the chances are you have ‘software factories’ set up. The factory model works at scale, as the name suggests, with each individual focused on a very specific area of a ‘production line’ of software. The agile world is more like a lab where each individual’s contribution is key and the level of individual, both from skill and maturity perspectives is much higher. You are expecting this person to manage without documentation, and productive driven by personal motivation. It is very dangerous to take an erstwhile waterfall model and switch it to an agile one keeping the same team and skills in place. There is no reason why this should work. I have seen projects suffer because of the important differences between project managers and scrum masters. A large project with multiple teams and external stakeholders may need both. Needless to say, leadership styles will differ significantly across the two models. 

Forwarned is forearmed 

In any number of projects that I have seen at close quarters, the teams have had to hit a number of challenges in the early stages of projects and had to conduct a specific meeting with all stakeholders where the primary question was ‘what did you mean by agile?’ If you’re in a situation where you’re being told to run a program in the agile manager, I hope this piece has pointed you in the direction of what to look out for and guard against, so that you can benefit from the power of agile, while addressing all the challenges. 

Of all these challenges, the one that is probably the most difficult and yet the most subtle is the need to look past the rituals of agile and embrace the philosophy. Without this you will always be out of tune in an agile orchestra.