Wednesday, September 14, 2005

MSF In The News Again

This well balanced piece of journalism looks at the new trend in agile management tools including Team System and its MSF process guidance. The piece manages to cover both MSF for Agile Software Development and MSF for CMMI Process Improvement as well as looking at rival products that support Scrum and Extreme Programming. It seems that the market is beginning to understand that transparency into the process of software development is a good thing. It leads managers to make better quality decisions and that’s good for everyone involved. I’ll be talking more about the benefits of transparency throughout the fall but especially at my keynote speech at EuroSUN in Copenhagen in November.

Tuesday, September 13, 2005

Rehearsal

So much in life requires practice. I do a lot of public speaking. Public speaking is performance. To get beyond bullet points, you need to remember that most of all you are telling a story and giving a performance doing it. Performance requires rehearsal. It needs practice. Sadly, I don’t get to do it often enough. Occasionally I have bad performances. The recent webinar for MSF was one of those. I had given the presentation to two sets of executives the week before. However, the same slide deck didn’t work for the web audience. What makes it even harder is the web provides for no feedback loop. It’s like radio. [You’ve got admire radio DJ’s - particularly talk radio guys.]

Back in 2001, when we launched the Sprint PCS Developers’ Conference, I gave one of the main presentations on the first morning. I had all the product and service announcements, following on behind our CTO, Oliver Valente, who announced the network upgrade for PCS Vision. During my presentation Daniel Vacanti came on stage and gave a 20 minute demo. That demo had been rehearsed to the n-th degree. We had presented it 4 times internally at Sprint. In addition to that, the team had scripted the whole demo and timed every mouse movement, and every click. When you have a large audience, at a glamorous developer event, you can’t afford for anything to go wrong. And it didn’t. The long evenings where Dan sat with other team members while the tracked him with a stop-watch and scripted the event paid off. Rehearsal made every go smoothly on the day.

The following year, my boss did a live demo of a new Java phone in a keynote at JavaOne. The demo failed on stage. It was highly embarrassing. Could a lack of rehearsal been to blame? Maybe.

I wonder how many other aspects of software engineering need rehearsal. How often do we create situations for software engineers to rehearse their actions? How many times in your career has your employer sent you on a boot camp? How many times do you get to build one to “throw away”? Rehearsal is all about being in a position to react appropriately under pressure. It’s the basis for cool heads. How many times do software teams get in to trouble and then react in a panic and make the wrong choices, the wrong decision - decisions that make the situation worse?

Uncertainty is out there. We need to train software developers to anticipate it and react calmly when it happens. We need to rehearse more.

Monday, September 12, 2005

Cohesion Advocate

I’ve been trying throughout this year to gradually replace posts about FDD with posts about MSF but FDD just keeps coming up again. Following a thread on the Yahoo! group today, I thought I’d mention this.

Rather than class owner in FDD, what if we called them “cohesion advocates” - members of the team who are given cohesion responsibility for a set of classes on the model? This was actually the original intend of the class ownership choice in FDD but it tends to get lost in the arguments about ownership and bottlenecks versus shared access and lack of constraints. The cohesion advocate model is a risk mitigation strategy. A strategy against cruft or technical debt creeping in to the code base. You don’t pay back debt because you don’t accrue it. Instead, you live with the constraint that classes have cohesion advocates who choose whether or not to grant write or edit access to others for the class file.

Tuesday, September 06, 2005

Prioritizing Requirements

There are many schemes for prioritizing requirements. They often take the form of enumerated sets like [1,2,3] or [High, Medium, Low] or [Must Have, Preferred, Nice to Have] or the one we’re promoting with MSF which started with the DSDM community in the UK - MoSCoW [Must Have, Should Have, Could Have and Won’t Have]. So here is the scoop! I don’t like any of these! Why?

Because they all need explanation. They all need some mapping. Some standard of what each term means and how to interpret it. Often this is never written down but is part of the tacit knowledge, or tribal lore of the organization. It doesn’t lend itself to repeatability and it doesn’t lend itself to good governance. I want a system which is better aligned with good corporate governance.

