Share via

Question about Scrum, waterfall, and more

  • Article

Hi all –

 

A reader named Steve Henke writes with some questions:

 

First, you mentioned your concern about waterfall being used in the next major division release but with even more centralized control than before. Why do you expect more centralized control? Because of results from your team's Scrum efforts or other external factors?
 
Second, how do code reviews fit into your practices, if at all?

 

[…]

 

P.S. Have you blogged before about the most useful books on Scrum?

 

Let me first address the question about waterfall & centralized processes.  Most MSFT products are developed in a quasi-waterfall model where a bunch of planning is done (driven by PM’s), then a bunch of implementation milestones (driven by devs), and then a bunch of stabilization (driven by QA).  In reality we take a slightly more iterative approach by breaking the product up into milestones (but it’s certainly not “iterative” to the extent people use the term in the Agile community).  Of course, different groups can take a different approach (e.g. some internal MSFT teams exclusively use Scrum, some use XP, etc. – however most use a variation of the quasi-waterfall I described earlier).

 

I don’t know if there will be more centralized control in the next release, but it’s certainly a risk.  You never really know in a big organization.  However, I try to emphasize to some of the movers-n-shakers the desirability of letting each team make progress in its way (whether they will listen to me or not, I dare not guess).  To be fair, shipping a product that has thousands of people working on it introduces many challenges of scope, so there has to be a balance between centralized assessment of overall progress and local flexibility to make progress in the most locally efficient way.

 

Regarding code reviews, on my team they are mandatory for all checkins.  However, we do not prescribe the code review process very precisely; it is left up to the code reviewer’s discretion to decide how much time to spend analyzing someone else’s changes before signing off on them (or sending them back for changes).

 

As for useful books about Scrum, the one I recommend is Agile Project Management with Scrum by Ken Schwaber.

 

Over & out!

Chris