ADKAR Change Management Model

Hopeful young woman wanting to change

ADKAR is a goal oriented change management model for individuals and organisations to help guide them through changes and create lasting change. As both an agile coach and a personal coach, I find this model incredibly useful. This is something that we can all use ourselves in our work and personal lives to help form new habits.


Key question: Why do you want to change x from the way it is now?

The first point of any change is to have an awareness of the need to change, and then building an understanding of it. If this change is coming from yourself then you should already have an understanding of this. If it’s a change for an organisation, you’re going to have to ask around to find out. If the decision has come from a committee then finding that why may be difficult. Find out who the key people who have made the decision to change are, and start asking them questions.


Key question: How will I benefit from making this change?

Once you have your why, the desire to change is easier to foster. This is the time to create passion and a sense of purpose around the change by selling it. Whether it’s change for an individual or a group, there needs to be a commitment from everyone involved towards the change in order to make it happen in the first place. Organisations need to employ change agents to support the change, and individuals need to create a network around them of people to help them stick to their decisions.


Key question: What behaviours do I need to change for the entire change to be successful?

Now that you’ve built up some passion, it’s time to gain the knowledge that we need in order to enact that change. There are plenty of resources available out there, you’ve just got to make the most of them. If you have a budget, then look for training both online and IRL. If you’re lucky enough to be in a major city then you’ll probably find groups of other people exploring the same kinds of things that you are. Perhaps you can take an evening class, or take a trip down to your local library and do some old fashioned book reading. Whatever it is that you need to learn, go and learn it.


Key question: What can I use to trigger me to remember to behave differently?

Knowledge is great, but until we’ve changed that knowledge into understanding and habitual behaviour we’ll sit in the hardest part of change. This is the part of the model where we actually start making those changes. Whilst you’re starting to make the change things are going to be slow and awkward because you’re having to really concentrate to make sure you behaviour in the new way. Persevere through these times. The longer that you practice the new behaviour, the easier that new behaviour will become.


Key question: Who can I ask to help me maintain my new behaviour by rewarding me when I exhibit it?

We’ve all started a new habit (usually around January) with good intentions to keep it up, but over time find ourselves falling off the wagon and back into old habits. Either find a way that you can reward yourself, or ask someone else to comment when they see the new behaviour. If you’re in an organisation and have the luxury of a change agent, then ask them to create a process for everyone to be able to easily call out when they see that people are successfully adopting and exhibiting the desired new behaviours.


When you’re thinking about making a change, take a moment to consider this model and what it means to making the changes you want. Create a passion within yourself to making this change, find out all the information you need before you start changing your behaviour, and finally find yourself a support network so that you can find that emotional reward for being successful.

Story Points Estimation for the Benefit of the Team

Team sitting around table discussing a piece of work for estimating in story points

I’ve heard as many explanations of story points as teams I’ve worked with. I’ve seen a team use equations to get from T-shirt sizing to story points to time prediction. Another team I worked with estimated user stories in story points and estimated sub-tasks (hello there, Jira) in hours. When I ask a team why is it that they estimate in story points, the explanation I typically hear is, “We’re an agile team.” In an agile environment we should be questioning what the value of doing everything we do, and we shouldn’t overlook estimation in our inquiries.

Complicated vs Complex

Complicated pieces of work are pieces that we know about. Mostly, we know what it is that we don’t about the work and therefore can have a good guess at how much effort it’s going to take for us to complete the work. If we’re really lucky this work can slip into simple and it comes to us almost for free.

Complex pieces of work are pieces that we don’t know about. Some things we may not be able to know anything about until we have a go at. If this is the case, we should be considering creating a spike to find out before we start work.

How do we as a team agree whether we think a piece is complicated or complex though? Story points. Over time, a team will start to understand that a large story point estimate means that the piece of work sits more into complex and less into complicated. Therefore when a team estimates work high up the story point scale, they know to look into the questions they don’t have answers to yet. A spike is a piece of work to quickly look into very specific questions in a set time scale. At the end of their investigation, the team should throw away all the work that they’ve done (so quickly that it should never be allowed into production) and bring the things they’ve learned into the original piece of work.

Sufficient Refinement

Another reason why the team may have estimated a piece of work high on the story point scale may be because the piece of work is just too large. When work is too large, people build in extra contingency into everything around that piece of work, including their estimate. These are a few questions the Scrum Master can ask the team about the piece of work to help them find out why their estimation is high.

  • How much information do we have vs how much do we need?
  • Whose perspective is the information written from?
  • Is there a clear reason why the piece of work is being requested?
  • Do we know exactly what the measures of success are?

Sometimes a team has everything they need and everything is clear, but there’s just too much to do as one piece. Like all large things, large pieces of work move more slowly than small pieces of work. Take a look around the web for ways to break down user stories. There are some interesting and creative ways to look at your work and find different ways to tackle it available out there.

