Berkun reading group discussion

Discussion starts here.

I really like how Chapter 7 begins with the example of an argument with a programmer. The visual of the "big tax law-size spec template" always sticks out when I began a big assignment with multiple disciplines. I've thought about the simplest way to explain the details. It was just this week I was reflecting on a previous assignment and recycled the "big poster of planning notes" that seemed to lead nowhere as it was overwhelming and seemed to lack focus. Anyone else take down big tax law-size spec template lately?

p. 138 - Note 1. I totally agree the Google Docs can be frustrating to figure out changes. In cases where 2 people disagree with changes I have to go back through and this re-editing is a headache in Google Docs. I like the functionality of Google Docs when there is minimal edits expected and minimal general comments. Especially with items such as flyers. In general this note on p. 138 relates to p.144. I agree, that one author to filter and shape. This was such a refreshing and sense of validation for my work. I struggled through editing documents for awhile, thinking I was not organizing or presenting info correctly for co-workers. This was until I got the sense that reconciling the edits was a part of my job. I have to allow additional time for it. I also have to convey the amount of edits I received and the fact that I am reconciling edits to co-workers. Reading this "Who, when, and how" section was such a sense of validation of the process I have taken. I think of a recent example of when I got 8 different edits on 2 sentences. I did not know that was possible, and at the time, we were in a time crunch. I did convey that I would be reconciling the edits and would get back to them soon. I am not sure how others handle things in which the chain of command does not necessarily override all edits, in which there is a strong consideration of project leads input?

p. 146-147 "How to manage open issues": I like the list. Especially 2 and 4. I have not gotten a good rhythm for tracking these issues other than "reference notes" at the bottom of an email or summary. If it's something that is truly troubling than I will talk to project leads. In terms of process, this list is useful. I also like that it assists me in being proactive rather than reactionary. Is there a way others track open issues?

I was not looking forward to reading this chapter. The word specification brings back memories of 50+ page documents produced by PM's that none of us ever read. Unfortunately, the majority of project managers that I've worked with gave us these monolithic specification templates to fill out for our projects. Where did they learn this one size fits all approach?

Scott mentioned that one of the most challenging aspects of spec writing is how do we explain something to someone else. I find this the most difficult item for me. I learned a trick by speaking with one of our business analysts several years ago. He would take post-it notes and write phrases to help him write feature specifications for his intended audience. For example, he would take a post-it note and write something like "Write feature spec for Bob". Then, he would stick the post-it note on his monitor. He said it helped him write the spec in a non-technical way. I've adopted this to my bag of tricks and it helps.

My only suggestion for chapter seven is to provide references to good technical specifications for small, medium and large projects.

Ravi: I've come a long way since writing this chapter. When I worked at WordPress.com to write The Year Without Pants we worked without them - instead we used very simple mockups, discussions and notes.

The size of a spec is correlated to the size of the organization - if it's just you and 3 people who get along well, you won't be motivated to write that much down. But if you know your document is going to be read by 100 people, including some with the power to shut your project down, you write differently indeed.

A reference kit of some good specs would be nice to see - I think I tried to do this but most specs are proprietary - companies don't want their internal sausage making shared with the world.

Scott: As a former scientist, we were taught to reproduce experiments by others in our field. A large portion of our time was spent on reproducing, designing, and enhancing experiments. So, we had a great reference kit on designing and creating experiments. There is a cost associated with each experiment that needs to be justified. So, we were taught early on on how to influence management and other senior scientists on the value of our experiments.

The problem that I've observed is that engineers want to go to requirements to writing code immediately and bypass the design/spec process. I think this is more of a leadership issue because the individuals in power don't understand the value of design/spec's.

In order to change the culture, you would have to show why you need to bet on design and write good specs in a manner that engineers could understand. I think showing the reduction in iterations and re-work on building a product during the implementation stage is required.

Everyone wants to skip ahead :) I don't blame engineers - you want engineers who want to build things. But if they've worked on a few projects they're inevitably experienced getting burned by jumping too quick into coding.

The answer then is trust. That engineers trust designers that their patience is warranted, and designers trust engineers that their patience shouldn't be abused.

It seems to me that the notion of a spec-writing phase runs a bit counter to agile project management, which calls for just enough spec to begin coding right away, whether on iterations or, in a larger context, a minimal viable product (MVP). Specifications are then integrated along the project's life cycle, with mini planning phases at each new iteration. Scott, do you agree that this dichotomy exists? If so, does a more piecemeal approach to specs make sense in certain contexts?

Another point: As an engineer, I worked on several projects that lacked formal specs. The large projects were monumental failures (at least when judged against vision), while the smaller ones (2-3 other engineers) were moderately successful. If anything, it shows that specs "close the gap" of communication among engineers, managers, and stakeholders. But I do think that this chapter might be a bit intimidating for managers of small teams.