Tech for the Exec | Agile Development

The Birth of Agile Development

Agile Development has become a bit of a buzz word in technical circles. In fact, it's become so heavily used (and in many cases overused) that Agile has evolved into more of a general guideline than a mandated checklist. As a bit of background, the term first appeared in 2001 when 17 software engineers came together to discuss ways to make development less cumbersome and more efficient. Their output was the Agile Manifesto, a document that laid out a collection of 12 principles. Those principles were driven by the following four key values (paraphrased below):

• Elevate people and how they interact while de-emphasizing tools and processes.
• Ship software that actually works and remove focus from its documentation.
• Emphasize collaboration across stakeholders and end-product producers.
• Resist following a strict plan, embrace iteration, and prepare for inevitable change.

Taming the Waterfall

On their face, these values don't appear particularly revolutionary. Then why does Agile seem to be such a big deal? The reason is because Agile emerged in response to the traditional longstanding development approach called "Waterfall". Waterfall could be the topic of its own collection of posts, but I think the following traits outline it best:

• All project planning, requirement gathering, and documentation prep occur prior to development.
• Stakeholders take delivery of a product once it's complete. They aren't involved during development.
• Addressing changes typically happens after the final product has been delivered.

Given the Waterfall landscape, the significance of the Agile movement becomes much clearer. However, Waterfall wasn't the leading approach for decades by accident. It had (and still has) a number of attractive attributes. As a result, for many executives looking to engage in a software project, numerous aspects of Agile may not be superior to Waterfall. The following considerations should help decision-makers navigate what isn't always a clear and simple issue.

Pros of Agile

• Key stakeholders can monitor progress, provide feedback, and effect change early and often during development.
• Project timelines and costs can be materially lower compared to Waterfall. This is primarily driven by a reduction in waste.
• Because of a focus on iteration, agile projects have a greater chance of optimally fitting the evolving needs of its users.

Cons of Agile

• If unprepared to commit time and attention to the entire process, key stakeholders could slow the pace and hinder progress.
• Decision-makers may be unsettled by the limited up-front planning that is common with an Agile methodology.
• Many executives demand hard timelines and budgets at the start of every project. That is a challenge when applying Agile.

So What?

In today's business environment, a strict Waterfall approach really doesn't make economic sense. It runs the risk of being very slow, rigid, and costly. That said, adhering religiously to every tenet of Agile Development may be too much for some non-technical stakeholders to handle. I think that for many executives, a slight hybrid approach may be ideal. Let's call it "Real World Agile".

For example, if a lack of timelines and budget is hard to swallow, find some middle ground. Ask your technical team for slightly more up-front planning than a strict Agile approach would dictate. Request planning documentation that includes cost and time ranges for numerous stages of development or groups of functionality. Ask for those estimates to highlight the underlying assumptions used to make the calculations. This level of planning should not hinder an Agile approach, yet it may provide decision-makers the insight they need to manage expectations.

In the end, I recommend starting with the basic principles of Agile and working iteratively to find the compromises that create the right balance for your business, your team, and your project.

-

Follow the rest of Firefield's blog here.