Why Agile?
The basic goal of Agile is to deliver better value more quickly. The Agile Manifesto clarifies that the way to do this lies with people working together. The success criteria for any given project/product, from an Agile perspective, is related to value delivery.
Why then do we need to use specific processes and methods to be considered “Agile”? Truthfully the answer is “We don’t.” The better answer is “To learn.” We use specific process to learn the Agile mindset. We follow a pattern to learn why the pattern exists. Essentially, we use these processes and methods to learn the fundamentals of Agile. We use them to truly internalize the Agile Manifesto. They are the Shu in Shu Ha Ri, the first stages of the Dreyfus Model, or stage one of The Four Stages of Competence. But then, we realize as we teach and coach this that questions wasn’t “Why are we learning Agile with these methods,” the question was “Why are we bothering with Agile instead of just doing our jobs?”
Unfortunately, it can be hard to give a general answer to this question. The answer is as varied as the organizations making Agile transformations. What I can do is give an answer as to why I would push as much for Agility as possible in any organization.
In this day of shareholders demanding profits it may seem that making money is the primary goal of companies. I have the belief, however naïve, that most companies were started with a goal of providing something for someone first. The money-making is important, but I digress. We move forward with the assumption that providing some good or service to some person or persons as the primary goal of any given organization. To make the organization better must require providing a better good or service. This is “Why Agile.”
Agile methods seek easier ways to get faster feedback on the product provided to the customer. Faster feedback is then used to drive immediate change. Feedback on the changes is then sought and reacted to. Repeat this process throughout the life of the product line. This is a core part of Agile. “Set it and Forget it” might be great for cooking, but it’s not great for your customers. Imagine if Apple had skipped out on feedback and change after releasing the first iPhone. To refresh your memory it had no capacity for apps or MMS. Today’s iPhone 6 is very different from that original device, arrived at by constant feedback and improvement.
The product developed is ultimately for the customer. Internal or external doesn’t matter. The customer is the one that is getting the product, they should be part of creating the product. Recently a co-worker brought in four bags of potato chips. They are part of Lay’s “Do us a flavor” contest. Lay’s is collaborating with the public in determining the best new flavor. This will get the most value to the customer.
This isn’t to say that the customer is always right, or the process is immediately easier when they are involved. As is so nicely shown in this cartoon nobody in the decision chain has all the answers. What Agile does do is let us find the differences and react to them early on. Without Agile we produce product 1.0, then go back and make product 2.0. With Agile the customer sees product .2, .5, and .7 before getting 1.0. The 1.0 product in these cases will be drastically different. More importantly the one produced by an Agile process will have more value to the customer. At the end of the day isn’t that what you really want, more value for your customer?
