Saturday, July 23, 2005

Scobleized

Recently, I was interviewed by Robert Scoble for Channel 9. You can see a whole hour of video as Robert questions me about Agile Management and what we are doing with MSF for CMMI Process Improvement. David Anderson - Writing Agile Software. I can only describe the experience as “like having David Letterman come to your office, only geekier!”

Sprintpcs.com

It’s interesting that Martin Geddes would post his memoirs of life at Sprintpcs.com recently - I had been thinking of doing the same thing. But before I do - a little background.

Sprintpcs.com was to quote its leader, VP and GM, John Yuzdepski, “the parting gift of Andy Sukawaty.” Sukawaty had been the president of Sprint’s PCS unit and had masterminded the bootstrapping of the business and the stock split which had created PCS as a separate tracking stock during the telecom bubble of the late 90’s and early part of this decade. I joined the company in 2000, just as Andy left. He, like many other executives at that time, exited with a handsome payout after the failed Worldcom takeover. Just a few short months earlier, he had, in response to pressure from analysts asking “what are you doing about the Internet?”, created the .com business unit, and appointed Yuzdepski, who was at the time, VP of Product Development, to run it.

“.com” as it was known had gone from being 2 people and 6 servers in a cupboard of the PCS headquarters in a tower block on the Country Club Plaza in Kansas City (or was that 6 people and 2 servers?) to a full blown business unit, in a self-contained building at 75th and Stateline Road with 250 people, in just a few months. A year later it would be 350 people. It was an unusual business unit within Sprint, a functionally organized company, in that it was a self-contained business unit. It had its own marketing, sales, finance, operations, and IT support departments as well as 5 development groups - I ran one of these - a large testing group and a user experience group. .com had been designed to be floated off separately - if that ever made sense down the line. Ironically, it was user experience and my uidesign.net site which had brought me to Sprint. I lasted as a UEA (user experience architect) all of 5 weeks. The chaos in .com in 2000, required my development skills and my agile experience with FDD. I took on managing the new mobile portal team.

As anyone knows, growing a startup business that fast is hard. It creates strain on people and there is a lot of chaos, as methods of working and processes, and lines of communication are put in place. Yuzdepski was very skillful at this task but nevertheless by the end of 2000, it was still chaos and he’d overspent his budget. He went begging to the executive committee for forgiveness and the result was a revolution, in discipline and professionalism, during 2001 which saw us do so many things right and in my opinion build the most agile organization I’ve yet seen. [Yes, there were politics and some funky issues with patronage and nepotism but none of that should stand in the way of what was actually achieved. The people involved have a lot to be proud of. It’s this good stuff that I plan to focus on.]

Over the next few weeks I’ll make a number of posts about things we did right at .com - the separation of functional management from project management, the measurement and recognition of a capacity in our “software factory” (as our Director of Operations called it), the monthly operations review with executive committee members present (which inspired chapter 14 of my book), the program management office and how we did the cross team program coordination and resolved resource conflicts and scheduling issues (this is one that I overlooked in significance when I wrote my book. If I ever get to do a 2nd edition, I’ll correct this mistake and give it a full chapter on its own) and finally I’m going to talk about an unusual approach to leadership training - the staff ride.

[I know that a number of ex-Sprint people read this blog including some of my old staff. If there is anything in particular you’d like me to cover - things we did well, where we showed agility and mastery of Feature Driven Development then post a comment or drop me an email and remind me.]

Friday, July 08, 2005

MSF for CMMI Process Improvement

My official MSF for CMMI Process Improvement workbench as MSDN is now available. The beta of the process guidance, but not the whole process template for Team System, should be available within a couple of days. A full process template should follow mid July with our July CTP release of Team System. The workbench web site pulls feeds from my new Channel MSF RSS feed. This is a filtered feed of blog entries related to MSF.

Thursday, July 07, 2005

CMMI and the Declaration of Interdependence

Back in February, I was involved in the creation of rallying cry for the adoption of agile techniques in project management. We called this the Declaration of Interdependence - six statement which we felt differentiated the agile approach from traditional teaching in project management. You can read my personal interpretation of each statement here: [1]; [2]; [3]; [4]; [5]; [6]. Shortly after publication I was challenged (via my Yahoo! group) to state how the DOI differed from existing project management frameworks such as the CMMI IPPD from the Software Engineering Institute. My initial reaction was to state that as the CMMI was a framework which didn’t prescribe specific practices it was likely to be compatible and despite frameworks like the CMMI, it was still possible that many project managers were practicing techniques which were damaging. I promised to do an analysis and post it here when it was done.

After 9 months of being deeply immersed in the CMMI whilst producing MSF for CMMI Process Improvement, including two visits to the SEI at Carnegie Mellon University in Pittsburgh, PA, I’m finally ready to make good on the promise - a gap analysis of the DOI against the CMMI.

[DOI] We increase return on investment by making continuous flow of value our focus.
[CMMI] The CMMI is pretty agnostic on this. It’s a “so what?”. It doesn’t break the CMMI nor does the CMMI ask us to do anything differently. Although the CMMI is written in a project-centric fashion, it does not rule out small increments of delivery.
#1 is compatible!

[DOI] We deliver reliable results by engaging customers in frequent interactions and shared ownership.
[CMMI] The CMMI actively encourages stakeholder involvement and has explicit activities for monitoring it.
#2 is compatible!

