The agile manifesto is so much simpler. Value individuals and interactions, working software is the number one goal, customer collaboration and response to change.... these are the concepts that so eloquently described the essence of the movement. Yet, it didn't take long for people to define what those meant in terms of processes with tools that helped implement the processes. It didn't take long for people to start saying, "This is how agile will work, it can't work that way." or "You MUST have a stand up meeting" and "You must use story cards only on white 3x5 index cards that must be pinned, not stapled, glued, or otherwise fastened to a bulletin board with exposed cork only and no one can do anything if they aren't told to do so by the index card and if you use software that's a tool and that's not agile."
What we're missing here is that many of these practices were already being done in a somewhat disorganized way because they worked. Having a colleague look at a problem with you was just called "helping" before it had the term "pair programming". Talking to a customer to refine requirements during the development process was just being complete and paying attention to detail before it became a part of a process.
It would have been amazing to be in the room when the authors of the Agile Manifesto were defining these things, but they weren't discovering new territory. They were defining and simplifying to the concepts that, in their experience, made the difference between successful and failed projects. At least that's my impression of the Agile Manifesto having not actually been in the room. :)
Do what works. If you want to label something as agile, that's it. It means at the end of a period of time you have to spend some time evaluating if your choices worked or not, but it's a lot better than having people roll their eyes and perform a task because it's required of them, not because it does something valuable.
No comments:
Post a Comment