Jan 1, 2002
"You can Change Your Organization or Change Your Organization." --Martin Fowler
I am working at a company that could use some change. I'm an XP coach with agile leanings, but for this contract, I'm just a programmer. I can't help myself, though: I've been running an agile show for three years on various projects, and it's painful to be a peon in the world of waterfall process and matrix management. I want change. I want us to become more agile, and I want to coach.
In The Secrets of Consulting, Gerald Weinberg says, "If they didn't hire you, don't solve their problem."
I'm running into the problem he alludes to in spades. I wasn't hired to be a process coach. I know: I asked. I was hired to replace a programmer who had very specific duties. When I talk about how I can help, the response is polite interest, but not enthusiasm or authority to change.
In this diary, I'm going to talk about my efforts to "Change Your Organization."
My organization is like a lot of organizations. It has good points and bad points. I think the good points outweigh the bad, which is one of the reasons I'm working so hard at changing things: I'd like to stay here for a while. The main reason, though, is that I get grumpy easily. I don't like working in environments which make it hard to produce quality software.
On the good side, this organization is willing to change. There's quiet interest in agile development, but not a lot of knowledge of what that means. There's acknowledgement of problems and desire to improve. The people in positions of authority are generally easy to talk to and are open-minded.
On the not-so-good side, there are a lot of barriers to creating quality software. People specialize in technologies and are composed into project teams. (This is called matrix management.) The waterfall model is the primary methodology. There's some bullpens, but quite a few cubicles. It's nearly impossible to pair program at the desks.
The worst problem, though, is communication. I think it may be a result of matrix management: the UI people work on the UI stuff, and the database people work on the database stuff. They go to separate meetings and have separate managers. It gets worse: project managers are a separate group that sits on the opposite side of the building. QA is on a whole 'nother floor and typically doesn't get involved until a project is coded. There's no real concept of team: a project brings together a UI person, a database person, a project manager, and a QA person. They work away, emailing back and forth and going to lots of meetings, until the project is done. Then each person goes his separate way. Worse, everybody's assigned to multiple projects simultaneously. There's really obnoxious time tracking requirements to go along with this.
As I look back on this list, I'm encouraged. All the good things are personality related: it would be impossible for me to change them if they weren't good. All the not-so-good things are culturally related: they're aspects of the way the company's used to doing business. Hard to change, but not impossible. There's hope.
20 Feb, 2006
I'm sitting in my warm, comfortable home office, looking out over the lights of my home city. I'm a long way from that cold day in 2002 when I started my diary. The industry has come out of its slump and, shortly after I finished the job described in this diary, so did my consulting business. I've received a prestigious award, my web site is steadily rising in popularity, and work is sure and steady.
In this diary, you're going to see me make mistakes. You're going to see me falter, become disillusioned, regain hope, lose it. Trying to change an organization from a position of no power is a thankless, difficult job, and this diary shows it.
As a consultant, my reputation is my livelihood. Many of my peers would consider publishing something like this, in which I am clearly fallible--human--to be career suicide. And to be honest, at the time I'm writing this, I'm still not sure that this is such a great idea. [And, in fact, I didn't make the final decision to go ahead until today, March 10th: three weeks later.]
I'm going to go ahead and publish the diary anyway, though. Almost every time I speak, somebody asks me how they can convince their organization to start doing agile development. I don't usually answer. It's hard, it's complicated, and... by the way... are you sure you should? For those people, this story needs to be told.
I've learned a lot since 2002. To supplement the story, I'm going to include this "Years Later" section with each entry. With the benefit of hindsight, I'll talk about what worked out, what didn't, and what I'd do differently.
This is a true story of success and failure, written as it happened. I hope you enjoy it.
A few notes about format: I've changed dates, names, and details to protect the confidentiality of my customer. I started in 2002, as stated, but not on January 1st as I describe here. However, all of the dates for the "Years Later" sections are the actual dates that those notes were written.
Secondly, this isn't the first time that this diary has been published. I originally published the diary in real-time, in 2002, to Ward Cunningham's original Wiki.
Next: Weeks One Through Eight