You need to know what's on the cutting-edge of technology. Find out what's coming and the unique Warptest POV with just one click on the "Blog" tile.

All posts in Agile

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.

obstacle - agile - tree trunk

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.

Agile Actually Does Not Have Low Hanging Fruit…

Are you “doing” Agile? Scrum or Kanban? Doesn’t matter. Probably some of you aren’t actually implementing or running with Agile. Even if you believe you are.

Sorry to disappoint you but this boils down to realizing that Agile does in fact have no low hanging fruit.

Agile Low Hanging Fruit - Tree and Chicken

What Does That Even Mean?

Low hanging fruit, the easily reached, easily attainable target. Ever been up in a cherry picker? That sense as the hydraulics lift you into the air in that small metal basket. As the basket vibrates and you hold on and then … yep, you look down and realize just how fast you got that high up. Agile is like that. Implementing Scrum or Kanban the first time feels like that, especially for the matrix, CMMI and waterfall crowd. Where’s my safety net? Ironically, Agile is meta. The more iterations you do, the more confident you get.

Unless you fall prey to the illusion that certain activities within Agile are easy and you can cherry pick those and ignore the tough stuff. It becomes about performing ritual or kata for its own sake instead of a deeper understanding of why and how to do things, and do them right.

Kata is mindful and any martial artist will explain the benefits of understanding their purpose. Like many others, I’ve applied the kata concept to testing in the past.

Don’t do these. No really, don’t.

There is one more arguably, having tools that don’t integrate, communicate or display actionable information. Allowing technical debt to fester.

If any or all of these are happening with your Agile team then you fell into the illusory trap of low hanging fruit.

This slideshow requires JavaScript.

The Warptest POV

At this point you may be thinking all is lost or getting a bit annoyed. None of this is irreversible and the solution lies in the Principles behind the Agile Manifesto. If you have never read this and or don’t review it with your team, then this is the first change to make. Heck make this the default page in your team browsers, print it big for each work-space and read it aloud together.

See the photo above, I didn’t choose it just for the tree but also for the chicken below. I was sorry to see the chicken and pig analogy dropped (albeit for some evident reasons). The allegory has benefit but is loaded with negative connotation. Find another story that works for you.

Invest in your people. Train them and give them the knowledge and skills to succeed. We can’t just say to a team member, “Hey mate, you’re Scrum Master from now on.” They need to know what a Scrum Master does, how to do it and they will need guidance and help. A Certified Scrum Master course wouldn’t hurt either.

Make the changes that need making and do so fearlessly but not aggressively. Use honey, not vinegar.

Why is all this important? If you leave things as they are, stuck in some bastardized version of Agile then you are plotting your own failure. It won’t work and management will consider Agile a failure. This is a disservice to your efforts, your product and Agile itself.

The point of all this is to drive success. Some of the things you shouldn’t do are the end of a path taken that gives you short term, warm and fuzzy self-gratification instead of keeping your eye on strategic success.

This always makes me think of the scene in Arnold’s Conan the Barbarian where he and his companions are asked,

What is best in life?

Conan knows the answer and so should you. In the case of your team and product it’s adhering to a concrete definition of success. For me that is happy customers who come back for more of our product.

What’s your definition of success?