Boots on the ground
- The power of visualising work -

BOOTS ON THE GROUND - The power of visualising work

by Dirk Depré - October 14, 2022

Too often we do work which actually delivers value but which we hadn't committed to as a team. Or we do work which possible is not really work that contributes to delivering the value in the current sprint. Context for this article is that we work with sprints of 2 weeks, this is typically 10 working days.

The Undertow of Work

We pick up work because a director or a manager or a colleague asks to perform a certain work that would deliver much value. "I'm not asking much and it doesn't consume much time, can you quickly do this or that?"

Those little things mean nothing right? We should be able to do them despite that we had planned our work, right?

Well, maybe, but often the answer should be : "NO". Please speak to my Product Owner. Even when it's a bug, we should be careful with accepting them as the next most important thing ever in the history of bugs (not every bug is going to let the world fall upon us). It's important that we start speaking about that kind of work and investigate what it actually is and how for sure it impacts our flow.

The conversation could be around the cost of context switching. If research shows that a distraction takes an average of 23 minutes to regain focus, than we should diminish the amounts of possible distractions and find a way to make sure we can keep focus.

But there is more ... this is not only about context switching. This is also about jeopardising the committed goal of a team, because as an individual you put yourself above the team. If you decide to take on work without consulting the team on the request, you consume valuable team time and you possibly undermine the circle of trust in your team. Each individual of the team has a saying in the committed plan for a sprint. This is equal voice. But if you decide to pick up work without discussing this with the team, you basically say that you don't commit to the plan anymore, putting yourself out of the team. It's a very delicate situation to be in, because I do understand that you might feel pressure to deliver something "small and very important" asked by a HIPPO. Maybe to right thing is to discuss in the team and see how they feel about it. The worst case scenario is that that HIPPO has to wait for 2 weeks before it could be prioritised as valuable work in the next sprint. Unless the roof is on fire, what is 10 days when you then get a focused team working on it?

Visualize Work

When we think about work that is going to be delivered, we often think about the engineer building stuff. In an ideal world the engineer knows the business and functional information and understand what the value is that needs to be delivered. Understanding what needs to be build is essential and it varies per team what "enough information" means. However, this is work that is needed to be performed and often the cadence is that this work is done up front , like e.g. 2 sprints ahead of actually being dragged into a sprint in which it is build. Let's call this kind of work "analysis" vs "development". Analysis is a total different game than Development and I'm starting to question why we still want to threat them in the same way? Both Kanban and Scrum can give you answers to this. Kanban through aligning upstream work with downstream work. Scrum through work breakdown and with respect of the definition of Done. So, in order to inspect and adapt, let's work on that transparency piece a bit. It makes your own choices about improvement so much easier, right?

Visualize Work - Kanban (simplified)

Align the work you're doing upstream (which is mainly about refining into more tangible and understandable work items) with your downstream (where you actually developed or engineer your little pieces).

Visualize Work - Scrum (simplified)

Split your work in easier to understand items. An epic is too big to deliver in a sprint, so you split that into a Story. A story should be deliverable in a sprint, but there is work to be done to do that. Splits that work into (sub)tasks and execute on them. When all (sub)tasks are delivered, you are (most likely) DONE with your story. Your Definition of Done is your compass along the way.

So … think about these high-level concepts. I'm sure you'll find out what works best within your teams. And to be honest, I'm quite sure you might even consider other ways that might work for you and your team(s). This is just a conceptual idea to give perspective on things.

Credits:

• Photo by Amanda Jones on Unsplash

• Reviewing the drawings: Serge Huybrechts - https://www.linkedin.com/in/sergehuybrechts/