Assessing a team’s readiness to adopt agile practices over coffee

I just finished an article on assessing the likelihood that a team will successfully adopt a change, such as a new process.  So this arrtice provides an example of how the approach I discussed might work in practice.

Lets say that my client, Jenny, wants to implement “Agile practices” in her organisation.  So she buys offers me a cup of coffee in return for a 20 minute consultation.

Jenny tells me that she thinks agile will be a be step forward  asks me how hard it will be to implement.

Being a typical consultant I respond that “it depends on a number of things”. But what does it actually depend on?

Well, predictably, it depends on:

• What Jenny means by “Agile practices”;
• The organisation; and
• How well the organisation embraces and sustains the agile practices.

“Great, thank you” says Jenny, “But I am not sure I need to pay for your coffee to learn that”.

I have no money on me, so I want to avoid having to pay for my own coffee. Instead, I walk Jenny through a speed-consult.

What is changing?

To be fair to me, “agile practices” could mean a lot of different things. So I ask Jenny what she actually means. It turns out that really she wants her team to be more accountable, more innovative and to be able to respond more easily to the changing needs of her internal customers. 

That’s not a very detailed plan, but Jenny goes on to explain that in the short term she wants to bring in a couple of specific practices that she used in her previous role, or that some of the team have suggested.

Jenny’s initial set of practices are:

• Using short iterations – implementing short bursts of work every couple of weeks rather than the existing cycle of delivering every three months;
• Replacing large requirements documents with agile stories, along with the team taking accountability for asking any questions they have as they develop their software; and
• Using relative estimates, with group input rather than having Arthur provide all the estimates for team.

Jenny and I could analyse each of these in detail going through the risks and challenges and coming up with a plan of attack. But our coffee will run out before we can do this so we move on to the second factor – the organisation.

Who is involved in the change?

I have spent up to two weeks on some projects, simply identifying the stakeholders and assessing their existing needs and challenges. But that’s not going to happen over a coffee.

So we make do with Jenny simply listing her stakeholders while I ask “what do they do … who else is involved in that .. what do they do … who else is involved in that … what do they do …”

We come up with this list:

• Jenny herself;
• Bill and Ben the key business stakeholders.
• Arthur, the senior developer and architect in the team;
• The development team including testers and a system analyst (but not Arthur);
• George and his operations team who provide first level support in production; and
• A team of 3 business BAs who get involved in projects but do not report to Jenny.

We gossip a bit about Arthur and how he might see the change as undermining his status as the guru in the team (which is why we listed him separately).

Will the organisation embrace Jenny’s agile?

One of the important lessons in change management is that organisations don’t adopt or reject anything. The different groups of people who work together in the organisation adopt or reject change.

So it is important to assess the impact of the change on each of our different stakeholder groups separately.

I tell Jenny that I have come up with 6 factors to use in predicting the challenges of implementing change. Of course if Jenny has read my blog, she knows I didn’t come up with anything.  Instead I lifted them straight out of some academic research.

The factors are:

1. Perceived benefit from the stakeholder’s point of view (called “Bft” in our table).
2. Compatibility with the way the group operate (“Comp”).
3. Undstand-ability (“Und”), which Jenny tells me is not a real word. This is a rating of how easy or complex the change is for the group to understand or grasp.  I suggest to Jenny that we call this graspability instead, but she is no happier with this term.
4. Trial-ability (“Trial”), or ability for the group to safely test the idea or trial the change .
5. Observability (“Obs”) or ability for the group to see the impact of the than change as it is implemented.
6. Customisation (cust) or ability for the group to refine and customise the change in their environment.

We create the following table and Jenny ranks each change against each factor while I prompt her and ask questions. We rank the alignment of the change with the factor using a scale of 1(bad) – 5 (good).

Stakeholder	Change	Bft	Comp	Und	Trial	Obs	Cust
Jenny	Iterations	5	5	4	3	5	4
	Stories	4	5	4	4	2	4
	Estimates	5	5	4	4	4	4
Bill/Ben	Iterations	4	4	4	3	5	4
	Stories	3	3	2	4	2	3
	Estimates	4	4	2	4	2	3
Arthur	Iterations	3	4	5	4	3	2
	Stories	2	2	3	4	3	2
	Estimates	1	2	3	4	4	2
Team	Iterations	4	2	5	5	4	3
	Stories	4	4	3	4	3	3
	Estimates	4	2	2	5	3	3
Ops	Iterations	2	2	5	4	5	4
	Stories	2	3	3	4	2	1
	Estimates	2	5	3	4	2	1
BAs	Iterations	4	2	5	4	4	2
	Stories	2	2	3	3	2	3
	Estimates	2	1	2	4	2	3

 

Now I have given Jenny a table with numbers in it, which constitutes a report. So I tell her that she should pay for the coffee after all.

So what?

But what has Jenny learned?

Actually, Jenny is surprised at the potential challenge that she might face with the BAs. Her initial feel was that the operations team would be a big challenge. 

But based on our conversation both the operations team and the “Bill and Ben” team don’t care too much as long as she can explain the benefits to them. The ops team are likely to be concerned about the impact of short iterations (more work? more risk?) and the potential loss of requirements documents and technical specs that will follow the introduction of stories.  So Jenny will have to provide some clarity around how stories work and what knowledge will be handed over once stories are adopted. 

The BAs on the other hand will need to change their work practices and join in on the estimates (and be accountable for them). This could be seen as a hassle by them, and while they are making the change they will be unlikely to have visibility of the impact of the change. So without seeing the benefits they might not see the point and will start to whinge (ie express concerns). Jenny remembers last time they were off-side and realises some communications and potential training is needed.

Arthur is clearly an issue (or more accurately – Arthur is likely to have issues with the change). I ask Jenny if she should just help Arthur move on so she can implement the changes without him.

Jenny’s answer is an emphatic NO. It turns out that Arthur is a key player in the team and her likely successor as manager. She really doesn’t want to alienate or lose him.

But it appears that he may lose some of his guru status. So Jenny has to think about how to explain the benefits to Arthur and how to ensure he comes out of the changes with a meaningful role.

Maybe it is a good time to sit down with Arthur and focus on growing his role in other areas to speed his development as her replacement. Or maybe the changes will negatively impact Arthur, in which case Jenny has some tough thinking to do around the changes she wants to make and their compatibility with her team’s (and Arthur’s) growth.

The other key gap we have identified is that most of the key stakeholders will not have any real visibility of the impact of the changes as they are implemented. The changes may provide real benefits, but it will be hard to see if it is these changes or other factors at work.

So the other challenge Jenny has is to define some clear metrics that will be both credible and useful for the different groups.

“Not bad for a consulting assignment over a cup of coffee”, I tell Jenny.

She pays for the coffee, which is a good sign. But also tells me that she just saved two days of consulting she thought she might need (rats).

If you try this approach then I think you will find it is useful for mini-consults over coffee and for quickly assessing your potential changes and their impacts. It also scales well when you integrate it with techniques such as the “Arenas of Change” or “the 7-S framework”.

Of course, I also coach and run courses in this area if you are interested. And I do this kind of consulting if you need help with it. So feel free to give me a call or email me if you would like some help.