Berkun reading group discussion

Start here.

My least favorite chapter so far. This chapter summarized portions of previous chapters such as Chapter 3, 4, 11, and 12. If I was using this book as a reference instead of reading it from front to back then I can see why Scott wrote it this way. The coding section pipeline is dated and I would've written it differently. But, this is what I liked:

1. "For this reason, the length of milestones should correspond to volatility: the more volatile the direction, the shorter the milestone length." This is sage advice especially when requirements are changing rapidly
2. "My general attitude toward them is this: it's better to use short dev cycles with strong design processes and allow few DCRs, than to plan a schedule that expects many DCR changes." I agree with avoiding the DCR process altogether. The team is already under stress and I've seen it adversely impact the focus of the engineering team.

These are the topics that I would've covered in the coding pipeline section.

1. Traceability - it's very easy for engineers to lose track of the features and goals when they have more than 10 things on their plate while delivering a new piece of functionality every day. The challenge is to maintain and create links across all product development artifacts (include test cases and defects). When done correctly, it helps ensure that the team is building the right product and continues to provide context within the implementation phase. When applied in SDLC context, it makes it easier to monitor and control. For instance, Feature X was broken in build 3248 which prevents the testing team for executing 3,000 tests.... The PMs were going to demo the product today and should avoid showing Feature X, etc...

2. I would've introduced the concept of continuous delivery. The purpose of continuous delivery is to reduce the cycle time between an idea and usable software. This means automate everything necessary to create usable software. So, you should be able to push a button to deliver software to any target environment as often as the team requires.

I disagree with Ravi, and think that the spirit of the guidance in this chapter is still entirely relevant, even if the toolset has been modernized (and greatly empowered by continuous integration tools).

“Always try to do the most critical work first, even if it’s the hardest.”

This point is insightful and intuitive, but I'm not sure how practical without having good critical path analysis. What's most critical may be an upstream activity for a large complex component that might not be completed until the end of the milestone. This must be balanced with easier, low-hanging fruit that give developers and stakeholders a sense of progress. Maybe this gets balanced by (a) planning short iterations where bite-sized tasks can be picked off by developers, and (b) defining "critical" more holistically, taking into account morale and political considerations.

Shiran: On complex projects you're right, but simpler ones you can just use your judgement. if you were mowing the lawn you'd know intuitively what the critical parts were (say, the path to your driveway).

You're right about balance though. If you bury people in the hardest work first they might not have the morale to want to continue.

Shiran: I agree with you that the chapter is still relevant. I would've taken a different approach on the coding pipeline section in 2015 vs 2004. There is nothing really that I disagree with Scott on in the chapter. But, if he's going to update this book, I want him to include several other areas that would be helpful in the coding pipeline.