19 characteristics that make agile radically different to what’s gone before

In an earlier post I noted that I’ve been doing a bit of thinking recently about the introduction of agile methods into organisations that use non-agile methods such as PRINCE2. In particular I noted that:

Agile ways of working are radically different to the non-agile ways of working that preceded them.

That is, agile methods aren’t just a bit different to what’s preceded them, they are fundamentally different. These fundamental differences require adaptations in the corporate service processes (finance, governance, procurement etc.) that enable delivery teams to avoid friction between delivery and corporate services teams while maintaining agility.

So what’s radically different?

Here are some characteristics of agile that mean agile teams place different demands on corporate services. This is not an exhaustive list and I welcome more examples. My argument is that the sheer number and range of differences means agile teams have radically different needs as users of corporate services:

1. Agile methods have a core assumption baked into them — that delivery is best approached as a learning process — you can only learn what you will build, how you will build it and who you will need to build it through trying to build it and regularly sharing what you’ve built with customers/users to get feedback. You learn and change course as you go.

Non — agile methods assume that you can figure most of these things out before starting to build. If you’re not familiar with agile ways of working, you will be frustrated by agile’s inability to give you up-front certainty. But that is a corollary of novel delivery work — which is what most people are doing whether they realise it or not — not of agile ways of working.

Basing everything you do on being able to figure these things out without doing delivery leads to disappointment sooner or later.

2. Uncertainty around what will be achieved by when and by what size and shape of team — which is inherent in novel delivery work — doesn’t fit well with detailed business case writing, workforce forecasting and other pre-planning processes that assume these things can be known in advance. Agile is an exploratory method for dealing with uncertainty.

3. Agile teams cannot (and should not) forward plan feature delivery to a level of detail that is unknowable. Their roadmaps, if they have them at all, should be necessarily vaguer as the time horizon disappears into the distance. This can be uncomfortable for stakeholders used to seeing a detailed prediction of what they will get by specific dates. In a pre-agile situation, stakeholders have what I call the illusion of control — because it can give them a warm, fuzzy feeling of control — even though a roadmap, for novel work, is necessarily a work of fiction.

Non-agile ways of working often require the creation of a detailed roadmap and Gantt chart mapping out what’s going to be delivered by when. The roadmap somehow becomes ‘cast in stone’. Overly-detailed roadmaps like this make this illusion of control worse as the feeling of control melts away when the information underlying them is found to have little basis in reality. In a pre-agile world, the usual, but flawed, reaction of stakeholders is to blame delivery teams for ‘getting it wrong’ and require them to lock down the roadmap even more. The problem isn’t in the teams, it’s a failure to acknowledge the inherent uncertainty of delivery and use appropriate methods for managing that uncertainty.

Agile teams recognise that a detailed roadmap is a logical impossibility under conditions of uncertainty. Some things may be knowable; others will not be. As projects progress, agile teams make it clear to their stakeholders what they have learned and what they are still uncertain about. Work is often prioritised to decrease uncertainty / increase learning. Better to begin with a sparse roadmap and flesh it out and revisit it regularly as your project proceeds. The less you know about particular parts of your journey, the less detailed your map must be.

4. Because delivery is a learning process, agile methods embrace change — the why, what, how and who of your work can change rapidly as new evidence is uncovered. Non-agile approaches often operate to prevent change, or at least operate on the assumption that change — i.e. deviation from your initial predictions — is rare or slow. Change boards that meet infrequently and decide whether a change is permissible are a reflection of this way of working. Better to delegate decision-making to your delivery teams or those operating at the same pace as your delivery teams. If you feel unable to do this, at least make sure that your change boards operate at a pace that don’t block delivery work.

5. Agile methods deliver incrementally and therefore frequently — we call this small batch delivery. Non-agile methods deliver in big-bang (or big batch) releases and so infrequently. Corporate services processes designed for big-bang releases (that come infrequently, but with a lot of change) are disproportionately heavyweight for agile delivery releases (that come with small, but frequent, amounts of change).

6. Because they are delivering in small batches, agile teams need small amounts of frequent input and feedback from customers (or product owners) and stakeholders. Each increment (or even more frequently) they need to know what they should focus their efforts on next and how what they have delivered is meeting people’s needs.

Delivery teams need frequent and fast decisions to be efficient and effective. With big batch delivery, customer and stakeholder feedback is needed less often — because change is prevented as much as possible — but for greater amounts of time each time it is given. This can cause several points of friction: for example, the different approach to engagement may not be communicated well or even understood or there may be coordination issues. Stakeholders may also batch up decisions in a way that’s convenient for them but which blocks or slows delivery work (for example, monthly (or even less frequent) governance boards).

7. Agile teams are typically made up of the right mix of cross-functional team members to deliver a working product. Responsibility for delivery is shared by the team. In the established way of working, multiple separate teams of specialists work by passing documents and intermediate deliverables (e.g. requirements specifications or untested software) along a chain. Responsibility for delivery is spread throughout the chain or is held at a level above the chain in, for example, a programme management office one step removed from any delivery.

8. Agile projects may be relatively small and there may be many more of them. These projects often begin with short discovery and alpha phases. Work may stop on a project after a discovery or alpha or even during those phases. This means there are typically many more, but shorter, agile projects. In a pre-agile world, it’s more common to have fewer, but larger programmes of work. Non-agile project approval processes are typically optimised on the basis that this is the case.

When moving to agile, an increase in the number of projects being run, even though they are individually smaller, can place anticipated additional load on portfolio teams, programme management offices and individuals in finance, commercial and HR teams working with delivery teams. This load will continue until those teams adapt their processes to the new type of demand being placed on them.

