Mini-Microsoft is a blog written by an anonymous MSFT employee in Redmond, WA (I think…) who makes some rather interesting, biting and pithy observations about what’s going on inside one of the largest software companies in the world. He’s known for his unvarnished opinions (which are easy to make when anonymous) on management and hiring, eg. would like to see 10,000 more jobs cut to restore profitability and efficiency to the corp.
I find it hard to argue with some of his comments – and I’ve found some simpatico between his observations and what I’ve seen in Canada, so he’s not just shooting from the hip. So, I’m a fan of sorts – and apparently he has readers right up to the top ranks in the company.
However, it was his July 12/09 post that caught my attention – it highlighted a suspicion I’ve had:
For efficient product development: Yahoo!'s Carol Bartz has a good point when she swears like a sailor over having way too many program managers vs. actual developers (overloaded with one program manager for every three developers). <<edit edit edit - this went quickly into the weeds - let me sum up some quick thoughts>> Looking across groups, I still see exceptionally inefficient use of broad, front-loaded thinking and design locked into a 1970s waterfall model that leads to reality and focus coming way too late and a bunch of frantic, mediocre consensus driven crap floating like chunks into an end product. Kaizen. Kaizen. Kaizen. Efficiency is not going to happen as long as we continue rewarding people for this status quo. Shedding a respectable chunk of the company would bring an exceptional amount of upfront focus to our teams and result in high-quality features end-to-end, vs. what we see in misshapen compromise that we can fit in.
From what I’ve seen inside MCS, this is particularly the case – almost every large scale project is locked into a model that is predicated upon the Microsoft Solutions Framework (v3 or v4, depending on who you work with) which is, despite words to the contrary, very much single-pass/phased. This said, I do know that my experience runs contrary to what I’ve heard from friends in product groups who have embraced the Schwaber/Beedle Scrum text as their “Bible” for project delivery. Cripes, Schwaber himself has been to the Microsoft campus and has published books for Microsoft Press!
So, I really find it challenging to reconcile why we do things so bass-ackwards within MCS. From my training last year through all the projects I’ve engaged on, we have continual disconnects such as those Mini observes that enforce the worst of bad practices. For example, almost all projects are estimated and scoped up-front by folks who likely won’t be doing the delivery. This leads to predictable schisms when a new resource is assigned and they have to reconcile the commitments made by their colleague who’s now on another project.
The reaction has been predictable – more effort to try and improve consultants’ estimating skills so as to try and homogenize their view of any project. A fool’s errand, I fear. To expand on Mini’s quote above, the Kaizen principles most needed to understand and embrace are those of Muri, Mura and Muda – uneven process flow, overburdening systems and waste respectively. We could accomplish a great deal if we looked to the east.