Something about Skip Angel's blog post about business killers and killer leaders got me thinking about how different people exhibit different behavior in stress situations, even though they have just agreed about the "ideal" behavior outside of the situation.

We've all worked once in a company with The Process. The Process was what people were taught on their very first day into the job and The Process was what every single project plan depicted with perhaps a slight variance in exact wording. And I wouldn't be surprised if you remember that nobody in that company actually followed The Process.

Intelligent people suck at following a process that they don't value. And it's not just processes. Recommended practices, monthly instructions from a distant part of the organization, a new tool that nobody asked for. Some of the resistance is likely due to the Not Invented Here syndrome but some of it is warranted.

And we all know this. It's not interesting. At least not as interesting as some other phenomena that can be observed every day in the corporate IT world that we all love so much.

Unfortunately, people neglect practices they were supposed to believe in. For example, many Scrum teams start out by defining what "Done" means, agree on the use of practices such as pair programming, test-driven development, automated acceptance tests, and so forth. But when push comes to shove, few of these practices are really executed by the team as a whole.

Why? Why do people decide to not follow practices they've committed to following just a couple of weeks, maybe only a couple of hours earlier? Because they hadn't really committed? Because they were holding their fingers crossed while they vaguely nodded during decision making? Because they stood silent and nobody noticed that their silence might be a sign of disagreement with what the majority was rushing ahead with?

Discipline is a powerful trait for a software developer. It's discipline that keeps us on the "righteous path" and from following the dark road of little white lies and tiny little compromises that we'll "make up for in the next iteration." Discipline also becomes a lot easier to achieve when the discipline is towards something you believe is good.

Discipline isn't just for software developers, however. Let's go back to the kick-off meeting where the team wrote up their rules and gained commitment and buy-in. Let's go back to that one team member who didn't say much in the meeting but also didn't object to what the team was about to decide. Let's assume that that person didn't buy in and therefore didn't commit to what the rest of the team was going for. Who's to blame when it turns out that that one person isn't really following the team's decisions? Should that person be disciplined enough to suck it up and follow the pack?

To a degree, yes. It is a team member's responsibility to speak up rather than stay quiet and create misinformation about the team's commitment to certain things. It's not wholly that one person's fault, however, when this kind of a thing happens. Bad things rarely happen because of one person alone.

What strikes me as a more serious problem than a couple of developers lacking the discipline their colleagues exhibit is when the process facilitator--be it an XP coach or a Scrum Master--lacks the discipline to do his job. I've seen and heard of plenty of cases where the process facilitator is anything but. Where the process facilitator is just a project administrator (we used to refer to this role as "project manager").

The best Scrum Masters I've seen are developers themselves or have been true craftsman developers before. Another demographic group I've seen do a good job at being Scrum Master or process facilitator are people with an eye for peopleware. On average, and in my experience, these type of people fare much better in their job than the ex-project manager turned to Scrum Master by two days of training and a secret audible handshake. These Scrum Masters are good at what they do because they care and because they believe. They've seen first hand what discipline can accomplish and what kind of a disaster the lack of it can create. They've seen first hand what kind of a deadlock can people issues create and how to solve them.

Many project managers simply seem to be missing some fundamental understanding of the kind of issues they're supposed to be helping the team to conquer. Or they're too unsure about themselves to do something about it. Lacking the discipline to do what they know is the right thing to do.

Discipline is core to the success of agile software development and to software development in general.

If you're a Scrum Master or a process facilitator with some other name, stop for a moment to think back at how you've done your job recently. Think about situations where you've smelled something burning but decided to not look for the fire. Think about occasions where you could've helped the team understand their problem better by pushing back and digging for the root causes instead of caving in immediately. Your job is not to make friends. Your job is to help the team live up to their full potential.