6 agile principles that apply to everything

Though the principles of agile were originally developed for software, they apply to almost every other area of your organization. Collaboration, open communication, trust and independence, efficiency, and continuous delivery are the foundation of agile and they can make a lasting positive impact almost anywhere in your organization. At the recent Agile Alliance 2015 conference in Washington, D.C., Tim Ottinger, senior consultant, Industrial Logic, lays out six agile principles you can use just about anywhere.

Sometimes work doesn't look like work

A common misconception about agile is that the methodology ignores planning and process -- and that couldn't be further from the truth. What's important to grasp is that often, the planning and process happens simultaneously with work being accomplished.

"The work is in the thinking, not the typing. Brainstorming, talking, even goofing around with team members -- that's all part of it. Sometimes the best ideas and solutions come not from constant, head-down coding but from letting go. It's not 'fingers on keyboards' that count, it's 'heads in the game,'" Ottinger says.

Deliver value early and often

Agile is about delivering value to stakeholders early and often using a simple progression of steps: Plan, develop, complete, test and release. Then, repeat. The key is to do so within a small amount of time -- a sprint -- and then to make incremental adjustments based on stakeholder feedback.

"The time constraints within agile reduces the likelihood of accidents, problems, bugs and misdirection. It limits our exposure. As a product team, we don't know what people are actually going to like in our product, or what they're going to use, because these people are crazy and they change their minds all the time. So, you have to get stuff in front of people as early and often as possible so they can say, 'yes,' 'no,' or 'almost.' You want to disappoint them repeatedly in a controlled fashion over a number of months, so that eventually you can make them extraordinarily happy," Ottinger says.

Break it down (or, embrace chaos)

If your teams are overwhelmed by the sheer size and scope of upcoming projects, start chopping. Slice and dice the work into chunks that can be accomplished within the confines of a sprint and keep slicing and dicing until the work is manageable and distributed based on each teams' strengths. This is where the heavy-duty up-front planning comes in; you must make sure that the business imperatives are clearly defined and determined.

"Sometimes you'll get a directive like, 'Add e-commerce to this.' Well, how big is that? What do you want it to do? What should it look like? How is it used? Keep asking those questions, and then keep breaking the answers down into more minute pieces. This is the power of chaos. It won't look like anything's happening -- see #1 -- and at first it'll look like there's more to do because there are so many pieces, but cross-functional teams have all the competencies needed to get the work accomplished," according to Ottinger.

Focus on capacity, not speed

Another common misconception about agile is that the methodology can increase a product team's speed. While that's true in one sense, it's not always the case; instead, what usually happens is that a team increases its capacity and its ability to produce viable products, which results in increased speed.

Capacity or, velocity, says Ottinger, is therefore a consequence, not a choice. Capacity shows how much can get done in a certain period without teams being unduly stressed. Once that's figured out, businesses and teams determine how many resources are needed within that timeframe, or the timeframe can be adjusted to accommodate limited time and resources.

"The old school of thought was that to increase speed you must increase effort. Cut corners, take chances. But you often ended up with mistakes and a shoddy product. To increase capacity we use Agile to develop skills, increase knowledge, improve tools, share work efficiently, reduce inefficiencies and reduce waste -- and that helps us move faster," Ottinger says.

The dreadful constancy

How do you answer the inevitable question, "When will the project be done?" The answer is, “never.” It's what's referred to as the dreadful constancy; especially in the software world, “done” is a fluid concept as updates, patches, bug fixes and feature changes, additions and subtractions are an ongoing effort. "When the last user deletes the last copy of the software off of the last machine that's been running it -- that's when the software will be done. There's no such thing as done, there's only improvement. Otherwise, you're looking at obsolescence," Ottinger says.

Agile methods are empirical

"In doing the work, we learn about doing the work. We all do different work, and there's no real “right way” to make products, or to make products work perfectly. You have to do your own agile. You have to find your own way, what works for your company and your projects and your teams. But what you'll find, what agile will prove to you, is that prevention is better than correction. That constant iteration is better than getting all the way to the end and realizing you've failed," Ottinger says.