Chapter 15: Discussion and Questions

[Scott]

Start here.

[Ravi]

This is one of my favorite chapters in the book: end-game strategy. I learned about a number of tactics that can be used to manage end game and tools to use to drive projects to the finish line. My key takeaways in priority order

1. "At the project level, it's best to think of team productivity as a zero sum resource: if you require extraordinary efforts to meet a date, realize you are stealing those efforts from the early parts of the next phase." The recovery time for extraordinary efforts can take weeks or months. On one of my projects, it took me about two months to recover from it because I didn't take any time off. I've learned that when I push the team or myself hard, we need to take time off to recover. I didn't understand this until I tracked my own progress on back-to-back projects.

2. Defining exit criteria for each milestones upfront. I've been on so many projects where teams were arguing what constituted done for a milestone. The mistakes that I've seen are poorly written exit criteria's - "payments can be made by some credit cards" should be "payments can be made by Paypal, VISA, but not AMEX or MasterCard"

3. "Why hitting dates is like landing airplanes?" One of my challenges is to explain concepts to some of our engineers and users so they can understand my approach. Scott has done a terrific job with telling stories and providing visual metaphors to help me explain these topics. I've learned that explaining items in a story format helps communicate a compelling message.

4. Creating a measurement system for tracking project status. The danger with data occurs when we take it out of context in order to make decisions. One of the problems that I see with PM's, VP's, and other team members is to avoid having conversations by using data.

The only item that I would add to this chapter is to have a longer section on Rollout and Operations. There is an entire DevOps culture that is being embraced by many for rollout and operations. See more here - http://theagileadmin.com/what-is-devops/

[Scott]

#2 is so tricky in practice. How much detail is enough? There's a lot of faith based beliefs about the answer, but generally it depends on the team, how much they're worked together, and how self-aware they are. There's no single answer. If I were making an airplane I'd want different exit criteria than a airplane iPhone game.

Data misuse is a rampant problem - I wrote about it here:
http://scottberkun.com/2013/danger-of...

[Shiran]

Another really great chapter. A few reactions;

* The term "war team" is great. It clicked immediately that the explanation was almost unnecessary. Having an intrepid group that decides on the shape of the project in the final stretch is extremely important. The war team provides rational assessment and strategy to mitigate all the thrashing and scrambling that can happen in the trenches.

* For me there's a very fine line between features and bugs. Features are planned, while bugs are not. More emphatically, bugs are features that failed to be planned. So in my projects, all features and bugs are tracked, managed, and prioritized almost identically within the same system (aside from a bug/feature tag). This helps us prepare for new milestones (e.g., bugs may expose new features that have yet to be implemented) and makes postmortem analytics of the project very straightforward.

* For many (mostly small) organizations, bug tracking is unfortunately the public face of project management. For the uninitiated it also represents a level of excess software bureaucracy ("why can't we just email bugs directly to the developers???"). I find that simpler tools that allow frictionless issue reporting (without requiring too many fields) to have better adoption by non-developers. I know the chapter recommends tracking various attributes, but incomplete bug reports are better than no report at all.

[Scott]

Shiran: you're right about the features/bugs labels. It's arbitrary, but every team sorts out for themselves where the line is. It almost doesn't matter as long as there's a line everyone agrees on.

I was surprised when I worked at WordPress.com they didn't have many bug tracking tools, and the ones they had weren't used consistently. But to their advantage since they use continuous deployment the spin rate for finding issues and fixing them is generally fast (except of course for the issues no one wants to fix that don't quite rank high enough to be dealt with immediately).