Posts Tagged ‘adkar’

I have a new team. It is a fairly large team with varied experiences working in an agile fashion. We’re also still figuring how design fits into our overall value-delivery chain (as an organisation, not only as a team) and recently I found myself having to help clarify some expectations and terminology which had led to some confusion and conflict.

At this point, if you haven’t read these already, I’d recommend you read these two blog posts for some background context:

  1. Change Managing our Backlog Refinement
  2. Overlaying needs, phases and quality concerns

The conversations I had with various team members led to me creating this rough visualisation of what where you are in your Epic and backlog refinement conversations means for the necessary level of granularity of front-end design.

A caveat: I believe there could be a third axis – one for “figure out what the problem is” (Product Discovery), but due to where my team was in the delivery cycle, I left it off to reduce confusion. This scribble assumes we know what problem we need to solve.

UX vs ADKAR

So how does the above work?

The vertical (y) axis represents where your Epic is in its “quality” journey. Are we still just focusing on getting something working (Functional/Reliable)? Or are we polishing a feature that is almost ready for release or is already released (Usable/Pleasurable)?

The horizontal (x) axis represents where in the refinement process we are with the team for the piece we’re hoping to take into our next few sprints.

The colourful blocks (intersections) represent what level of visualisation the team probably needs for their refinement conversation based on x and y. So if we’re just starting on an Epic and want to get to a slice that does the basics for internal testing or Beta feedback (usable) and the team have had a conversation to understand the problem and are starting to think a bit more how to slice the next chunk into pieces of user value (Break-down), then you probably don’t need anything more granular than a wireframe to work with to have the conversation and figure out the next steps. If you’re already bringing pixel-perfect designs into a conversation at this point, there’s a lot of risk that there will be expensive re-work required. There’s also a risk you’ll miss out on a more creative approach/idea because the team will be less willing to suggest changes to something that has already had so much effort put into it. Finally, because pixel-perfect isn’t necessarily required for something usable, having a lower level of granularity (in this example, high fidelity) means it’s easier to make changes when we get feedback from users of the “usable” version of the Epic.

So far I have used this tool to help team members know what they need to prep for a backlog refinement conversation, and I plan to use it when facilitating conversations to the right-hand side of the y-axis so that team members remember that “grooming” isn’t always about ready stories.

Would you find this a useful tool? If you have used it, let me know how it went.

I have a new Product Owner (PO). She is new to the team and also relatively new to the Product Owner role as a whole. One of the things that I have needed to coach her on is Backlog Refinement or Grooming – and how to do so at the various levels of the Product Backlog. This is something I’ve seen many teams struggle with in the past. Either the team sees stories too late (and there’s a rush and they don’t really problem-solve); or they see them too soon (and we go into the detail far too early and forget most of it when/if we eventually pull the work into a sprint); or there’s some gap between understanding the problem and getting into the detail which means some team members get left behind and never really own the work.

So, this time, I decided to try a different way of evaluating how far a story/epic/feature was in its “readiness” journey (and, thus, how much more grooming the team still needed to do and at what level). And, what I decided to try was overlaying the ADKAR change management steps on each of the items that the PO had ordered near the top of our Product Backlog for the next couple of sprints.

So, for each item we care about, we regularly check whether the team has moved through:

1. Awareness

Do they even know this is coming? Do they know what it is? Are they familiar with the domain and the problem space?

2. Desire

Has the team engaged with the problem? Do they understand what we are trying to solve for the user? Do they WANT to solve this problem for the user?

3. Knowledge

Have we covered all the aspects of the problem? Have we started thinking about how we might want to solve the problem and what questions we want to answer or explore? Are we starting to get a feel for the steps involved and how we can break this thing down?

4. Action

We’re doing what we need to do to be ready to start on this work in the next sprint. We’re ensuring ourhighest ordered stories are INVEST.

5. Reinforcement

We’ve finished our story – what did we learn? (The Sprint Review is one natural place where this happens.)

 

Mostly, both in change management and backlog refinement, people seem to tend to launch in around steps 3 (Knowledge) or 4 (Action). Together with the Product Owner, I now try make sure we’ve moved through each of the first four steps (ideally in order) before we pull a story into the sprint. And if we realise we’ve missed a step, we try to go back to it as quickly as we can. This doesn’t need to take long at all – for the Awareness step it’s often just a short communication – after a stand-up, or perhaps in a Review when sharing the roadmap. In fact, for the Awareness step, I’ve noticed that it doesn’t have to be a long thing at all. Often the best way to move teams through the Awareness step is to repeat something brief many times, over many channels, and over a short period.

We’ve been trying this for about two months now and, so far, it seems to be working better than anything I’ve tried before when checking to see that the state of the backlog matches where the team’s understanding is of a particular piece of work. And, because we’re not skipping any important parts of our team coming to grips with the problem, we seem to be uncovering important questions and potential challenges earlier in the process.

What tools have you tried to help with Backlog Refinement? Or where have you borrowed from one problem space (e.g. Change Management) and found it has helped with a challenge in another problem space (e.g. Backlog Refinement)?

Image result for grooming backlog