April 15, 2016
Technology Solution Delivery

Who Doesn’t Want to be More Agile?

Whether you are talking about sports, personal schedules or business, who doesn’t want to be more agile? Many people have written articles about Agile vs. Waterfall application development frameworks (as my esteemed colleague Yves Baseke did in this article), but I have a slightly different take on this endless debate. My viewpoint is shaped heavily by early experiences of receiving agile coaching and then by being an agile coach myself for large .Net application development efforts. All too often, agile coaches provide context and considerations to the agile methodology dilemma, but never actually answer questions with the concrete direction the askers crave. I know an agile coach is not supposed to make decisions for a team, but I am here today to tell you definitively that everybody should be using agile techniques in application development projects. Let me repeat, you should at least consider using agile concepts and best practices!

After 20+ years of experience in the IT industry, I have found that agile provides the best approach to building a business application, and therefore increases your chance of meeting business objectives related to quality, timeline and budget. Requirement flexibility, re-prioritization and enabling the experts to influence decisions are the most compelling reasons why an agile methodology is an effective approach for software development. On a project to build a new application, I led a team utilizing a waterfall methodology to build the initial version of the application. We switched to an agile methodology for the second and third releases. Not only where we able to deliver more functionality in the subsequent releases, but we also delivered the application with a lower defect rate and satisfied the most critical of our customer’s requirements in the same delivery duration.

At this point, I hope I have you convinced of the merits of agile frameworks, but to be fair I also want to point out considerations for adoption. In this article, another colleague goes into great detail on integrating agile concepts into a traditionally waterfall organization, but the take away is that some agile concepts should be considered.

I view the adoption of agile as a pendulum. To the far left side is waterfall and to the far right side is agile. For some teams in certain business situations, being closer to the waterfall will be most effective. For example, highly distributed teams or newly formed teams would benefit from using more waterfall techniques until the team becomes more proficient on the business application. For other teams in other situations, being closer to agile is going to be most effective. For example, highly experienced, co-located teams or small teams could more effectively adopt numerous agile techniques into their delivery process.

My point is some agile techniques are always valuable. To illustrate, here is a list (in no particular order) of well-known agile techniques that can and should be applied to almost any project (regardless of industry, size of company, product, etc.)

  • Work on the customer’s highest priorities first
  • Mandate right-sized documentation
  • Enable high collaboration
  • Deliver a working product early in the life cycle
  • Mandate a product showcase with customers / sponsors
  • Identify issues early when they are cheaper to fix
  • Mandate retrospectives (a.k.a. lessons learned) to improve

As you can see, you don’t have to be an agile purest who lives and breathes terms like sprint, scrum master, retrospective, showcase, daily stand ups, burn down charts, etc. to get value from using agile techniques. As a prudent business person, if you want to be successful with something new, don’t do it yourself! Go out and find someone that will divulge their experience and help your organization up the adoption curve in the least amount of time. And no matter what, start being agile! For more information on the adoption of agile techniques, contact us at

How Can We Help?