I came across a post yesterday that really made me think. Giles Bowkett posted a take-down of scrum (a popular form of agile software development) and in fact of agile processes in general. The post made it into my twitter feed (I forget how) and I read it, ironically enough, right before I headed into a sprint review and planning meeting.
What got me thinking was how much of it I agree with, even though I don’t mind scrum as a process and in fact think there are aspects of the agile approach that scientific projects could really benefit from adopting. This is obviously a bit of a disconnect, and I’ve been thinking about how I can both agree with large parts of a post that eviscerates scrum and like scrum enough that there are aspects I’d take and transplant into a completely different sort of project.
I think it comes down to how I view process. I am almost completely process agnostic as a project manager. I have used agile methods, waterfall methods, weird homegrown methods, and even weirder amalgamations of all three. Even when I’m part of a team that is technically using scrum (for instance), we are not using The One True Scrum Process. We always tweak it. To me, the best process is the one that makes the team happy and productive, and since each team is unique, I guess it doesn’t surprise me that each team eventually settles into its own unique process. One of my most important roles as project manager is to help the team find its best process.
So I read Giles Bowkett’s post and agreed that all of the issues he describes with scrum are real issues. I have also seen teams fall into similar pathologies. I don’t really place the blame for those issues on the process, though. I think those teams would have some manifestation of the same issues no matter what process they used. Sure, the manifestations would be different- there probably wouldn’t be any long, obnoxious meetings in which only the manager gets to sit down, for instance- but there would be some manifestation of the issue of a manager too full of his or her place in the corporate hierarchy and too lacking in respect for the team. There would be no farcical version of planning poker, but there would still be an overbearing dominant team member who shut down dissent from other people. There wouldn’t be meaningless velocity charts, but there would still be managers looking for a concrete measure of progress in the time between asking for a feature and delivery, instead of just taking the team at its word for whether or not they are on track.
In short, I view those issues as problems with management and/or culture, not with the process. The process is just determining how the problems are displayed.
The thing is, doing a good job at management is hard. Fixing a dysfunctional corporate culture is harder still. People want magic solutions. I have yet to find any. I recently had someone ask me for my “top tips for becoming a better manager.” I was a bit flummoxed. Everything I came up with sounds like an empty platitude. Listen to your team. Respect your team. Protect them from corporate politics as much as you can. Facilitate good communication. Try to understand their motivations and understand and respect how events will make them feel, even if your own reaction would be quite different. Don’t agree to impossible timelines. And so on.
Everything I came up with sounds like simple common sense, and in a way, it is just common sense. It is putting these ideas into practice that is the hard part. How do you know if a timeline is impossible? How do you protect the team from politics when one of the team members is embroiled in the latest politics-driven crisis? How do you understand the motivations of someone who responds to everything in a way that truly makes no sense to you?
I have no easy answers for those questions, in part because the best answer will change from company to company, and even from team to team within one company. But if you can’t do these things at least somewhat well it won’t matter what process you pick to manage your projects. No process will hide your failings. The best you can hope for from a process is that it will help you identify your weaknesses and your team’s weaknesses, so that you can work to make them better. The great thing about agile processes is that they all include a mechanism for feedback and a chance to improve. The terrible thing is that most teams ignore these mechanisms, and very few managers or teams want to take the feedback that does make it through and improve. No process in the world can solve that.
An aside that is funny only in retrospect: I put the word “usually” in the title because there was one time when a large part of my role was to help protect project teams from a ridiculous and overbearing process- basically, I ran interference with the requirements of the process so that the team could actually do their work. In that case, the process really was a large part of the problem.