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.
> 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.
Maybe the reason is different approaches to management. The first one sees a manager as serving his team to produce good results, the second one sees the team as serving the manager to deliver good results. A short training as a Scrum Master wouldn't change that (~ Theory X and Theory Y).
Concerning the problem of acting disciplined, I once read the recommendation of a top manager on how to cope with regular tasks you don't like: make them a habit, take a decision once and then don't think about them anymore, just do them like breathing. I applied this quite successful to some tasks I hated, now I'm indifferent. To make this work you need discipline at the start especially you have to stop thinking about its usefulness after taking the initial decision. But this is a personal approach each team member has to take for herself. E.g. if you have decided that you should pair program, do it and don't question its usefulness any more, except in predefined situations like a retrospective.
Regarding Theory X and Theory Y, IMO Theory X is entirely contrary to agile development principles. Theory Y tends to be more effective in most cases, and especially in managing a team of creative professionals such as engineers or software developers.
The Theory X approach damages specific elements of team dynamics that add value in an agile project. They are:
- Transparency;
- Self-organizing, self-managing team; and
- Sense of collective ownership coupled with individual accountability.
A team of professionals that is enabled to act autonomously to respond to problems, and that is not penalized for taking risks and making mistakes along the way, tends to be much more productive and effective than a team that is afraid to take any action beyond the instructions of their manager. A team that must wait for instructions or approval from the manager will waste a certain amount of time waiting for such instructions/approval every day. This is unproductive time.
When a team feels a sense of ownership of the problem and the solution they proactively solve problems before the problems become large, simply because they care about quality. When a team feels as if the manager owns the problem, and the manager punishes them for acting without instructions or approval, they quickly cease to care about the project and they limit themselves to carrying out instructions, even when they can see potential problems ahead. I have seen cases when the team members think it is funny to watch the manager's ideas fail. This is obviously not a good way to deliver high-quality results.
Sometimes people must be careful to align what they need, what they want, and what they ask for. The Theory X manager needs to deliver quantifiable value and to satisfy the customer; wants to feel powerful and superior; but asks for poor results through his management style.
The Theory Y manager needs, wants, and asks for results that deliver quantifiable value and that satisfy the customer.
I suppose you can guess which style I prefer.
In the context of Lasse's original point about discipline and Scrum Masters, I think it is incumbent on the Scrum Master to mentor the project manager in this case. It may be a difficult cultural change for a traditionally-minded manager, but it is an important one. For the Scrum Master, it will be politically risky to address this sort of problem, and that is exactly why it demands professional discipline.
Dave, most of the Scrum Masters I've seen in companies with no external consultants are project managers. They're often both ex-project managers slash administrators as well as current project administrators posing as Scrum Masters. I.e. they're missing the "improvement" part from "process improvement"...
Fortunately, this isn't always the case--some projects that have been running Scrum for longer (and usually have gotten proper coaching) are much better in terms of understanding what makes Scrum work.
I think a more effective team structure has separate roles for project manager and Scrum Master, with the project manager focusing on these areas:
- financial tracking
- dealing with internal bureaucracy
- smooth interaction between agile project teams and non-agile parts of the IT organization
- general administrative tasks
- process facilitation
- agile mentoring and coaching
- removal of impediments from the team's path
You make some very good observations about the importance of discipline. It's a subject that is on people's minds these days. The Slow Leadership piece and Skip's commentary are also very relevant.
>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.
That's an interesting and important question. Maybe in some cases it happens, as you suggest, because people are not really committed, they don't genuinely believe in the practices, or they silently acquiesced to the team's decisions without speaking up. I can see a couple of other possible answers, as well. These answers are a little more sympathetic to the team members who are having problems, and also IMO they are problems we can address on a practical level.
(1) In organizations that are new to agile methods, many people may believe they understand what the words mean and how to execute on the practices, but they are simply mistaken. The plain truth is that they don't understand what to do. At our company, for instance, many members of our agile delivery group believe they follow two XP practices in particular - TDD and pairing - but in fact they do not follow these practices correctly or rigorously. Besides that, if you ask them directly how those practices bring value to a project, they really cannot explain it. This reflects a simple lack of understanding on their part.
Unfortunately, as I mentioned on Timo's blog some time ago, we still do not have enough people here who can serve as team coaches or even as process facilitators / Scrum Masters. Most of our projects have no one in that role at all. I can "float" from project to project an offer suggestions, but this is not as effective as having a dedicated process facilitator on the team. We can address this problem through periodic learning sessions and team discussions, but this approach is less effective than on-the-spot coaching in the context of real work. I would not be surprised to learn that many other companies are in the same boat.
(2) When people get into the routine of a project, and especially when things get tight and they are under a bit of pressure, they revert to their default work practices (whatever those may be) based on long-established habit. Unless practices such as TDD and pairing have become automatic and habitual for the team members, they will set those practices aside the moment they come under any pressure at all. That is unfortunate, since the disciplined application of XP practices can carry a project through the rough times far more effectively than falling back to a process-centric approach.
To use our company again as an example, in hindsight I think we released our agile mentors (ThoughtWorks) too soon. We had reached the stage that our staff understood how to do XP. We felt as if the ThoughtWorkers were working with us as peers rather than as mentors, and they were rather expensive peers. Confident that we could carry on without them, we released them. Our mistake was that most of our staff had not truly internalized the agile approach, changing their mentality and their habits. They understood what to do only on a superficial level. They did not automatically approach development work from a TDD standpoint; they still required prodding to "do the right thing." Without consistent mentoring in the moment-to-moment activities of daily work, they gradually slipped back into their old habits without necessarily realizing it - especially when working under pressure.
This problem can be addressed through coaching and mentoring by a process facilitator who stays with a team at least for a couple of iterations, if not for a whole release or even longer. We don't have the resources to do that just now at our company, but still it is a problem that has a practical solution.
I definitely agree with your comments about what makes for a good Scrum Master. To care, to believe, and to be disciplined about the job are very important factors. They also need to understand, truly, how each of the best practices delivers value, how to recognize "process smells" and track down the causes, how to guide team members in correcting problems (teach them to fish), and how to quantify the effect of process changes in terms the project manager and customer can understand. The job of Scrum Master requires a broad range of skills that cross several traditional professional boundaries, including people skills, technical skills, critical thinking skills, political skills, and management skills - not to mention a lot of patience.