What Problem Are You Trying to Solve?

This is the fifth in a series of posts on dealing with the impediments raised in “Agile Antipatterns Are Easy to Spot, Hard to Change”. The fifth antipattern discussed in the post is…

5. Expecting the software to be built better, faster AND cheaper

Software projects have a reputation for delivering systems that are late, costly and buggy. Having worked in the field for many years, I feel the pain that many companies experience. They seek out alternative approaches to software development hoping to solve these problems.

Agile forms of software development are a hot topic today. Scrum, Kanban, XP, Lean, etc. get a lot of attention. Go to Amazon.com and do a paperback book search for “agile software development”. You’ll get over 1,000 hits. There’s a lot of agile information available so it’s not surprising that many companies have adopted an agile approach or are interested in doing so.

Not so fast!

If your company is considering agile development or has recently adopted an agile approach, ask a simple question. “What problem are we trying to solve?” If the answer is along the lines of delivering better software (quality issue), on time (speed issue), and on budget (cost issue), the responder is trying to solve three complex, interrelated, problems. An agile approach may be able to achieve these goals but only after a lengthy trial and error period.

Most agile approaches focus on delivering a higher quality solution to the end user. This is achieved by engaging the end users in the process sooner and delivering incremental updates to them frequently.

Will this result in an earlier final delivery? It might, but finishing the project sooner is not an agile principle. The project may finish sooner if the business requirements are captured better and if less rework is needed. Agile development can help get you there but it won’t be easy.

Will agile development result in a lower project cost? It might, but reducing cost is not an agile principle either. The cost may be lower if mistakes are caught sooner and if the team can react to business changes quicker. Again, agile development can help but it’s no magic bullet.

Scrum, Kanban, XP, Lean, etc. often “fail” simply because expectations are too high and/or the investment to make the effort successful is too low. Don’t try to solve too many problems at once and don’t expect major improvement overnight.

I strongly encourage every software development team to embrace agility using an agile development approach. Simply remember a few simple rules:

  • Know what you’re getting into.
  • Know what problem you’re trying to solve.
  • Don’t try to do too much, too soon.
Updated: November 17, 2011 — 9:35 pm