“Tell me and I'll forget; show me and I may remember; involve me and I'll understand.”
This quote is the crux of my main challenge in getting clients and new staff to accept Agile practices. True understanding of something that challenges a standard usually requires an epiphany. This often requires doing.
So, how do you get someone to do something that is outside of their accepted practices? Three choices: You can woo them, surprise them or coerce them.
In wooing someone, you have little evidence to prove your claim. The claim has to stand on its own merits. When wooing someone to Agile, I generally start by asking them how previous non-Agile projects have gone. Since very few non-Agile software projects go very well, an agreement that something better is needed is quickly established. After that, a discussion of Agile theory is better accepted.
When you have a bunch of data under your belt, you can surprise people. "Look! Agile projects have allowed us on-time, on-budget completions 100% of the time!" This lets you lead with a paradigm-challenging statement that makes the listener simultaneously skeptical and hungry for more. While it may seem unfavorable to start with a skeptical person, it usually works out better in the end. People who traverse a greater internal distance to get to a new system often end up being even more invested in the new system.
Some days you're outta carrots and have to bring in the stick. This most often arises with programmers we've worked with. Non-agile programmers are often used to working alone, where many Agile processes aren't seen as necessary. (e.g.: I woke up this morning and had a standup meeting with myself).
We've had an increasingly easy time dealing with this situation as our tools and methodologies have become more robust. Initially it was teeth-pullingly hard to get people on the Agile bus. This was because many of the tools we were using weren't developed enough to be rewarding to us. There also was no feedback loop in their use.
Today, we've selected groups of tools that are self-enforcing. In other words, you can't do your job at all without using the tools. The tools, therefore, wield the stick for you. This makes them mandatory, but not necessarily enjoyable.
To make them enjoyable, tools need to have rewarding feedback built-in.
Infrequent check-ins, code hoarding, unit testing, and so on were all constant problems for us before. Now, with tools like CruiseControl, this is all very different. Continuous integration and unit testing quickly become routine for even the most stubborn programmer.
Programming an Epiphany
Test-first programming to someone who is primarily interested in churning out code seems like drudgery from the outset.
"I want to write code, but you're telling me I have to write a test for everything I do before I do it?!" Their brains fill with images of laboriously writing tests for simple and theoretically non-breakable code.
Continuous Integration is the same way. They want to blast through code writing and don't want to be bothered with checking in every time a tiny bit of functionality is complete.
So, they try to ignore the system. But Continuous Integration is a harsh master. Not only does the system let them know that they just broke the build and have to figure out why ... but it lets everyone on the team know as well. Infrequent check-ins are more likely to break your build and screw up other people. Audibly and visually there is a social penalty for breaking the build.
The system quickly reinforces frequent check-in, which the programmer starts to game in order to keep their defect rate low. Check-in small, fix quickly. If you do break the build, you have such a small amount of code you are checking in that it's easy to fix.
After a while, maybe a day, the programmer says "OMG! This really works!" Unit testing and continuous integration quickly become part of their routine. They are coding faster, getting more done, and feeling like part of the team.
A Note on Specific Tools
We've worked with Java, .NET, Python, ASP, and a host of other technologies. In the end, I don't think it's the specific tools we use that makes a successful project. It is the ability of the tools to be self-enforcing, rewarding and coherent. Tools with any question of their value will quickly be orphaned by the team and you'll find yourself bitching that they aren't being used. That bitching costs time and money. If you find yourself bitching about a tool too much, it's not the right tool.
Back to the Clients
Whomever it is that you wish to appease, that is your client. Your client is interested in one thing ... value. Value is a squishy word. It can mean whatever it is that makes that client happy. Make sure you know what it is that your client values, and seek to communicate the successes of your teams under the guise of that value.
I've had people tell me this is politics or sucking-up -- but it is actually respecting the needs of a person and showing them how those needs are being met. You can still show them other metrics of success, but if you ignore the ones most important to them ... well, then it won't be as important to them.
As long as I've been a consultant I've bumped up against the concept of "complete". I don't want to get into the whole "specs are the enemy of a good project" discussion again, so I'll make this short. Part of managing any project is managing expectations. From the very outset you and your client need to agree on ground rules for what "complete" means and you need to revisit it as often as is necessary. (And it's necessary a lot).
This is important because "complete" is a big part of "value". People often (improperly) talk about the concept of building an Agile house. In a house, you have stuff you can't live without. You can't put plumbing at the end of the project. So there are elements of home construction without which "complete" will never be reached. There are other elements that are very important, but have no real claim to completeness, like using a specific fixture over another.
If you and your client don't have a good mutual understanding of "complete" or of client-value, you are doomed. If you can't communicate in the common language of value, you are doomed.
Making a final, tidy package out of this: The Agile Manager has two sales-fronts: Client and staff. Both need to understand the way in which Agile processes create a better project. On the staff side: How does this make their coding easier, better and more productive? On the client side: How does it support their value-needs and lead to an elegant completion?
It is unlikely that either group will come to you chomping at the bit for Agile, so the Agile manager needs to provide them with a credible challenge to established ways of working, get them involved and lay the groundwork for epiphany.