Questions

This is a test answer

The answer to this one depends on how you're running your agile project, for two reasons.

The first is that an agile approach is usually brough to life by following one of the different agile frameworks which exist, which often set out the roles that need to exist and the responsibilities those roles hold.

The second is more fundamental to what agile is. Teams following an agile approach should be able to inspect and adapt not just what they work on but also how they work on it. Through doing this, they may find that they work better by adjusting the roles and responsibilities within the team, and as long as it doesn't damage any of the other teams they may be working with, that's just fine.

The best way to get started though is often to follow a set framework, and adopt those roles and responsibilities to start with, then inspect, adapt and improve them to suit your needs over time. One of the most widely used frameworks is Scrum, which brought us such roles as the Product Owner, Scrum Master and Development Team Member. Alternatively, if you're talking about Agile Project Managers, you're probably talking about the DSDM framework, or if you're scaling things up, in Scaled Agile Framework (SAFe) you get roles like Product Manager and Release Train Engineer.

So as you can see, there are potentially a number of different roles and responsibilities you could adopt to take an agile approach, and they often depend on exactly which agile approach you are taking. A word of warning though. Each of the different frameworks in agile has been carefully thought through and tested over many years. Whilst it's fine to inspect and adapt them based on thing you learn through trying them out, it's best to try and avoid customising them too much right at the start.

If you're not careful, you can end up in a situation where the roles and responsibilities get heavily customised back into your existing ones, meaning all that changes is the job title, which is at best a waste of everyone's time, and at worst a confusing mess. If you're going to adopt an agile framework, adopt it properly, see what happens, and then learn and grow from there.

Hah! We're not getting drawn into this one...

Seriously though, the reason we laugh is because for some people, the debate around the pros and cons of the different agile frameworks out there becomes something like a fanatical war, with their side being right, and the other side being the enemy. So I'm afraid we can't answer this question specifically.

In our opinion, all the frameworks out there have their value in certain contexts. None of them was invented by people with bad intentions, and all of them have their own fans for their own very good reasons. If you want more on this topic, you could take a look at the Agnostic Agile Oath, which includes the statement "I will not be dogmatic when it comes to lean or agile frameworks or methods, because dogmatism is non-agile, does not benefit my customer, my community or lend itself to continuously improving my own practice". We tend to agree.

Rather than talking about the 'best' framework, if you wanted to talk instead about which are the most popular or widely used frameworks, then you could look at the VersionOne 'State of Agile Survey' which comes out every year, and reports on which frameworks people are using the most in the last year.

Perhaps though, the only answer to this question is to say that the best agile framework is the one that works best for you and your organisation.

This question comes up *a lot*. If you're a project manager reading this and worrying about your job, first of all, try to relax, all is not lost.

It's true to say that in agile as a broader mindset, and in the specific frameworks you can use to take an agile approach, there is very little mention of project managers. In fact one of the only agile frameworks to mention them specifically is DSDM.

On top of this, you sometimes get agile consultants and coaches that are quite passionate about sticking to the way things are prescribed, so sometimes they go around telling people that all of the project managers must be removed, with little care for what happens to them afterwards. Whilst it may be technically correct, it doesn't seem like a helpful approach.

The fact that it exists as an approach in many ways reflects the tension between traditional and agile approaches to delivery. In many situations, project managers are seen as holding views that make agile more difficult, if not sometimes impossible. Traditional project managers often want to write the delivery plan and assign tasks to people, when agile teams want to write their own plans and decide amongst themselves who does what. Project managers often like to try to get people to stick to timescales, costs and scope requirements that have been decided up front, when agile teams know that things often end up better if they are allowed to change as they go along. It's undeniable that a tension often exists between the two, so this does need to be faced into and resolved. Thankfully, there are a number of different ways of doing this.

The first and perhaps most obvious way to fix things is to see if you can retrain project managers to take new roles within your agile framework of choice. After all, these people often have tons of skills, contacts, experience and organisational knowledge that it would be foolish to throw away.

If you're the sort of project manager that likes supporting teams, getting problems dealt with, coaching people and generally doing what's needed to help the team be the best that it can be, then you might want to take a look at the Scrum Master role in Scrum, and see if it sounds like it might be interesting. You'd have to let go of your desire to tell people how to work and what to do, as that's largely up to the teams themselves to figure out now, but there's still lots of great work to do in serving and supporting the team.

