Blog - End stop-ship development with agile

  • Share
  • Share

Agile solutions to your stop-ship problems

A “stop-ship bug” is any bug that, if unresolved, will stop shipment of the whole product. Many organizations suffer from what I call "stop-ship software development"—meaning the time from idea to implementation is measured in months if not years.

Anjuan Simmons | June 26, 2018

Slalom loves Agile. We’re excited about the real, measurable benefits we’ve seen businesses gain from it, and we’re talking about some of its greatest advantages in a series of blog posts and a free Agile webinar—watch on-demand.

The power of being human

Software development teams have missed their shipping dates. Customers are complaining. That’s when I enter the picture as a Solution Owner and Agile coach. In these cases, it’s usually not that anyone is bad at their job, but rather that they’re burdened with inefficient processes.

Few software project management processes or tools are built around how humans work. In fact, humans often contort themselves into unnatural poses to follow methodologies. Agile focuses on how humans actually work. Working in iterations, having a bias towards simplicity, empowering self-organizing teams, displaying information radiators, and other aspects of Agile software development derive from how the human mind works—especially in relation to other humans.

You need humans to build software. You optimize software development by optimizing the experiences of the humans involved. This starts with simplicity. You can illustrate Agile practices on a single piece of printer paper and have enough space left over to help a kid learn algebra. The challenge isn't understanding Agile. The challenge is maintaining an Agile mindset across all levels of an organization and riding out the inevitable disruptions in how people see software development. This also means dealing with deep organizational problems as they scurry around once the Agile light-switch is flipped on.

Beware of superficial adoptions

Sometimes companies are already doing some form of “Agile.” I've walked in to companies and noticed big monitors with burn-down charts, people around conference room tables having "stand-ups," and titles changed to things like Scrum Master, Product Owner, and Scrum Developer. By themselves, these are just the trappings of Agile. I call it "Agile Theater." While these practices are usually necessary to start an Agile transformation, they aren’t enough.

Sure, techniques like user stories, story maps, and planning poker are valuable, but they mean little without an Agile mindset. We’ve found that the best way to help our clients adopt an Agile mindset is in how we structure our conversations. In many ways, Agile is a framework for having conversations, and Slalom believes that structuring interactions with everyone involved in the project has to be open and transparent. Organizations often fall into a stop-ship state because conversations fall into silos or don't happen at all. This problem can be avoided by following the Agile principles of face-to-face conversation and daily collaborative work.

Agile flows—or doesn’t—from the top

So how do you get there? Leadership and sponsorship from the very top is absolutely essential. Sometimes there’s an effort to convince leadership to get on board with Agile by completing an isolated Agile project. Those leading these projects hope they can fly Agile under the radar and impress their executive management teams with results that will lead to wider adoption of Agile practices.

But to be truly Agile, a team needs to be protected from distractions, and these "Dark Agile" teams are inevitably disrupted when a senior executive has a pet project that requires resources. Without doing the necessary work to get the executive team to buy into Agile, executive pet projects take precedence over commitments made by the Agile team. This leads to the same kind of failures that resulted in the attempt to adopt Agile software development practices in the first place, with the executive team concluding that Agile doesn't work—even if they are the ones who caused the failure.

Agile must be driven from the top of the organization down to the individual contributors.

When Slalom partners with a company that want to become Agile, the first phase thing we do is a phase we call "Engage," where we make sure that the stakeholders and members of the executive team understand the principles of Agile. This upfront work with the top of the organization always pays big dividends during the delivery of the project—which is when temptations to disrupt the team are mitigated by a solid understanding of Agile theory. Because they now get it. In this sense, Agile is not a methodology but a mindset for how to envision software development—one that comes from the very top, and cannot survive in isolation.

But when it does, when people are working in ways that feel natural, we find that stop-ship problems have a way of melting away, and that the shared positive feelings of success between developers and leadership drive greater alignment and further successes.

Anjuan Simmons

Anjuan Simmons is an author, technologist, solution architect for Slalom, and passionate Agilist. He is also an in-demand speaker on technology and diversity. Follow him on Twitter.

            

Start a conversation

What’s on your mind? Let’s explore the possibilities.