9. As noted above, agile teams often start delivery with a short discovery phase, where they research the main user needs for a service, explore options for delivering it and generally get a sense of whether it’s worth building.

The idea of a discovery phase is that the team delivers new learning in each increment. Good agile teams know that their discovery work may lead to the project progressing no further. Indeed, it’s a big win for the organisation if the project can be stopped after discovery as it saves them the cost of developing a service that won’t be successful.

In non-agile teams, thinking happens before delivery and change is prevented as much as possible. There’s an assumption that once delivery starts it’ll continue through to the end. This is expensive and embarrassing if it’s later learned that the service isn’t delivering the outcomes it was expected to when it comes into contact with reality.

10. Agile teams can pivot and scale up or down very quickly, especially in discovery and alpha when you know least about what you’re trying to build. You may need more or fewer people with little notice. Non-agile methods assume team size and composition can be worked out in advance. Procurement methods, therefore, needn’t be responsive. Big batch delivery also leads to big batch procurement, which is time-consuming and often requires more governance and a longer list of approvers, slowing down delivery.

11. Agile teams often work towards outcomes rather than deliverables and features. If you’re a non-agile project tracker, this will require some adjustment in your approach. You won’t be tracking progress against planned deliverables and estimated effort but rather working with the delivery team regularly to agree how much money you want to spend to achieve which outcomes. You will probably also find that stakeholders will need to be educated to monitor progress differently.

12. Agile needs trust and empowerment in order to work. Those closest to the work need to be able to make decisions about what to build and how the work works. Teams communicate in very open ways, which should help foster this trust. Agile also comes with a set of artefacts and meetings, such as the daily stand-up at the team wall and regular show and tells that increase openness. Teams communicate face-to-face every day, sharing their work with each other and with those outside the team, including stakeholders and others in governance roles. Non-agile ways of working often require communication through documents and contracts. This doesn’t engender mutual trust. Also, these artefacts are often not available to those outside the project.

13. Spontaneous interaction is important in agile. Teams might swarm together to deliver a particular feature, and the best way to do this is with co-location. This doesn’t just mean that the team is in the same building — members sit together as well. If co-location isn’t possible, tools that support instant interaction are needed — but sitting together works about twice as well as remote working due to the need for frequent intra-team communication.

14. Information radiators are essential in agile. These displays (which might be handwritten, printed or electronic) are placed somewhere prominent near the team so that all the information that’s relevant to the work can be easily seen and tracked at a glance. This is also part of the openness and transparency that’s inherent in agile — passers-by can see this information as well as the team. In established ways of working, information is usually kept within the project team or with those who govern it. Increased transparency may be uncomfortable for some. In some organisations, using walls as part of the team workspace may be explicitly banned.

15. Hot-desking — where teams are mixed together and inter-mingle, with individuals often working on their own — doesn’t work with agile because it assumes you needn’t be sitting next to your team members (or near your team wall) to be effective. Agile teams interact most of the day and need to be near each other, as well as the information radiators that manage their work. Agile teams have different ways of working and therefore different space needs — it can be difficult to work in a quiet, open plan space — both for the team and for those in other teams in the space because agile teams talk to each other all day and need to have meetings in their team space.

16. Senior leaders need to become comfortable with agile meetings like the show and tell, which means going to the place where the work is done. Directly witnessing the work like this is the best way to understand what the team is doing and this proactive approach is very different to the non-agile progress reporting (using documents) that stakeholders may be used to where the team is often not present. It’s easier to hide the true state of delivery work with a report produced by a project management office than it is when the stakeholder is able to see the work and question the delivery team directly.

17. Agile has governance built-in. Agile teams report using approaches like the show and tell, A3 reports, information radiators and team dashboards for governance. Going to the place where the work is done, for example participating in a show & tell, is the best way for stakeholders to reassure themselves that delivery risk is being managed effectively.

Non-agile project tracking methods focus on reports comparing the estimate of what features teams said they would deliver before they started delivery work vs. the actual features they are delivering. That isn’t a suitable approach for novel delivery work, where it cannot be known in advance what features will be delivered or how long it is going to take.

18. Large non-agile programme teams often include roles that you would not see on an agile team — finance trackers, procurement specialists, HR assistants and administrative support roles. These are needed to support the heavy governance required of non-agile programmes.

In agile ways of working some of this work is still needed — good financial and procurement management and people development is needed in any delivery setting. But in an agile world these people would be close to, but not in the team.

19. Agile has risk management built-in. Taking an exploratory approach to delivery, by delivering work in small increments and adapting based on new learning is the most effective risk management approach for novel work. As noted above, agile teams often prioritise work that reduces uncertainty. Phased-based delivery is an acknowledgement that you know least about the work when you start it.

What does all this mean?

As noted in my earlier post on agile being radically different from what’s gone before, the mismatch in the needs of agile delivery teams and the services provided by corporate services teams optimised for non-agile ways of working can mean that pain ensues when agile is introduced. This isn’t anyone’s fault, it’s just that there’s a mismatch in the needs of agile teams and corporate services optimized to meet different needs.

Organisations have 3 solutions to this:

  1. Accept the pain, while understanding that this will get worse as your organisation does more agile delivery.
  2. Add bridging people — who can understand both the agile and the non-agile world — as adapters between the two worlds. This is expensive and again, the cost will grow as your organisation does more agile delivery.
  3. Align corporate services and agile delivery more closely by bringing everyone together to co-design adapted processes based on the user needs of agile delivery teams and the organisation. Iterate these processes as you learn more about how agile works in your organisation.

Good luck!

Thanks to Beck Thompson for content design assistance on this article.