I have recently taken on a new role at work. I am the tool wright for our Business Unit. This mean that it is my responsibility to ensure that the tools we use are "sharp" and ready to be used. One of the tools we use is our process. I mean the low level development process as apposed to the higher level software life cycle process (though I am responsible to maintain that as well). When I say I am responsible for our development process, that means it's my job to document it. It is also my job to create Templates/Tools/whatever else to make the process work as smoothly as it can. No process has zero impact on those who follow it, but the impact should be minimal and relatively painless.
All this means that I attend many meetings about our process. As we are making the transition from an ad-hock process (read that as essentially no process) to an Agile process (more or less XP), there are many things we have to figure out. One thing I keep hearing from the developers is that we are not Agile, to which management responds we are agile and have been for a while. Furthermore, management insists that we have to be agile to be effective in our market place. You gotta love it when some one takes a word that everyone knows the meaning of and gives it a new meaning.
So what does it mean to be agile and what does it mean to be Agile? Well, Agile used to mean something. In fact it meant something pretty useful after the Agile Manifesto was originally drafted. So you don't have to follow the link I will copy the Agile Manifesto here:
We are uncovering better ways of developing software by doing it
and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Responding to change over following a plan
That is, while there is value in the items on the right, we
value the items on the left more.
That's it. Its fairly loose, but it defines an idea, an approach to the problem. What it doesn't do is cause someone to purchase a book, or high a consulting company. Don't misunderstand me, I have no issues with XP, or Scrum, or DSDM or whatever your favorite Agile Methodology is, but the strict adherence to any methodology is contrary to the fourth point above. The goal of Agile methods (all agile methods) is to respond to the real world rather than focus on the model. A Methodology is a group of methods that have been identified as typically having a favorable result. Sometimes people call them best practices, but the goal is to continue to do what has worked in the past. This is normal and useful. You don't figure out how to get to work each morning, you go the same way you went yesterday and know that you will likely make it.
The issue come when you turn a corner and find that a construction crew has dug up the road to work on the sewer. Obviously you cannot continue to go that way. It might be possible to get through, but it would be risky at best. Likely it would end badly, so instead you think to yourself what other path can I take to get to work. Project management should work the same way and it often does. The issue with Waterfall Methodologies it turns out wasn't that they didn't allow for change, but that people did not recognize and respond to the need for change. Almost all Waterfall methodologies have an idea of a feedback loop built into them somewhere. It is usually very long and so relies on people to remember problems and be interested in fixing them weeks or months after they have been a problem. Agile methods stress shortening this time frame and that is a good thing, but you still have to recognize when the train is off the tracks.
I like the train off the tracks image because I locomotive that has left its rails does not stop right away. It is going to stop soon however and it will make a mess as it does so. I hear people say things like "We are still getting things done, so we must be alright." I don't know why people think that way. It would be like skidding sideways down a freeway and saying we are still going toward our destination so we are alright. No you are not. Yes your moving in the right direction, but you have no control, etc. This will end badly.
So where am I going with this? Response to change is not what makes Agile Methods different. What allows for agility (the ability to change direction) in Agile Methods is knowing where we are. What is important and different about Agile Methods is defining work that can be done in a time frame that allows you to change course. Having things that you can get done in days or weeks means that you can change direction in days or weeks. If everything you are working on is going to take months, then it is very difficult to change priority and work on something different. Yes, but you say it really does take months to do ... I know it does, but to accomplish that you are really doing 100 smaller things that take days or weeks to do. What Agile Methods are about is identifying what those smaller things are and assigning them. So that you can change who is helping with the work, or even what work is getting done this week as the project goes on.
No comments:
Post a Comment