Best Practices

Agile Development. Agile Business. Agile Surgery. Wait, What?

Modern applications currently run the world, and this isn’t likely to change anytime soon.

As Forrester Research’s Diego Lo Giudice and Jama Product Manager and co-founder Derwyn Harris’ Agile webinar will outline, modern applications require modern delivery capabilities—the way we need to communicate, organize and assemble teams—to tackle the following:

  • Dealing with unknown requirements
  • Delivering software quickly
  • Embedding market feedback fast
  • Improving the customer experience with each iteration
  • Testing smarter to maintain quality

Reserve your spot: Scaling Agile Adoption Across the Enterprise

At first glance, it would seem that each bullet point is focused on the product engineering team. Makes sense, since Agile is a software methodology. But what about the agile business?

Engineering teams work hard building complex configurations of software, hardware and embedded systems, but if business has a limited view into the process, just how agile are you working, really? After all, agility in computing and business depends the ability to make continuous adjustments based on the needs of the people who buy and use your products, systems and services.

Establishing why a certain change is needed, making a case for a shift in strategy, getting consensus and approval to make the change from the folks on the production and management ends… These negotiations are happening within your engineering and business teams, but the problem is that they’re often occurring independent of each other.

At the recent ALM Forum in Seattle, speaker Kevin Behr asked the crowd (we’re paraphrasing his comments), “How many of your parents worked in software?” Only two hands went up. He replied, too humbly in our estimation, “We are, literally, making this stuff up.” And he then posed a fascinating theory for consideration: That we stop thinking of software creation as engineering, because they are two different occupations with two different ways of working.

To illustrate his point, he explained that the process of building software can be distilled to two things: thinking and typing. If you change your mind mid-thought, you simply change what you’re typing. But, he argued, you can’t do this when you’re engineering, say, an actual building. His conclusion, and selling point, was that we need to think of the process of building software as being akin to surgery, with the caveat that less of it is better.

It’s a provocative analogy that made us think about universal problems with product development and management. In many cases, more is indeed not better.

Some examples: Overdosing on more meetings to make sure mission-critical details don’t get overlooked? Fun. Discovering that key decisions are hiding in more spreadsheets, documents and emails within various individual accounts or local drives? Ugh. Creating more features that should help define how follow-up features get developed and deployed, but don’t? Ouch.

We argue that the reason “more” happens is because engineering and business, which are supposed to be aligned around the same goals, too often aren’t working in sync. “More” grows like a foreign body, inserting itself into the process of meaningful work, redirecting energy and stopping the flow of great ideas.

When it comes to the “more” disease, we encourage you, whether you’re on the business side or the engineering side, to think like a surgeon and cut it out.