How to survive in a world of agile delivery

If you’re a Project or Program manager and you haven’t had much experience in agile delivery, this can be a daunting experience. You probably don’t know much of the lingo and you’re probably not sure of how you need to operate. More than that, you probably don’t know what on earth the team is doing or how you can understand it.

There are several possible ways you can go:

  • Get out – find another project that doesn’t have all this “Agile” stuff going on. Go somewhere else where you can be comfortable with the delivery techniques.
  • Bluff – you can try to pretend you know how to do this, perhaps trot out a few buzzwords and try and fly under the radar.
  • Revert – declare that agile doesn’t work and “we’re going back to waterfall”. That way you don’t have to change, you just need to get everyone else to do so
  • Learn how to manage an agile project / program – this may at first seem outside your comfort zone, but chances are no one else there’s knows how to do it, or do it really well – otherwise they wouldn’t have asked you.

Get out

Sometimes discretion is the better part of valour – you may need to make a tactical withdrawal at this point. There are likely plenty of “traditional” or waterfall projects out there that you can contribute to. You won’t learn as much or challenge yourself in a new context, but that’s ok, you can reliably deliver the kinds of things you have in the past the way you know how to do it. There’s still value in that for certain contexts through this delivery mechanism – so look for something that suits you.

It can be quite frightening going into an agile context if you’re not used to it. Things seem out of control – you won’t have your trusty schedule and other tools that you’re used to to rely on to see things through. You might not know how to communicate with the teams – how to understand the risks / issues and get the information you need to do you job.

If this is you, then I thank you for understanding where you want to be and not trying to fake your way through agile delivery and deciding to bow out. So many program / project managers pretend to understand and don’t really change any of their behaviours for this new context and they’re better off not getting involved – it will just lead to failure.


In this option, you may not understand agile delivery – or you may think you do and just don’t want anyone to notice. You decide to bluff your way out of it – or “fake it till you make it”. It’s a nice idea, and you might get away with it for a little while. If you pick up on some of the buzzwords and kick off a few basic ceremonies, no one will notice that you really don’t know what you’re doing……will they?

This is a great option if you don’t want to change your behaviour too much. The teams can go “agile it” over there, but I’ll manage it with my traditional tools and techniques across all of that. What could possibly go wrong?

In the context where a number of people are new to agile and don’t know any better, you’ll probably get away with it, until it becomes noticeable. Essentially, the dynamics of the two paradigms will start to contradict each other and you may actually have to switch your approach to “Learn” instead. In which case, will you have made the switch in time or is it too late? It’s likely that if you’ve left it till this point in time, there’s some kind of problem that surfaced and you’re getting called upon / called out to fix it.

If people in this program actually have some agile delivery / management experience, they’ll probably call you out on it. When this happens, you can try one of the other options – “Get out”, “Revert” (perhaps you might need to remove / silence the agile delivery manager to do so) or “Learn”.


This can often happen – particularly if you’re not well experienced / trained for this kind of delivery. What happens is that often your traditional project / program managers come into the agile context when they probably should have gotten out. Often these are the fakers that don’t understand what it takes to manage agile delivery, thus they don’t set things up for success from the beginning. Eventually, you’ll see the program / project starting to go off the rails.

If the scenario is one where everyone is entirely new to agile delivery, you would have had to set up a lot of support initially for this to occur. Both at the team level and the management level – there are different techniques and practices that will need to be in place. You’ll have a lot to “Learn” – plus you may need to bring in outside help to coach and / or recruit some more experienced practitioners and inject them into the team. But fundamentally, at the program / project level if you’re in this circumstance then you’re probably lacking agile management skills. Often, those that tend to revert miss this point – so to avoid reverting, you’ll need to look to “Learn”.

Often things go off the rails when things start to work at scale – when we had one or two teams working in an agile way, things were fine and we could manage it in that way. When you have to scale across multiple teams, perhaps multiple vendors and bring things together across an organisation, this is often when things start to go wrong. However, at this level it’s not a team problem it’s a management problem. Guess who’s going to get called upon?

