On February 11-13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, seventeen people met to talk, ski, relax, and try to find common ground and of course, to eat. What emerged was the Agile Manifesto. Representatives from Extreme Programming, SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, Pragmatic Programming, and others sympathetic to the need for an alternative to documentation driven, heavyweight software development processes convened.
While the Manifesto provides some specific ideas, there is a deeper theme that drives many, but not all, to be sure, members of the alliance. At the close of the two-day meeting, Bob Martin joked that he was about to make a "mushy" statement. But while tinged with humor, few disagreed with Bob's sentiments that we all felt privileged to work with a group of people who held a set of compatible values, a set of values based on trust and respect for each other and promoting organizational models based on people, collaboration, and building the types of organizational communities in which we would want to work. At the core, I believe Agile Methodologists are really about "mushy" stuff; about delivering good products to customers by operating in an environment that does more than talk about "people as our most important asset" but actually "acts" as if people were the most important, and lose the word "asset". So in the final analysis, the meteoric rise of interest in and sometimes tremendous criticism of Agile Methodologies is about the mushy stuff of values and culture.
So, let's look at each part of the Manifesto in more detail. (You can read the entire Agile Manifesto and other related information at agilemanifesto.org).
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Just like the act of creating software is a discovery process, so is figuring out how best to develop that software in the first place. Agile recognizes that there is a constant need for improvement - not just in the software itself, but especially in how you get there. Through constant feedback from the team, and acting on that feedback, the team can own the process and make it better over time. This really goes against conventional thinking that management should control those processes to ensure that others follow them. The team owns how they do the work, the customer owns what functionality they want produced, and management owns how are we going to get there.
Individuals and interactions over processes and tools
There was a discovery that processes were becoming too heavy and that people were hiding behind those processes and the tools to manage those processes. Contrary to what some have thought about Agile, processes and tools in some form are used by all Agile teams. It's important to note that those should be in place only if they help the team produce better software more efficiently. In other words, they help you do your job better and with higher quality than without it. However, NO tool or processes should keep people from talking and working together. Project managers can't hide behind Gantt charts, they need to work with the team and talk about the progress of the project. Developers can't hide behind their tools as well, such as email, when their other team members are within distance to talk about things. The fastest and most effective form of communication is face-to-face, yet people tend to forget about it and use less effective forms.
Working software over comprehensive documentation
The goal for any software development should be to get the product out to customers as quickly as possible assuming that the level of quality meets standards. Just like tools and processes, if you are spending too much time on documentation when you could have the end product "speak for itself" than you are not meeting that goal. The code should be the documentation as much as possible. Conventional wisdom would say that customers should review and sign off of designs before product is developed, so that time is not wasted on being product the customer does not want. However, customers don't always know what they want until they see it. Paper cannot take the place of something more tangible. Once they see it, customers want to play with it, mold it and make it their own. Therefore, release often and early and provide the ability to respond to the customer using the working software product as the tool. We aren't talking throwaway prototypes here or "smoke and mirrors", we are talking software that works for the functionality that has been provided at the time.
Customer collaboration over contract negotiation
Think about past projects that you may have been involved in. How was the relationship with the customer? How much were they really involved throughout the project? Too much? Too little? Wish they were there? Wish they weren't? Most people would say that the relationships have usually been strained at best. Traditionally, most customers are involved primarily at the start and end of the project. At the start, they are asked to provide specs whether or not they understand software and how something should or could work. They are asked to provide EVERYTHING they can think of because the scope will be frozen for the remainder of the project. They are asked to SIGN IN BLOOD before the team will start development of the product. They are asked to refrain from any changes because they will cost the team especially late in the project. However, that is when most customers finally get a chance to see the real results of the project. Because many of these projects are already late, the customer "lives" with the end result most of the time (even though they know it isn't meeting their needs). Ultimately, either functionality is never or seldom used or there are future projects to redo a major portion of the developed product. And the vicious cycle continues...
Would it be better if the customer felt part of the team instead of on the other side of the table? That they felt they were being heard and were allowed to react to the product while it is being developed? Wouldn't it be the best interest of the customer to know what is going on since they are investing a lot of money into the effort? Wouldn't the team want to make sure that they are producing product that the customer will REALLY use and meets their needs? Of course!
Responding to change over following a plan
If we are to let the customer "mold" the product, we need to allow changes naturally to happen. If the customer wants something, why shouldn't we provide it to them? After all, they are buying our product! If we aren't providing something of value to them, why would we even work on those things in the first place. Traditional thinking says it is important to stay on time and within budget. Agile thinking manages the scope of the project and takes time and budget out the equation. If you are building the highest priority things for the customer, let them decide when the product is ready to be used. Why should we decide it for them?
That is, while there is value in the items on
the right, we value the items on the left more.
Critics seem to miss this last statement, and it's a VERY important one! Agile isn't saying that documentation, processes, tools, and planning is bad. If fact, you will find a little of all of these things on a typical Agile project team. However, it is recommending that a little goes a long way and not to lose site of the things that are most important to be successful (which are the items on the left). Remember to do the things on the left first, then make sure the things on the right are necessary to further support the left.
No comments:
Post a Comment