Agile: It's about learning

Driving home this evening, I thought about the reasons I'm attracted to Agile Software Development. Increased transparency and intimate customer involvement are two that come to mind. However, what struck me most is that Agile gives me a chance to do something I love:

Learn.

Quite frankly, spending months developing a set of requirements and more months developing, only to learn that we didn't solve the business problem (but met all the documented requirements) annoys me.

This annoyance has led me through the years to drive for small, reversible decisions. There is a sense of progress. Of accomplishment. Of creating results. Of learning.

Agile allows me to learn frequently. Think about your school days. Which were better learning experiences? The classes where you had one final at the end, or the ones where you had a weekly series of small tests? I never appreciated the instructors who adopted the weekly testing approach. I was "forced" to make steady progress, week after week. I had to master a topic in order to build a foundation for future learning. (Perhaps they should be called course scrum masters instead of instructors?)

Fast forward to executive leadership. What does learning have to do with anything? It's about hitting dates and generating sales, right? Of course. But how do you achieve these goals? By learning what works and what doesn't. Agile allows you and your teams to learn.

You learn what practices are effective and aren't effective.

You learn what your customers like and what they don't like.

It is this constant learning that enables the achievement of your goals. Would you rather learn sooner or learn later that your software isn't going to solve your customer's business needs? Learning sooner (in product demonstrations or sprint planning meetings) gives you time to think your way out of a problem instead of frantically re-work a poor solution.

There is an interesting advantage to be gained by learning. Level of experience is a significant factor in team performance. Using the traditional waterfall approach to development, you perform one planning exercise, and perhaps a few more along the way at the infamous "checkpoint" or "gate" reviews. Your competitor using Agile practices plans every two weeks. After a 6 month project, your competitor experienced twelve planning exercises. That is 3,4, or more times the number your team experienced.

Which team do you think will be more effective planning? Since your customers don't buy plans, consider why this matters.

To be continued...