Observations

Can I be agile with a run sheet?

One of the quintessential things about being agile is that you get to have a story wall.

Increasingly the team are not co-located, so they keep their wall online. Hopefully though it is still visible to the whole team, so they can all see where things are at, where the bottlenecks are, etc.

This creates a feeling of being part of a team and hopefully improves collaboration. Perhaps more importantly though, it means that the team can manage the flow of their work rather than being “managed” by the seemingly random arrival of work.

I recently visited a team and they had no wall though. So I said they should probably get one like all the cool agile teams have.

But then things got a little confused.

“Is agile a mindset or a process?” asked one of the team

“It is a mindset,” I answered emphatically

“But a wall is a tool and tools are less important than the team and their interaction. We interact just fine without this new tool” Challenged one of the team

“Shut up and use the correct tool,” I thought, but did not say anything because it seemed a little unagile to demand they use the correct tool. I thought I would trick them into coming to the right conclusion instead.

A rough approximation of the conversation

So – why would you not use a story wall?

I often encounter teams who do not want to put their work up on a wall. Is it because their work is top secret? No its not

Is it because there are no walls left to use? This sometimes seems to be the case but it is not the real reason.

Is it because they lack accountability and fear what will happen if everyone sees what they are working on? Sometimes this is the case, but it is Not because people are scared of the wall, it’s because they fear the judgement of their peers.

This relates to a mindset so I thought I would go with it.

“Maybe your unjustified fear of walls reflects the lack of psychological safety here and you fear the repercussions of transparency and honest conversations” I commented helpfully

“No, not really” Commented the team member, “We just don’t know what to put on the wall.”

A new clue

So, I thought to myself, this is the issue. The team are not really sure what their work is, so they are not sure how to make it visible. I have encountered this quite often.

People like to track the throughput of their “stories” or “tasks” but that assumes they know who the customer of a story is and when it is “done” or it assumes that they know what level of task to track and they know when their work starts and finishes.

I started to ask powerful coaching-style questions and impressed them all with my mindset level and agile jargon. But then we hit yet another issue.

“A lot of what I work on has nothing to do with the rest of the team. I am off on my own adventures” Said the team member, “only some things require interaction with the rest of the crew.”

“You could still put all your work on a wall, is there any harm in sharing it?” I asked

“Well, it doesn’t sound like it would make it quicker and easier to get my work done. Plus I already have a todo list and duplicating it seems like it would be a waste of time.” He responded

A question of relevance

So now I hit another reason people don’t put their work on the wall for all to see. They don’t see the information as being relevant to others. Sometimes this is a learning process – they have never shared the detail of their work, so they don’t see the benefit, so they don’t share the detail of their work.

In this case though, it turned out that “the team” were really a village of locals who were grouped together by the organisation, rather than a tightly knit, cross-functional team. Just like a traditional village, the blacksmith got on well with the tailor and and the candlestick maker, but they didn’t really work together in their various crafts. They just got on with their work and then met at the tavern at the end of the day to share stories.

So – maybe the story wall would not add much value here, if they don’t actually have common work that would “flow through” the wall. I was nearly defeated, because I wanted them to be an agile team but how could they be a buzzing collective of agility without some kind of wall to improve the scenery.

We had killed off the various reasons for not wanting a wall

  1. Fear of transparency with everyone knowing what you are up to. Terrifying if you think they will judge you but not so bad if you can adopt a culture of supporting each other and seeing bottlenecks as a systemic problem rather than a person’s fault
  2. Know knowing what to make visible. A lot of teams get on with things but are not sure of the team goal, the definitions of “in progress, “done”, “good work,” “our customer,” and maybe “ready.”
  3. The apparent irrelevance of the work to the rest of the team. It is often hard for teams to identify the level of detail and types of work that they all want to see, rather than just running to the wall to add something every time the phone rings.

“What about the things you do work on together?” I asked

“Oh – we suck at that. Maybe we could improve how we work on our “joint missions” He said