Alternatively, if you've always been into the details of what is getting created, managing stakeholders and taking their views on board, looking after the financials of how much is getting spent against how much profit is likely to be generated, keeping people up to date on how the delivery is going, then you might want to look at whether the product owner role might be a good one for you to move into.

There are lots of roles within various different agile frameworks, and as long as you're prepared to make the mindset shift from commanding, managing, directing and controlling, to supporting, helping, coaching and facilitating, then you might well find an agile way of working is less stressful and ultimately more enjoyable.

Another technique that has been tried out and worked well at some larger organisations has been to retain the project managers, and let them do all of the work that the organisation still needs to have done, but that distracts the team from delivery. Whilst in an ideal world an organisation moving to agile would look to cut out as much waste from its ways of working as possible, sometimes this takes time to achieve, or is made more difficult by the requirements of an external regulatory environment.

In situations like this, the project managers can be used as a buffer to keep the organisational waste, bureaucracy and noise away from the teams doing the work and working in an agile way. You have to be careful here that the project managers do in reality act as a buffer, and don't start coming to the teams enforcing the consequences of the organisational noise on to them (such as insisting on fixed timescales with fixed scope). However, as long as they do, then this setup can run quite well.

In short, there are practices and behaviours that some project managers display that are not helpful, and can even be actively harmful, to people and teams wanting to take an agile approach. These have to stop. However, try to separate the practices and behaviours from the people themselves. The people often have years of valuable skills and experience that it would be foolish to throw away. Far better to find them a new role, one that helps the agile adoption grow even stronger.

Before you decide which agile certificate(s) to get, you need to ask yourself what you want them for. There are a number of different reasons for gaining certificated status in an area of agile, each with their own pros and cons.

First though, for those who have no idea what agile certificates are, let me explain. Agile is quite a broad field of knowledge these days, and there's lots to learn in lots of different areas. As a result of this, a number of different organisations started offering training courses in their specific areas, and when you complete these courses, or pass an exam at the end of the course, often you get a certificate of achievement, which helps to prove that you've studied what you've studied.

The slight problem is though that agile certification has in some ways become an industry itself, with so many different courses and certificates out there, it's can be hard to know which ones to get. Let's have a look at some of the reasons why you'd want to get a certificate.

The first is for the sense of achievement you get for yourself. Some of the exams you need to sit for some agile certificates can be pretty tough, so getting a certificate for passing can add to the sense of achievement, and keep you motivated to keep learning more. Given agile is all about learning and improving, if certificates are what keep you personally motivated to keep learning, then get whichever ones you'd find most interesting.

The second reason is to 'close the learning loop'. That is to say that sitting an exam at the end of a course makes you think through what you've just learned some more, and so helps to embed the learning even better in your brain. This is a great reason for getting a certificate, but it only really applies with some courses, and sometimes the exams at the end of a course are so easy that they don't help you learn very much at all.

The third reason is often the more common one, and is perhaps the reason you ended up reading this page. With so much money and so many jobs floating around the agile space at the moment, people get certificates because they think doing so will help them earn more and be more employable. Being honest, this reason doesn't apply anywhere near as much as it used to. Partly because so many people have got certificates now that the perceived value of many of them has decreased, and partly because so many certificates have come along that are so simple to collect.

Good agile people, and good agile recruiters, know the difference between the different certificates, and often collecting armfuls of them and putting them on your CV can make you look like someone who just collects certificates for the sake of it, rather than doing something equally if not more important - learning agile skills and competencies through direct experience in the workplace. As some people say, they value 'scars not certs', that is to say they'd rather employ someone with lots of experience gained through good times and bad times, than someone who's just spent time attending courses and passing exams.

Having said that, there are a number of certificates out there that require on the job experience in order to be gained. The Scrum Alliance's Certified Team Coach (CTC) and Certified Enterprise Coach (CEC) certifications both require lots of proven experience to be demonstrated before they are awarded, as does Scaled Agile Framework's SAFe Program Consultant Trainer (SPCT).

Everyone's experiences and opinions of agile certificates is different. The important thing to remember is that what counts at interview, and once you've got the job, is knowledge that you can actually use to add value to the situation you're in. Some people are motivated to gain that by attending courses and gaining certificates. Other people never get any certificates at all, and instead become great agile practitioners through direct experience. Most people seem to blend the two approaches.

