I just finished my first complete, pre-publication technical book review for Addison-Wesley. Ugh. Twenty-Eight chapters in a little over a week.
Well, it was certainly an adventure, and one of the bigger items on my list is now gone.
The book by Jim Brosseau has a working title of “Taking Ownership.” I was particularly struck by chapter 15 – “Guidance.” Specifically, in this chapter Jim discusses the benefits of norms, policies, and standards in software process.
Long time (ok, short time) fan of Creative Chaos will note that I am, well, not really a big fan of stable, repeatable processes. In fact, over the weekend I was mulling an article about the damage that the cult of repeatability is doing to our craft.
So, you can assume that when I read chapter 15, I had my red pen out, ready to slash.
Then Jim did something interesting: He made some fine points. I enjoyed the chapter, and came away with a more moderated opinion on the subject.
But enough about what I think; I am interested in what you think. So I have arranged with Jim to have that chapter available on Creative Chaos for free.
So, if you have a few moments to spare, please feel free to follow the link and take a look.
Note: I am about to switch webhosts; if you can’t find the file, I’m probably working on it.
If you are really ambitious, this is your chance to tell AWL how you really feel; you can leave comments or email me. If there is enough interest, I could turn this into a short series.
Or don’t. It’s just a couple of pages; I thought it was interesting, wanted to share, and Jim was agreeable.
And with that off the stack, I can finally start focusing on lighting talks …
I found many things in the chapter in line with my personal views. Does this make the text “right”? No. But it does reflect my experiences and to me that is of worth.
I have said for years that existing processes and methodologies addressed some problem of their time. To modify or extend a process one must understand the original goals of the process. These align with some of the quotes on my Maverick web site.
http://home.att.net/~geoffrey.slinker/agile.html
“Hey, I knew that methodology when it was still just a complaint.”
“You know with a flat-head screw driver, a pair of vice-grips, and a hammer you can fix almost anything but you can build almost nothing!”
“Of course I am lying, I can really do that in a week instead of three. Gosh, you caught me.”
Carrots and Sticks and persistent consistent : these go hand in hand. If one gets hit with a stick for doing something, then all should get hit. If one gets a bonus for doing something and someone else does the same thing then they should get the bonus.
As for heroes, I think that their need to exist can be removed and thus the heroes will either leave or change.
From my rants on heroes found at http://home.att.net/~geoffrey.slinker/maverick/MaverickDevelopment.html
“If it wasn’t enough to have managers without any real understanding of how to develop software I have watched developers dup management into believing heroics are required to develop software. Duped into believing that there is only a few that can develop the product and the rest of the developers are to take supportive roles. I have watched these clever developers build empires to protect themselves and become the very prima donnas that management complained about.”
“I have seen excellent developers black balled by these empire builders because the empire builders realized that this person was skilled enough to replace them. I have watched these empire builders wait for a power vacuum to occur and rush in and fill the gap. I have seen them target other developer’s features that are late and secretly criticize the developer. Then, while the developer’s reputation is in doubt, the hero works many late hours and rewrites the feature and presents it to management who in turn praises their effort and commitment to the company. The other developer is then regulated to a subservient position and is basically layoff fodder for the next round.”
Just as Jim Brosseau states that allowing the team to learn and create their own processes because they are more likely to adopt the changes and the team is most likely to have the most accurate understand of their situation the same is true in the performance review process. I don’t know if his book address such things but a Semco style review process seems important in applying fairness and persistent consistency.
I could go on and on. I liked the chapter. I agree that we should get as many tools in our boxes as we can.
Thanks for sharing this chapter.
Geoff