Agile Implementation - observe, analyse, experimentThese days it seems everybody is doing at least „something agile“. However, the ideas what agile is and how a good agile implementation looks like still vary widly. I find that even within the same company people regularly disagree on what the next step in becoming more agile should be.

So how can we best learn about how agile we are and where to focus our energy moving forward? Doing „something agile“ is easy, but how do we adapt the tools and techniques to our own context without loosing the agile spirit? That is actually much harder.

As agile is about learning from the concrete situation, we need tools to assess this situation and thus gain a sound understanding of our actual context. Such an assessment tool should

  • provide „objective“ measures grounded in real world observations
  • connect people for shared understanding and learning
  • allow for emergence of new ideas and adapts to the changing needs of the organization
  • be action oriented and uncover tangible opportunities for improvement and change

I’v been thinking about how to implement this for some time now, did some research and started experimenting with a novel method for collaboratively self assessment of our own state of agile.

So, how ‚Agile‘ are we?

When people start into agile it’s usually all about backlogs, boards and better meetings. Those are all tangible things, that are easily observable, at least on the surface. Many agile assessment tools focus on these things and ask questions like: Do you do iterations and how long are they?

That is all fine and a fair start but of course part of agile are much harder to observe qualities. Things like:

  • Smart development strategies, which try to optimize value creation and risk management
  • Close collaboration within the teams and across stakeholders to foster fast feedback and learning
  • An attitude which allows for failing, learning and experimenting as a necessary and more effective part of creating innovative products

These qualities of agile are much harder to observe and asses. They become more and more important though, once we move out of the initial adoption phase, beyond a single team, into larger projects and the organization as a whole.

So, how do we find out where we stand with these qualities of agile and how to develop them further? A simple checklist won’t do, but fortunately agile has us covered! We can simply use the agile catch all strategy: Ask the team!

Except, asking just the team isn’t enough. Agile change lies beyond a single team. We really should be asking and involving everyone – not just a team, but all stakeholders, not just representatives or delegates, certainly not just the Scrum Masters.

How you ask matters during agile implementation

Setting up a survey seems to be a proven strategy if you need to gather information from lots of people. Traditional surveys however, abstract away way too much meaning to be useful for our purpose. If we wanted to find out something about important agile qualities like self organization, leadership or decision making, typical question might look like this:

„On a scale from 1 to 5: Are you satisfied with your ability to self organize?“ or „Are you regularly involved in architectural decisions?“ or „Does your Product Owner consult you in refining and
ordering the product backlog?“

Well the honest answers to these kind of questions would be: „Sometimes yes, sometimes no. Sometimes that’s fine, sometimes it isn’t.“ You have been asking for an average opinion.

One of the key tricks in agile is learning from the concrete observations and not from opinions and believes. We need a method that actually supports this kind of learning on a larger scale. The SenseMaker® Method, initially developed by Cognitive Edge, allows for that.

Just observe ‚Agile Qualities‘

Instead of asking for average opinions we ask everyone to share their specific stories with us. The water cooler conversation kind of stories, little fragments of observations.

We might ask: „Imagine you are sitting in a cafe and a friend comes in and tells you, just for once she would love to work in a proper agile Team. What recent experience would you share with her, to give an example of how it is working within your company, positive or negative?“

The question is deliberately a bit open, we want people to share whatever they feel is important. The goal is together lots of these stories, so that from this collection of little fragments contributed we can arrive at a larger picture.

However, now we have another problem. We have to interpret and analyze all these stories, to make sense of them and figure out where we stand.

So ask everyone not just for a couple of stories, but also for each story we ask about the agile qualities within it. For example, we might have a question like „The outcomes of this situation where influency by what…“:

Something Agile - 2

This type of question is called a triad. To answer, I would place the marker at a position in the triangle that reflects the mixture of the influences, as I felt them. That process is called self signification: The person sharing the story also indicates what the story means with respect to the qualities we are after.

Agile is all about striking the right balance and neither of the influences in this question is good or bad per se. A well functioning agile team would make use of all of them as required by the situation.

We will ask a few of these kind of question, plus whether this story was a positive or negative experience. Through this methods we arrive at a dataset, which contains concrete experiences as well as statistical data, which allows us to analyze and understand the collection of stories:

Something Agile - 4

Agile implementation: analyse, learn, experiment

Having gathered all the stories and data, it needs to be analyzed. That should also not be something done exclusively by individual experts, include everyone. Think of it as a special kind of retrospective, allowing everyone to scan the data, come up with hypothesis and craft experiments.

With some simple tools we can look at the datasets and ask questions like these:

Something Agile - 3„I see there are still a number of negative stories close to ‚set standards and agreements‘. Let’s look at the stories and see what that is all about…“

„I see there is a cluster of positive stories, which rank high on ‚individual (expert) influence‘. I’m curios, what kind of stories are those? I would not have thought that these kind of stories would be shared, maybe we can find out more about that …“

„There is a single negative story in the area ‚Input and contribution from the team“. That worries me. It might just be a one off situation, still I would like to look into it, it could also be an early warning sign.“

The quantitive data enables to roughly measure how we are doing in the different areas, it also allows to differentiate between common feelings and weak signals. At the same time we can always access the concrete stories behind the statistic. With those we can better understand what is truly going on and what kind of actions can actually help within those kind of situations.

Jan has presented these ideas in a Lightning Talk at goto; Amsterdam in 2016. Contact him to share his showcase project with your team.

 

Foto: pexels.com