Today’s IT teams are adopting the agile methodology far beyond the realm of software development—think team collaboration methods and a self-organizing culture.
In fact, McKinsey director Paul Willmott believes most organizations can glean lessons from the Agile Manifesto on minimizing complexity and increasing decision velocity. Willmott says that rapid decision making is at the heart of agile techniques, like scrums. “Small cross-functional teams work side by side, checking in daily for quick progress updates and problem solving,” he explains. “Working at this pace means focusing on fewer objectives and putting in place well-defined controls, such as decision rights and risk guidelines.”
Agile just makes sense in a broader IT context. Reflection at regular intervals? Customer-focused processes? Huddles? Sure. These ideas make perfect sense at a higher level. But buried deep in the Agile Manifesto is the tenth principle, which is often a source of confusion. It states, “Simplicity—the art of maximizing the amount of work not done—is essential.”
Though the manifesto arguably evokes poetic form (it’s even in stanzas rather than a numbered list), this tenet is the only component of agile that delves into “art.” It’s also pretty confusing at first glance, especially if you’ve been compulsively driven to “get stuff done” your entire life. We took a journey to discover the true meaning of this idea and whether it’s worth your time.
In defence of not getting stuff done
You’re probably familiar with some abysmal case studies on IT project failures. The statistics on project management are decidedly not great: up to 75 percent of IT executives anticipate their projects will fail from the beginning, while Harvard Business Review found that one in six IT projects go over budget by 200 percent and exceed their time line by 70 percent.
Organizations need to control for complexity and do everything they can to keep their projects simple. Simplicity could be the single most effective way to prevent failure. Consider MailChimp, which surpassed iContact in features delivery while having fewer people on the tech team (20–30 employees for the former, 100 for the latter) and being truly agile, according to former iContact employee and agile consultant Robert Galen.
Galen also dives into the story of Unix, which you may know from its product Linux. Their original, simple architecture was elegant and streamlined, offering only what users needed and used while allowing for more complex erecting when required. Small teams with defined goals can make huge impacts on technology.
Attack the 80 percent
Think of Microsoft Excel or your smartphone. Do you use its complete functionality on a consistent basis? If you’re like most of us, the answer is definitely “nope.” Research by Standish Group reveals the average technical project results in an 80–20 percent split. Only 20 percent of features are used often, while the other 80 are used infrequently—or hardly ever.
While this knowledge is critical for IT workers who develop technologies, it’s also an important life lesson. When your IT team works on any number of projects, from security to policy, will 100 percent of your work have a real impact? Chances are, it won’t. Focus on perfecting the 20 percent and eliminating as much of the rest as possible—especially if it doesn’t provide any real value to your team or your customers.
Suman Bhowmick of the Scrum Alliance recommends a simple, three-part questionnaire that’s invaluable for weed-whacking useless work in a ton of IT settings. Before you add an item to your to-do list, ask the following:
- Will it deliver valuable outcomes?
- Does it cost more resources (time or money) than the value it provides?
- Does it duplicate work we’ve already done?
Team collaboration is an art
The ability to consider time, budget, technical restraints, and even emotions while remaining agile is far more than a science. Learning to say “no” requires a constant reevaluation of competing priorities. What worked for your IT team last year could be the wrong decision today. Agile enthusiast Aaron Krumholtz stated, “Maybe it is insanity, but I think we do need to ask the same question over and over, and expect a different answer.”
From the time we enter the workforce, we’re trained to use team collaboration sessions to create massive to-do lists, and then retreat to our work stations to plow through our tasks at a breakneck speed. While this ethic is certainly admirable, the tenth principle of the Agile Manifesto begs to differ on its effectiveness. By working with others to assess whether projects, features, and tasks actually have value, you can maximize your team’s impact in very real ways.