The trick is to find the approach that works best for you, and use it to continously grow and develop your own skills and experience. That's probably the most reliable path to be a great agile practitioner, and reaping the rewards that can go with that.

Short Answer: No.

Longer Answer: Sort of.

You see, there's no one to one mapping between traditional and agile roles. If there were, there probably wouldn't be a whole lot of difference between traditional and agile approaches, and probably very little point moving from one to the other. So a product owner is not just a new name for a project manager, and the two roles are very different in both what they do and how they do it.

However, that is not to say that there aren't things that needed doing before agile that still need doing once you move to agile, and someone will be needed to do them.

The simplest way to understand this is to say that the product owner role is as the 'single wringable neck' for the thing that is getting built. That is to say, they are the person that is accountable for its success. For example, it's the product owner that decides what the most important things are to work on next, that is closest to the customers / stakeholders for the product when it comes to keeping them engaged and gaining their feedback, and that is ultimately accountable for the success or failure of the product in the marketplace. It is their product, they own it, hence their job title.

What exactly this looks like will probably differ from organisation to organisation, but it often means traditional project manager responsibilities such as budget allocation, work prioritisation, reporting, stakeholder management and final sign off of work before delivery now move to the product owner. Other tasks may fall to someone like the Scrum Master if the team is following the Scrum framework, and some tasks that used to happen might no longer be carried out at all. For example, a big phase of testing carried out before a big release and go live process may be replaced entirely by continous testing, continous integration and continuous deployment, right throughout the process of delivery.

How some of these tasks are done often changes as well. For example reporting is now more likely to be done by demoing actual working outputs to real people and getting feedback on them, rather than producing slide decks and Gantt charts, but those are subjects for a different questions.

In practice though, especially in the early stages of moving to agile, a new product owner having to take on all of this work can be tricky, and they may choose to delegate it to a project manager if they wish. However, the important part to remember is that the product owner remains ultimately accountable for these areas, even if they do decide to delegate.

This is a really interesting question. Knowing the reasons for taking an agile approach can really help you to understand what agile is and why it recommends many of the things that it does.

To answer it, we have to take a look back at the roots of agile. For most of the 20th century, especially after the end of World War Two, the world of projects and getting stuff done was very much shaped by the work of people like Frederick Winslow Taylor and his Principles of Scientific Management. This popularised the idea that things got done better if processes were standardised and people made to follow these processes. For Taylor, there was often 'one best way' of doing things, and this could be discovered, documented and followed.

To go alongside this, the idea spread that not only could processes be standardised and enforced, but that plans for getting things done could be specified up front, with the workers then being made to follow the plan. This led to what is often called 'waterfall' project management, where plans and processes are decided up front, and then followed. So if the plan or the process fails, this is obviusly because people were following them closely enough, or there wasn't enough planning or process standardisation, right?

Well, no. Often the problem turned out to be that standardising plans and processes then sticking to them no matter what doesn't take account of the external reality. A reality where things often change, where new information emerges as the work goes along, where unexpected events occur. When these things happen, you can often find that your plan and / or process no longer works as you expected it to, and sticking to it without taking into account the new reality can cause large amounts of harm.

This is where agile comes in. Agile, as first brough together in the agile manifesto, is all about ideas like prioritising 'responding to change over following a plan' and focussing on 'individuals and interactions over processes and tools'.

So in many ways, agile is a response to complexity and uncertainty, where you can't know up front what the right thing is to build and you can't even be sure of the right way to build it. So instead of trying to decide both of these things at the start and stick to your decisions no matter what, you instead take an approach that continously test and learns, or as agile people often say 'inspects and adapts'.

So if you're wondering when the right time is to use agile, it's likely to be in those instances where you can't be sure what the right thing is to build, or what the best way is of building it. How you decide which areas of your work that applies to is up to you, but the chances are that anything you do could likely benefit from a mindset of continous curiosity, where you're constantly looking to gain feedback and make changes based on experience.

With this in mind, sometimes the best way to decide when to use agile is to do what agile recommends, and try it out, see what happens, and use the experience to decide what to do next.

The short answer is, we don't panic. The longer answer is more interesting though.