An idea I’ve been batting around for a while, but haven’t blogged, is based on strategic planning - use an enumerated set of [Table Stakes, Differentiator, Spoiler].

Michael Porter has suggested that from a strategic positioning perspective your business can be the cost leader (there can be only one), or a niche player (in market share terms), or differentiated (there can be many forms of differentiation). I like to use the example from my recent past in the wireless telecom business in the USA. There were six major players: ATT Wireless; Verizon Wireless; Cingular; Sprint PCS; Nextel; Voicestream (later T-Mobile USA). They were aligned thus: T-Mobile was the cost leader; Sprint, Verizon Wireless and Cingular were differentiated as the innovator, the best network and something called “the value leader”; whilst Nextel was a niche player in small and medium sized mobile businesses. That left ATT Wireless which was to coin Porter’s phrase “stuck in the middle”. Being in the middle is not good. Guess who got acquired first?

So, what does this mean and how do you play it? Well imagine you are offering a wireless email service. Your table stakes are all the basic features you need to be in that business. You need a network, you need handsets which are email capable, you need data service, you need an email server and so forth. Now imagine you are the cost leader - stop right there. You already spent as much as you need to. But if you are an innovator then you might want to do picture email. So you need to upgrade everything. If you are niche player in small business, you might want to do Exchange enablement and rich client concepts like reading .DOC files. If you are the best network, you might want a lot of non-functional requirements which insure the best quality of service. All of these are the differentiating features for your product mix selection. Finally, what is a spoiler? A spoiler is a feature which commoditizes one of your opponents differentiators. For example when Sprint and Verizon Wireless launched “push to talk” walkie-talkie features on their services, they were spoiling a lucrative market for Nextel.

So, an enumeration of [Table Stakes, Differentiator, Spoiler] allows us to directly align strategic positioning with operational marketing product mix selection choices with work done on the shop floor actually coding the features required. No need for any translation scheme. No need for tribal lore. Every need for everyone to be doing their job properly - strategic planners properly positioning the business against the forces of competition, marketers choosing a product mix which correctly selects features to target the strategic positioning and the desired goals in a given market, e.g. profits, share, prestige, and then for the agile team and project manager to correctly select the release and iteration backlog to deliver the product mix in a fashion which aligns with the goals and strategic positioning.

One big happy family. And everyone lived happily ever after and they all retired rich on their company match in stock 401K plan. Awe!

APLN Seattle Chapter Inaugural Meeting

This Thursday September 8th sees the first meeting of the Seattle Chapter of the Agile Project Leadership Network at Microsoft’s Redmond campus, building 25 from 5.30pm. If you want to attend contact Mitch Lacey, email to mitchl at microsoft.com.

I’m really excited about the APLN. I haven’t blogged about the founding board meeting which took place in Denver after the Agile conference in July. I was waiting until we could announce the formal association and its not for profit incorporation. However, the lawyers are still working on that. More when it happens.

Meantime, I am really happy with the way the APLN is forming. There is a strong consensus amongst the founders and board members that this new organization is primarily a network of its members - a professional craft guild for agile project managers everywhere. There is a consensus that it is there to serve its members and as such the government from the core will be small and the governance light. The organization isn’t in the business of competing against its members but rather encouraging the spread of agile project leadership craft. If you are interested not just in agile and lean techniques for project management but in a new kind of professional organization for project managers then I’d encourage you to join. If you get in now, you can start a local chapter and start influencing the direction of the organization and pushing the state of the art in agile project management.

The building of a network is core to the concept of the APLN and three local chapters have already formed - in Dallas, Texas, Milwaukee, Wisconsin, and Redmond/Seattle, Washington. If you are interested in forming a local chapter, I’m heading up the networking program for the APLN, so mail me - dja at agilemanagement.net. If you live in one of the 3 metro areas mentioned then follow the link and contact your local APLN chapter representative. Let’s build a great new professional body together.