Arguably, the most important aspect of agile is change. Indeed, agility can be understood as moving from one way of work to another. From doing something planned that is potentially useless, to doing something unexpected but surely useful.
In order to achieve change, you must first discover what you can do differently for your next action. Discovering the needed change is usually painful. People are used to doing things in a specific way. They are used to doing concrete, well known, tasks. Derailing them from their daily routine is uncomfortable and many times it can be met with resistance. This is normal, even if you are prepared for change.
We have come to value […] responding to change over following a plan.
― The Agile Manifesto
Change can be triggered by different sources. Probably the most painful one is when a client tells you that your product is not doing what he/she wants. Client complains must be analysed, and, if reasonable, must be considered for inclusion into the product. Such changes may have a high impact on both the product and the development workflow.
Another potential unexpected change is when we missed a bug or two and they end up in the released product. The client will come and complain that the product is working in a defective way. This type of complaint is, however, less painful than the previous one. Yes, there is a mistake that needs fixing, but at least both the client and yourself agree upon what the product should do. So the change affects the development team’s workflow by introducing an unforeseen task, but everyone easily accepts that it has to be done.
The third way to produce change in a project or in our development workflow can occur when one or several team members identify a problem. They then find a solution and try to introduce a change in the whole team’s workflow. This change is born to eliminate the identified issue. This kind of change requires one person to convince everyone else that there is a problem. Furthemore this person must convince the others that the discomfort caused by the change today will make everybody’s lives easier tomorrow. This may be the trickiest change to introduce, regardless of which side of the barricade you may be on.
Read the rest of the Behind the Scene series:
Behind the Scene #9: The Right Tool for the Job – Multiple Language Development
Behind the Scene #8: Polyglot Programmer – Multiple Language Development
Behind the Scene #7: Being Agile by Responding to Change
Behind the Scene #6: The Art of Programming
Behind the Scene #5: Double Vision – Pair Programming
Behind the Scene #4: Techno Agile
Behind the Scene #3: Culture Shock
Behind the Scene #2: We Are Not Prodigies
Behind the Scene #1: How We Develop Storage OS