One of the defining characteristics of an agile approach is that it handles change requests really well. In fact it doesn't just handle them, it welcomes them with open arms. As the agile manifesto puts it, we "welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage".

The reason for this is simple. The whole point of adopting an agile approach is to be able to change what you're doing based on feedback and learning. If you're working in a marketplace that's rapidly changing and evolving (such as technology and digital), then making big plans and spending a long time delivering them might mean you build the wrong thing, or what you're building becomes no longer relevant. So you want to be able to change as you go along, and the better you can handle change, the more agile you can be.

Of course, this doesn't necessarily mean it's helpful if someone comes along and makes changes constantly, or expects massive changes to be made just a day before something is meant to go live. Good agile teams are generally pretty quick and flexible in what they do, but they still live in the same universe as everyone else, and there are only 24 hours in a day.

If you look at an agile framework like Scrum, teams using Scrum still plan out a chunk of work and try to deliver it in a chunk of time called a sprint. If too many changes need to be made to what the sprint was meant to deliver, they cancel the sprint and plan out a new one.

The three things teams really need to get to grips with to handle last minute changes though are continous improvement, a focus on quality and only working on small chunks of work.

If teams are working on continuously improving how they work, then they typically get better and better and delivering things, so making changes becomes much more simple. In short, they become proficient at 'turning on a dime for a dime'.

If teams focus on quality, then changes often become much easier to handle. Think of a production line. If each work station produces something that works first time, then the work flows through the system much more easily. If things get passed down the line broken, and have to be handed back up the line to be fixed, then pretty quickly the system can grind to a halt, especially when changes start adding to the confusion. From a technology perspective, it's much easier to change code that has a full set of tests running on it, as if something breaks, you know straight away where the problem is.

Finally, breaking work down into small chunks really helps as well. If all work gets handed to a team as small chunks, then it's much easier to separate out and prioritise the most important changes first, and get a better handle on what the changes are.

There's much more to all of these concepts if you want to delve futher into them. For now though, just know that good agile teams should welcome late change requests, and be constantly getting better at how they handle them too. Just remember, the people on these teams are only human, and most humans can't perform miracles.

This is a question that often comes up when people start looking at an agile framework like Scrum. Scrum sets out various roles, meetings and events to set up in order to use the framework, and one of these events is called a sprint.

A sprint is in essence just a timebox, a chunk of time within which a team will aim to complete a certain number of things. Technically, a sprint can be one month long or less, but you typically find Scrum teams run sprints that are between one and three weeks long. The sprint starts with a planning meeting, to plan what to do in the sprint, and ends with sprint review and restrospective meetings, to inspect what was done and how it was done, with a view to improving each of these things in the next sprint.

The problem this creates for some teams though is that they're used to working on things that take longer than one to three weeks to deliver, that even take longer than a month to deliver. When you've got work like that, work that could stretch across many sprints, what do you do?

Well, the incorrect but all too common answer is just to roll things over from one sprint to the next. So at the end of the sprint you just tell people you worked on this task, then at the next sprint planning meeting you pull the task into the next sprint, and just carry on. This is dangerous for a whole number of reasons.

The more you just roll things over and work on them for long periods of time, the longer you're waiting to get feedback on them. The longer you wait to get feedback, the higher the chances are that you're building the wrong thing, or building it wrong. Agile is all about being able to respond to change and new information by continuously running experiments, getting feedback and learning about what you're doing.

On top of this, large tasks that take many weeks or months to complete provide much less visibility into what is going on, which makes spotting problems and fixing them much more difficult. Transparency is a crucial part of many different agile frameworks, and for good reason. You have to make things visible in order to inspect them and adapt them. If a piece of work is just written up at a very high level as one big task, and it gets delayed, it's much harder to see which element of the overall task it is that is causing the delay, and as a result it's much harder to do anything about it.

Finally, by waiting weeks or months for the whole task to be complete, you're delaying the point at which the thing you're building could start to be put in the hands of customers, and start making you some money. All the time you're holding onto a piece of work, it's just costing you money to store and maintain. As soon as you can release that piece of work to customers, it stops costing you money and starts making you money instead.

