The Language of Change
There are some people who respond very well to being told “here is a better way, you should try this”. Then there are people who react defensively, almost out of instinct. These types of people tend to put great weight in the status quo, and believe that what they are doing is good enough. A few even maintain that their way is better without doing due diligence on what you are proposing. Its like the book “Who Stole My Cheese?!!”. Why is it then that when we propose that people try Agile many use the words that imply the judgment on Agile being inherently better? This sets up the scenario where someone tries agile, fails, and then shoots the messenger.
Instead of making judgments for people, I think you come out ahead if you state the benefits and drawbacks of whatever current approach is being practiced, and also the benefits and drawbacks of an Agile approach you are suggesting. This works best from the bottom up, because you need to be able to have developers realize benefits greater than their current approach in order to realize business savings that you can then promote up the chain.
For example: say a business uses a waterfall approach (3 month releases with a 2–3 week up front design.. I find this to be typical). There are several ways that if you are critical of your current process you can gently migrate to an ever more effective one. Even if the end result (where the team decides to stop changing the process) does not look like Scrum, or XP, but is better than where the team started, isn’t this preferable to proposing sweeping changes promising the moon and stars and getting shot down? Here are some areas to look for improvement:
- introduce automated testing
- introduce a build server that runs those automated tests
- propose leaving design tasks for another day to take some time to prove out design discussions and ideas
- introduce code reviews that are pinpointed on topics everyone can agree on that are critical to code health. These will differ from team to team but might include design principle violations, formatting, framework contenders, etc.
- start a refactoring list, prioritize, and evaluate after the release to see if anything on the list would make the next set of features coming down the pipe easier to implement
- keep focus on YAGNI
- invite people to look over your shoulder (pair programming… but don’t call it that… instead say you could use a second set of eyes)
- shorten your cycle by a week, or advocate splitting a release into two releases
- suggest to remove artifacts that you create, that are never used after they are created
- be critical of meetings you are sent to. If you can’t get out of the meeting, suggest that only you go and take notes for others.
- promote unit tests that test units (this works best if code abides by design principles), and code that can be unit tested. This will help your design be more decoupled.
The alleged benefits of doing nothing is that you will continue to doing what it is you are doing, and whatever results you are getting now out of your process will continue. Many people consider known issues (over budget, late release, or 60 hour weeks to make a release) to be better than unknown issues. Try to understand why people feel this way and empathize with them.
The alleged benefits of any agile approach are:
- the smaller your feedback cycle the more feedback you will get
- what you create is able to adapt more easily, because its had to due to the increased feedback
- you have less things that you really don’t need, since what you focus on is feedback driven with less guesswork
- because you create less waste, and are able to change more easily, you incur less risk
Note that these benefits are not code specific. When you apply these benefits to code you arrive at tangible development benefits such as:
- the more often your code releases to version control the sooner you find out if you broke something, and the better you will remember what it was that might be the culprit, saving time and money
- the more often you test code you wrote the sooner you find out when someone else changed something that affects you, allowing you to react to it sooner, saving time and money
The degree to which you realize the above benefits is a factor of your team’s ability to embrace change on all levels. But if you force them to bend all at once, or too quickly, there is a good chance you will break something. Never put your live frog in boiling water; its best to turn up the heat slowly.