[DOI] We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
[CMMI] The CMMI is founded on the principles of W. Edwards Deming, his Theory of Profound Knowledge, the theory of variation and the concepts of special and common cause variation. Although some explicit text talks about “plan the plan, plan the work, work the plan” and has very “conformance to plan” language in some of the practice guidance, there is nothing about uncertainty, variation, adaptive planning, iterations and anticipation that is incompatible with CMMI. In fact the new MSF for CMMI Process Improvement does these things explicitly.
#3 is compatible!

[DOI] We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
[CMMI} The CMMI is very big on the idea of creating an organizational environment for success (where success is defined as achieving continuous improvement - in a quality assurance sense). There are explicit process areas around training and organizational environment. There is nothing in the CMMI which is incompatible with the DOI’s embrace of innovation and creativity and its underlying principle that people are assets rather than fungible cost centers.
#4 is compatible!

[DOI] We boost performance through group accountability for results and shared responsibility for team effectiveness.
[CMMI] Though many formal organizations which follow the CMMI use RACI designations and have individual accountability, the CMMI is really agnostic to this. What it asks for is that the agreement is written down in a Team Charter. Again, with MSF for CMMI Process Improvement I have designed it to exhibit group accountability and shared responsibility style with the team of peers concept carried over from earlier versions of MSF. This is perfectly compatible with CMMI.
#5 is compatible!

[DOI] We improve effectiveness and reliability through situationally specific strategies, processes and practices.
[CMMI] The CMMI explicitly expects situationally specific practices and processes and encourages it with explicit activities aimed at tailoring processes and practices for specific projects.
#6 is compatible!

Asking the question the other way, “Is there anything in the CMMI which is incompatible with the DOI?” is also an interesting question. There are 25 process areas in the CMMI. However, my take on it is “No! There is nothing at the process area and goal level which is incompatible with the DOI.” The problems arise at the interpretation of the specific practices. The DOI was born out of observation that project management practices as taught in so many places are leading to undesirable behavior and unfavorable results. The DOI seeks to reset the mind set (or paradigm) of how people think about projects so that they adopt the correct behavior that leads to good results.

It’s perfectly possible to be an agile project manager and be running a CMMI compliant process.

Agile Fence Painting

I nearly choked on my sandwich, mid bite, yesterday at lunch. My wife had just said, “You know it really pays to be thorough. All that rework is really time consuming and it uses a lot of paint!” So there was hope after all that my wife might understand what I do for a living.

We have been sealing the perimeter fence at our home. The building is 5 years old. The fence has never been treated since it was new. It was badly needing done and we had purposefully set aside some time at the beginning of July to do the job. The last two days we’ve been “painting” the fence around our house.

So how do you manage a domestic fence painting project? Well the agile way - naturally. You buy some wood stain sealer, some brushes and you start painting. You determine the velocity in fine-grained units of value - in this case, the amount of fence painted, not the hours spent painting it. The finest grain unit available is the plank. However, analyzing how many planks there were, sounded like, big analysis up front, to me. The next unit of granularity is, the fence section - a set of planks between two poles. Easily calculated - 22, in our case. The initial scope was to paint one side of the fence - the side we can see from the house. So we measured velocity after 90 minutes of painting - approximately 3 sections per hour. But we also noticed that some special cause outage was possible - children come and complain about stuff and need attention. So the low end velocity might be 2.5 sections per hour. If we hussle, the high end could be 4 sections per hour. So it should take between 6 and 11 hours to complete the job.

What about the available hours - the load factor? Well , we couldn’t dedicate the whole of the day to the job, so it was likely to take 2 days. What we weren’t to know was that one of our painters was too eager and would paint with poor quality requiring significant rework. This would affect both over all velocity and consumption of raw material.

What about iterative work cycles? Good idea! What value groupings make sensible incremental deliveries? Well the front section of fence, forward of the gate. The bit that can be seen from the street - 6 sections plus a gate - made sense as iteration 1. It was the highest value section, due to its public visibility. The next section at the side of the house (pictured) was another good incremental delivery but of low value. Then the gate and fence at the other side of the house onto the shared driveway. Finally, the fence around the back yard. So 4 incremental deliveries. 4 good “stopping points”. Note: the best value is delivered from appropriate domain specific groupings, not from a regular cadence of, say, 4 hour, sprints. Even though a regular cadence does facilitate the need for a tea break.

So, at the first iteration review - the cup of tea after completing the front section of the fence [Readers from the UK will note that British tradesmen often ask for a cup of tea on arrival at the job before commencing work. This is sure fire sign that you have hired a traditional big planning up-front tradesman, rather than a more nimble, better value, agile tradesman.] - we analyzed the raw material usage - 4 sections of fence per gallon of sealer. Issue: we didn’t have enough sealer to complete the job. So the project manager was dispatched to home depot to procure 2 additional gallons. This was done early enough that the painting team never ran out of paint and were never idle during assigned painting hours.

And finally, it occurs to me that this sealer has a 6 year life span. The next time this job needs done, my 3 year old will be 9 or 10. So it sounds like I can delegate the task, in exchange for pocket money, and sit back on my comfy patio furniture and “manage” the job with a long cool drink in my hand. I wonder whether the agile manager’s daughter will charge by the hour, by the section, or on a fixed price with a guaranteed quality level and delivery date?