Or, another scenario is that you tried to move too quickly too fast. You just can’t get to agility overnight – it takes time to get to a decent level of maturity. If you planned that you’d be “agile” instantly, or very quickly, then you were probably planning to fail from the beginning.

You probably knew this would happen – they should have just done things the old way from the start. In which case you declare “We’re not doing agile anymore, we’re going back to the way we used to do things”. I dare say that things haven’t really changed to begin with – you’re likely using you’re old practices because you haven’t supplemented or replaced them with 21st century knowledge work management techniques. Perhaps you weren’t sure how these could work together or haven’t seen them used successfully.

In this case, you may have a group of really talented agile practitioners at the team level. In this scenario “reverting” will mean they might need to change their behaviours and practices. They likely won’t want to do this and will either resist or leave. In any case, you’ll suffer from an alignment problem or you might stall because the skills have left the organisation. Either way, things are going to get worse before they get better.

If you’ve gotten to the point of reverting, then there was probably already a problem from the beginning and perhaps you should have tried one of the other options such as “Get out” or “Learn”.


If you’ve selected this option – congratulations, you’re about to venture into a new world where you’ll have new skills and understanding of how to manage knowledge work. But the good news is that you don’t have to throw away all of your existing skills – things like risk management & vendor management are still very relevant to agile delivery, it’s just that we view these through a slightly different lens.

You will need to give yourself time and space to learn – you won’t be an expert overnight, so make sure you plan to have the capacity / time to be able to learn. If you’re considering taking on an agile project / program in the future, then this is the optimal time. You’ll have some time to learn what you need to do for day 1 when you land on that program. Often managers new to this type of delivery, don’t set things up from the start. You’ll know from you’re existing skill base that anytime this happens, regardless of the method, you’ll be behind the eight ball from the start.

If you don’t give yourself the time and space to learn, effectively you’re really in the “Bluff” space, you just don’t know it yet. Often people talk about learning, but their actions clearly don’t give enough time and investment in learning so they might not realise that they’ll need to resort to the “Bluff”. If you’re in the learn space, please make sure that you’re actions match your intent, otherwise you might find yourself in a world of pain and stress.

If you don’t have time before you start you’re next assignment, you’re probably going to need some help right away. Find an experienced agile manager / consultant / coach and bring them on to set things up that you’re not aware of. Watch what they do, be curious and ask them along the way why they’re doing what they’re doing – you’ll learn a lot this way.

If others on the program are new to this way of working, you might need to organise similar support / capacity for learning for their roles as well. They’ll be supporting you along the way, so you need to make sure you’re all on the same page.

You’ll need to get an understanding of how to manage down as well as manage up. How do you understand what the teams are doing and how it all comes together towards the aligned goals. Plus, how do you ensure that you make reliable commitments to your stakeholders and customers in this kind of world? You’ll need to understand how to manage these expectations in this different paradigm.

At some point in time you’ll want to understand for yourself how agile systems of work can be created and improved on. Your best bet for this is to actually get some formal training on this, sooner rather than later. To really get the most out of this, you should consider becoming a Kanban Management Professional. This is made up of two courses (Kanban System Design & Kanban Systems Improvement) which will give you a practical foundation from which to manage knowledge work and achieve real agility.


If you’re a project / program manager and you’re new to agile delivery you have some options open to you. However, in the end the only two real options are to “Get out” or to “Learn” – the others are only temporary stop gaps. Although there are many different pathways to learning, you may want to learn about Scrum or XP to understand the things going on at a team level. You may also be in an organisation that practices SAFe, in which case its program and portfolio layers are Kanban anyway, however they tend not to go into enough detail about the particulars of how to do this. Plus, you might have other teams working in non-technology based areas and you need to bring them all together. Kanban can do this for you, so why not go to the source and achieve true agility. Read more about in our blogs, or check out our training programs.