If you think that refinement is your problem, perhaps think about facilitating some Three Amigo sessions in between formal backlog refinement meetings.

Avoiding Silos

Something that should scare everyone in every organisation is how concentrated the knowledge of their organisation is within their organisation. I’m sure we’ve all heard stories of someone leaving an organisation and them being the only person who can <insert important function here>. As part of the refinement and estimation process the team must be talking to each other about what they collectively know regarding a piece of work.

When it comes to estimation, this typically manifests itself by the individuals having wildly different estimates. Ask multiple members of the team to explain their estimate and you may find out that one person has never touched part of the system and that another is the only person who has. What a better time than to invite the team to collaborate more intensely than they’re used to doing so that the knowledge can be spread out?!

Facilitating Estimating in Story Points

There are some gotchas of using story points that are easy to fall for if the facilitator is not looking out for them.

Only the Development Team get to estimate. Not the Product Owner, not the Scrum Master, not the boss. Only the people who are potentially going to do the work get a say on the estimate for that work. This includes BAs, devs, QAs, and anyone else who falls into the ‘does the work’ category.

We’re trying to find out what each individual thinks as an individual to understand the team as a whole. This means we need to avoid groupthink. I always provide teams with planning poker cards for two reasons. First, when a planning poker app is open and being paid attention to, then those twitter and facebook notifications are oh so appealing. Second, due to the nature of a phone, it is easy for one person to see what the person next to them has selected.

Ask the team to select a piece of work to discuss ready to estimate. Once there are no more questions about what the work, then we’re ready to estimate. Ask everyone to choose a card and place it face down on the table in front of them once they’ve chosen. Wait until everyone has placed their choice down, and then ask everyone to turn their card over and hold it up for all to see.

Check for disparity, and ask at least the highest and lowest voters to reveal why they chose these results. Once the discussion that innevitably start have finished, invite the team to vote again and guide them through the same process of placing a card in front of them and revealing as a group.

Check for agreement of a high estimate. What looks like high is different for every team, but typically sits around the 13 mark (5 – 20). Lead a discussion with the team to find out what their concerns are. Is this too big a piece of work, or does no one know enough about it yet? Perhaps only one member of the team hsan’t voted high, and that may be indicitive of a silo. If you’re ready to esitmate again, then do so.

If a concensus cannot be made, take the piece of work away for further refinement. Maybe you want to break it down, maybe you want to do a spike or two, maybe you need to do some knowledge transfer. Work out which, do it, and then bring this back to estimation and try again.

Once there is a concensus, you have completed the process and have a high confidence that this is a piece of work that you’re going to be able to complete quickly and with relative ease.


As you can see, story pionts can tell a team information about the work that the individuals that make up the team can find hard to uncover in other ways. Understanding the stories that story points tell us allows a team to use estimations as a valuable tool, and not just a reporting mechanism for their management.

Three Amigos to Enhance Agility

Three amigos meeting

Three Amigo sessions are a great way to get people together to talk about a ticket. The structure ensures that they are quick and have representatives of the groups interested in the ticket. The best time to use one of these sessions is when you have found something emergent before or during development. Welcoming change late in development is one of our agile principles, and Three Amigos is a practice that can help to make a change as painless as possible. Continue reading “Three Amigos to Enhance Agility”

Increasing Team Engagement in Retrospectives

Team having a fun retrospective

I love retrospectives. They’re one of the easiest and most effective ways of directly implementing an agile principle. (At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.) Retrospectives should be something that the team looks forward to because they know that it means that during the next iteration they’re going to improve. Unfortunately, this doesn’t seem to be the case for all the teams I meet. In this post I’ll talk about how you can improve your team’s retrospectives so that they can be excited about them and improve their ways of working. Continue reading “Increasing Team Engagement in Retrospectives”

Doing Agile, Being Agile

Over the last few months I’ve heard many experienced agile practitioners talk about their thoughts and feelings around agile adoption in London, and the wider world. A common theme between them all has been that there is a difference between saying that one is ‘doing’ agile, and actually being agile. Nearly everyone I’ve spoken to who has an active interest in agile practices has stories about a team treating agile like they would PRINCE2 or any other project management strategy. I’ve heard of and seen teams follow scrum to the letter, and in doing so completely miss the point of it. Agile is a verb not a noun, and it is worth reflecting upon that whenever we attempt to do something in the name of agile. Continue reading “Doing Agile, Being Agile”


This is another post resulting from my recent review of the notes I made when taking my CSM course. I love a good mnemonic. There are plenty of words that I can only spell by remembering some strange sentence. I especially like it when a mnemonic relates to the data that one’s trying to remember, and INVEST is certainly that. Continue reading “INVEST”