Finally an excuse to force my wall on them

The team got together and discussed how they might increase the visibility of the work they do together. It turned out to be only a minor percentage of what they all work on, but it was actually a significant pain point.

After some discussion they agreed to tackle joint work as a series of “epics.” Each time they got a joint mission, they would get together to understand it and hold a kick-off meeting or launch. Then they would get together each day to coordinate their efforts

Often, people only want to meet every few days but this crew saw value in checking in each day. They would each give an update on their impediments and on what they would be working on that day. Where they were not involved, they would just say they weren’t working on the epic thing today.

“Wouldn’t it be great if you could also track the work together by making it visible,” I prompted

“Like a shared to-do list, that could be useful,” one of the crew commented

“Ah ha, hmm .. what might that look like to you,” I prompted in my coaching voice

“I know – Tracey used to have a run sheet for us all to follow. That worked really well. What do you think Tracey,” One of them added

“Um .. what,” I commented in a less coaching voice

“Sure – I can be the coordinator,” replied Tracey, ” but you all know I am not going to do the work for you – just keep the list up to date each meeting and make sure everyone knows what is going on.”

“Oh – look at that big empty wall, ” I commented nonchalantly, “I wonder if we could use that to somehow put all our stories up on it to make things really visible”

“No need – I will already have my run sheet to keep track of things,” Said Tracey

“Plus I often work from home so I would be able to see the wall,” Commented Fred

The team reaches a conclusion

The team implemented the run sheet and seemed pretty happy. This is a random picture of a different one – but everyone could see the document in their google drive and they were all happy with Tracey running them through what was due each day.

It worked well – but it left me wondering.

I know story walls are awesome and I use them all the time. I also know that there is real value in creating a shared visibility of the work and (more importantly) the impediments impacting the team.

Would a story wall be better for the team or was this actually the run sheet actually the most agile solution for them?

Advertisement

4 thoughts on “Can I be agile with a run sheet?

  1. Yes, and…
    It looks like the runsheet is the best solution for this team at this point in time.
    Will it remain so in the future – maybe, maybe not.
    An important perspective will be for them to be comfortable to challenge the thinking on a regular basis and ask something like “is this still the best way for us to collaborate on our shared work” – if it is then carry on, if it isn’t then try another experiment.
    There’s a manifesto somewhere that talks about “individuals and interactions over processes and tools” – it sounds to me like these individuals had some good interaction (facilitated by some great coaching, of course;-) ) and came up with what works best for them at the moment.
    Being agile about adopting practices.
    What a crazy way of working!

    Like

    1. Good points Shane. Perhaps my final question have been “to be agile or not to be agile? Whether it is nobler of the mindset to do what the coach tells us to do, or to do what we as a team think is right. That is the question.”

      Like

  2. Hi James,

    Perhaps the answer to your question is the often heard, “It depends”. Having the wall might be a better tool but if team does not embrace, update it regularly and make it a focal point of their conversations then perhaps a run sheet if it has their attention might be a better choice.

    When I coach teams beyond software development I often find this situation where a lot of teams are trying to embrace agile (although they are managed as groups and not teams) due to organisational mandate. Their manager(s) want them to be acting as teams (and ideally high performing teams) but their tasks are often independent of each other.

    Sometimes it helps me to understand why even this group exist and I then start understanding the organisational value chains which enforces the existence of these groups. One technique I have tried to understand the flow of work is from Kanban world “STATIK”. Doing a STATIK workshop along with all team members and their managers unlock many hidden pathways for me. This can also result into developing an understanding that what might be a Kanban wall specific to that group’s needs. Does it need stories or operational tasks, bugs, problems etc.

    I used this technique quite regulalry across a large number of teams in a telco and found them quite useful.

    Like

    1. Thanks Shoaib.

      I agree that there is no point in a beautiful tool that the team don’t adopt. So maybe the answer is to let the team solve the problem.

      I haven’t used the approach you mentioned so I will look it up and then possibly try it. Thanks.

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.