Embracing the Obstacle
The obstacle. What is it?
GUEST POST: the following is a guest post by close friend Dan Shernicoff AKA @BrasSMan75. He’s written for Warptest in the past about WiFi Security and knows his stuff. Thanks for contributing Dan. Read on folks …
As a relatively freshly minted CSM I clearly remember the instructor saying that what Scrum does best is shine a light on the dysfunctions. It’s true, Scrum shows us where our problems are. Sometimes it shows us the boulders in our path and at other times we see the pebbles. What’s universal with these is they cost us in time, productivity, and job satisfaction.
Why We Test
When we write software, we test it to identify the bugs in our code. We try to find the success cases and the failure ones; we test both positive and negative outcomes. Having run all our test cases we invariably have found bugs – some are boulders that might require a redesign of the functionality while others are pebbles that we need to address to keep our users from failing while others yet are just gravel, annoying but of minimal consequence.
As we integrate Scrum we are constantly testing ourselves and our processes. Just as we found bugs in our code when we tested our software we will also find bugs in our processes, systems, workflows, and teams. Some of these are boulders that require major changes to how we get our work done while others are smaller and cause inefficiencies, distractions, and loss of productivity.
Just as we track our bugs in whatever tool we choose we use we need to track our obstacles. Just as we don’t take bugs personally – they’re mistakes we made while doing the best we could – we can’t take obstacles personally. We need to “embrace our obstacles,” give them a big hug, and show them the door. The only way that we can truly benefit from Scrum is not by marking the bumps in the road but by removing them.
The BrasSMan75 POV
I say all this with the self-knowledge that I have kicked myself many times for bugs that I have introduced into the code (and into the process at times.) I know this is hard but if we don’t do it we will never evolve our teams into their best versions. Whether the obstacle is that we run out of coffee the day before we resupply the break room every time (whether it is because we don’t order enough or we wait until we run out is irrelevant,) or that the tool that we have decided to use is unwieldy and not giving us what we need, or that we are having excessive meetings to communicate data that is easily accessible should we use the tools at our disposal, we need to address the problem. In the first case it’s simply a matter of changing the ordering habits, in the second we need to take time and try to find either ways to improve the tool or a tool to replace it with that will meet our need, while in the third we might need to train the people calling the meetings on how to use the tools to get the information.
As we develop and test our code we look for our bugs and fix them. As we go ahead with our stand ups, our retrospectives, and our sprints we need to look out for the obstacles and fix them. When we see the obstacle, we need to run up to it, give it a hug, and show it the door.
The Warptest POV
Dan raises a few interesting points here about our work habits, productivity and how we need to be engaged with the process for sprints to succeed. Agile can lead to rote adoption of the “rituals”. Framing the work in terms of the obstacle and how we behave when we encounter it is a valuable mindset. Thanks again Dan.