So what's the answer to these three problems. Well, it's the same answer for all three, and the same answer to the age old question, 'How do you eat an elephant?'. Simple, you just break it down into smaller chunks. Once you start to break tasks down, you can start to finish them and get feedback on them more quickly, get greater transparency into which tasks exactly are the ones that are slowing everything down, and you can start to get things shipped to customers and start making some return on your investment.

But how do you break tasks down? Often some tasks look like they can only ever be big, and even if you can identify all of the different 'sub tasks' that are involved, you still feel like you need to complete them all before you can show anything to anyone, or ship anything to a customer.

The answer to this comes in a practice often called 'story splitting' or 'vertical slicing', which is a series of techniques for identifying a simple version of the overall task, delivering that, then identifying the next most simple version of it, delivering that, and so on.

For example, in The Lean Startup, Eric Reis describes the story of Nick Swinmurn and Zappos shoes. Nick thought there might be money in an online shoe store, but rather than build the entire store before launching it to customers (a big monolithich task), he set up a simple website, went to local shoe stores, took pictures of their shoes and put the pictures and prices on the website. If people bought a pair of shoes via the site, he went back to the store, bought the shoes, and mailed them out to the customer. It wasn't a sustainable model, but it gave him feedback early on as to whether it was worth continuing with the idea. Turns out it was, and Zappos is still going strong.

That's just one approach to slicing up the elephant, there are a number of different approaches you can try documented here.

This is not to say it is easy. Breaking work down into smaller chunks can be tricky when you first start out, and you're so used to working on big tasks that take many months. It's a crucial one to start to tackle though, as without it, you'll be locked out of so many of the benefits an agile approach can provide.

Sometimes moving to an agile approach can be hard. For example, it may seem like some parts of an agile framework would work in your context, but others clearly won't. Alternatively, it may be that you can follow an agile framework, but there are still things your organisation needs you to do on top of what the framework says. Producing Gannt chart plans for example, or monthly RAG status reports, or committing to a fixed scope by a fixed delivery date.

When this happens, people do often ask whether they can blend 'waterfall'(traditional project management) and agile approaches in their work.

The short and literal answer is that technically speaking of course they can. Just like you can mix any food ingredients you like with any other ingredients when cooking a meal. The bigger question though is whether doing so is a good idea? In both cases, the answer is probably not.

Whilst you can blend watefall and agile approaches, very often doing so leads to conflict between the two, and sub-optimal outcomes overall.

For example, those Gantt charts you're asked to produce. How much value do they add, truthfully speaking. How quickly do they go out of date? Would anything be significantly different if they weren't produced? One of the principles of the agile manifesto states 'Simplicity - the art of maximising the amount of work not done - is essential'. So if you're mixing waterfall with agile, are you really maximising the amount of work not done? Straight away, the two approaches conflict.

You get even bigger problems when you try to mix waterfall approaches like delivering a fixed scope by a fixed date with agile approaches. Agile is about 'responding to change over following a plan', so if your scope and timeline are fixed, how can you respond to change? In reality, doing something like this just leads to teams standing up next to whiteboards covered in sticky notes, wondering why they're being told to be agile when they have no ability to change anything.

So yes, you can mix waterfall and agile if you want. But the more you do so, the more likely it is that the two approaches will conflict with each other, causing you to waste time and effort that could have been better spent doing one approach well.

The first step to understanding the agile methodology is to understand that there is no such thing as the agile methodology. If being agile were as simple as following a new methodology or process, you'd probably be doing it already.

Being agile is much more about changing your mindset, about seeing the world differently and applying different thinking to the problems that you encounter. The best way the mindset has been summed up is in the agile manifesto, but the important thing to remember is that agile is about responding to change, constantly looking at what is happening around you and using that information to decide what to do next. This is something agile people often call 'inspecting and adapting'.

This approach applies both to the work that you do, and how you do that work. So as a result, how you do your work should be constantly changing based on what you learn from the work you've just done. This means there can never be an agile methodology, as everyone's application of agile should be unique to their specific context, based on what they learn about it.

That said, there are many agile frameworks that give you tools and techniques to use which help bring the agile mindset to life, and for many people they're a good place to start. However, a framework is not a methodology. A methodology tells you what to do. A framework gives you principles and practices you can use as a appropriate in your own context.

That's the true challenge of becoming agile. Finding out which principles and practices help you constantly inspect, adapt and respond to change in your own specific context.