At first blush, this looks like significant progress (and that is exactly how the Standish Group reads it.) However, a closer read of the data shows that 58% of technology projects even using agile still fail or are challenged. That’s not particularly impressive (and that’s an understatement).
At Thought Ensemble, we’ve spent a lot of time thinking about this problem. Our focus is on the strategic use of technology, but strategy is only useful if you can implement it. Because of this, we’ve recently built our Technology Product Delivery Framework™ and piloted it with a few of our customers.
I won’t go into the whole thing here, but there are two key features that distinguish it from a traditional agile process.
1. Design: Agile projects tend to drift due to a fear of upfront design. However, design of software has become increasingly important. Expectations for good looking, well designed, easy to use software are rising. The traditional agile processes focus on small incremental improvements, which does not solve this problem. For example, one of our clients recently had a “challenged” project that followed the agile mantra fairly closely. They delivered the product, but customers disliked it even though it had all of the functionality they needed. It was ugly and hard to use. Design matters.
2. Challenge: Agile projects often have the idea of an iteration review or sprint review. This is a helpful first step, but our experience shows that this isn’t a sufficient amount of challenge for most projects. There simply isn’t enough scrutiny of what is being designed and built. Because our process enforces and structures challenge sessions throughout the life of an idea, projects are substantially more likely to be successful.
