Who has not heard about the waterfall model, extreme programming, or agile software development. Many books have been written and speeches have been given about these topics. News articles, success stories, and web-sites appear all the time about them (well, less and less about the waterfall model, but this is besides the point of this article).
Processes give you the set of rules your team must follow to insure project success. They keep everyone in the team on the same page, and insure things are done according to the guidelines. Or at least, that is the idea.
The problem with any software development process is that one size does not fit all. People are different; projects are different; company cultures are different. What worked for you does not work for me, no matter how hard I try. The ideas are good, but the rules are too tight to fit my needs.
Team dynamics evolve as team members change, as people learn how to collaborate with each other, and as experience is gained by the team. We cannot pretend to keep the processes static while all this evolution is going on.
If we blindly follow rules, we will not see what we are doing wrong. It is easier to blame people for their mistakes than to understand what went wrong and how can we prevent it from happening again. Rules always tells us who to point our finger to, but they would not solve our problems when mistakes happen, and mistakes always happen, no matter how much experience we have, how well our rules are defined, or how hard people work to follow them.
Does that mean processes are useless? Not at all. It means that processes to be successful need to be flexible. It means that we always have to keep an eye on our process and improve the things that are not working. It means that we need to learn from experience.
But what it really means is that rules hardly work. Guidelines work much better. When implementing a process, you need to evaluate your situation and make the necessary adjustments. Do not underestimate your team members and what they believe it will not work because they would not follow rules they do not believe.
Your team probably knows as well as you what needs to be done. All they need is a set of guidelines to coach their decisions when confronted with tricky situations, and open communication will solve more issues than any written rule, even if is carved in stone.
When you read or hear about a new software development process always think: Processes are good. Now, how can I adapt this process to my environment? Embrace change, but do not force changes without consensus. The people in your team are more important than the processes you intend to follow. they are the ones that will have to do the work, so listen to them and adapt your process to their needs. Keep people in the same page by letting them buy into the book, and everyone will be happy.
No comments:
Post a Comment