The new Technical Note from the SEI which I co-authored has been causing a stir. My friend Adail Retamal has translated some of the somehwat cynical commentary from Brazilian agile and XP discussion lists. I'm excited to see so much debate on this and read these wonderfully creative comments...

Well, after some have found the Agile CMMI idea nice (this is a sign of the end times) , I can only propose an AgileWaterfall 2009 conference.

Some of the themes could be:
- Agility and Bureaucracy: get the best of both
- Waterfall made Agile: just burn out the documentation
- Agility with Control: Henry Ford has done it a century ago!
- XMMI (eXtreme CMMI): the 12 practices revisited under CMMI
- The CMMA Model: How Agile are You?

See how the first XCMMI practice would look like:

Pair Everything: Why only pair programming? Let's expand this agile
practice: Pair Analysis, Pair Design, Pair Project Monitoring and
Control, Pair Requirements Management, Pair Organization Process
Definition, Pair Quantitative Project Management, Pair Decision
Analysis and Resolution, etc. As you can see, with XCMMI, we have a
lot more pairs than with the regular XP.

If you send me enough good ideas, we'll even build a site like the waterfall'2006.

-------------------------------------

hehehe "Pair Decision Analysis and Resolution"

Some other ideas:
- Taskboard CMMI: all your documents printed and exposed on a white board visible to everyone.
- Daily meetings: 15 minutes every day... for every process.
- Chart burndown. Let's show all the metrics in a bunch of burndowns!

And so on :D

-------------------------------------

Extreme Waterfall:

Just 4 Values, 12 Practices, 5 Years and 12 million dollars!

Values (aka, The Cobra Kai system):

Fear - code is dangerous, code is your enemy. Run away or hide from
code if you can. If you can't, pray. Pray VERY hard.

Silence - it is golden, gold means money and money is good. If you
can't say anything good about the system, shut up. We don't need your
negativism!

Aim - measure a thousand times and cut once. After all, systems are
very much like diamonds!

Practices

Stand-Up Coding: coding 15 minutes a day keeps tendinitis away.
Feudal CodeBase - Be the Lord of Thy Land, keep invaders at bay,
punish trespassers.
Weekly Iterations - based on Pluto's calendar.
40-Hour Weekend - times flies with pizza and cola!
Lego Design - 5 generic components is all you need to build any
system. Take a look at Assembly. Technorati tag: David+Anderson, agile+management, CMMI

[First pusblished at moduscooperandi.com] More than 4 years ago, I riffed off Jim Collins idea of a corporate Hedgehog Concept, with this blog post on Personal Hedgehog Concept. It's proven to be one of the most popular blog pages on AgileManagement.Net since I started it in August 2003.

The original post used the career of Cameron Barrett as the example. At the time, Cam was pursuing his passion for politics supporting the campaigns of Democratic candidates Wesley Clarke and John Kerry. However, recently I was challenged by Liza Raiser to explain what the Personal Hedgehog Concept means to me.

Actually, I've been working on my own hedgehog concept for most of the past 8 years.

 

First, what am I passionate about? For a long time I've been passionate about the underperformance of the software engineering profession and the low rate of success on software development projects. In fact, I was so disgusted with the profession I intended to quit almost 10 years ago. It was thanks to Jeff De Luca, and the original FDD project in Singapore that I regained my enthusiasm for the profession.

So what can I be one of the best in the World at? It's taken a while, but I started down the path to publishing and what we now call blogging in 1999 at the behest of Peter Coad and Jeff De Luca. 4 years later, Peter was instrumental in assisting me with the publication of Agile Management for Software Engineering. I've continued to work at improving my ideas on software engineering process and management of knowledge workers and I've continued to work as a practitioner in regular jobs managing software engineers - until recently, when I formed David J Anderson & Associates.

So what changed? Well finally, I was able to realize my Hedgehog Concept. Finally, my skills with software engineering process and management and leadership of knowledge workers were in sufficient demand that they could drive my economic engine. Let's be under no illusion! There is little to no premium in the market for good management in the software and IT industries. While great individual contributors often become independent contractors and earn high hourly rates, the same does not generally apply to managers. And while employers might be willing to pay a 10%-20% premium for a decent person, often a great manager find him/herself earning far less than the top technical people on the team. This is despite the hard economic evidence that it is management talent that generally constrains the performance of software engineering organizations.

So, for a long time, I've known that I had to break out of working as a manager for other people and start my own firm. The question was when? When would the timing be right? Finally in 2008, with a track record that includes successful projects and teams at Sprint, Motorola and Corbis and with a catalog of intellectual property that includes my contributions to FDD, the MSF for CMMI Process Improvement and most recently my contributions to Lean in software development and the innovations with the Kanban method, I finally have sufficient recognition and respect in the industry for it to drive my economic engine.

Along the way, I've also resolved my own inner conflicts about whether I had taken the correct career path. I've finally come to realize that management and leadership is my real strength and that other things I enjoy are merely hobbies, like painting, art and design, and my synthesis of those talents in user interface and interaction design. It was in fact user interface design that got me started down this road, with my uidesign.net site. Recognizing in myself what I could be World class at, from the things that I can be merely good at, has been the foundation of a new happiness in my life.

So here we are! I'm having the best fun at work since I quit the games industry in the late 1980s and I'm happier than perhaps I've been since leaving Singapore in 1999. Finding my Personal Hedgehog Concept has been at the root of that happiness. It's been a long slog - more than 8 years. A journey of personal discovery. But ultimately it's been worth it. And now I am excited about the future where I intend to continue innovating in leadership and management of knowledge workers and helping teams deliver superior economic performance.

Are you working on your Personal Hedgehog Concept?

[First published at moduscooperandi.com in a slightly different form]

At David J Anderson & Associates our strategy is to help clients achieve long lasting, institutionalized, enterprise scale agile change. We help them to become what the SEI calls a "high maturity" organization while continuing to use Agile and Lean methods throughout their technology functions. To achieve this we go about changing the organization's culture. Lasting change takes time. To do it properly can take 9 months to several years. It requires a serious commitment to achieving high maturity - quantitative management, predictability and continuous improvement - from the senior leadership. That's why many of our clients have C-level titles.

However, not every client needs long term institutional change. So should we turn those other clients away? Perhaps! But not if they truly need us to meet their immediate, tactical goals. I've been amazed by the clients we meet who open up the discussion with "I've been reading your ... <insert book, article, etc.> and I've decided that the solution to our current problems is... <insert methodology FDD, MSF CMMI, Kanban>."

I've been amazed at the demand for FDD and MSF for CMMI Process Improvement. By adding Daniel Vacanti and Eric Willeke who can help us deliver FDD and MSF CMMI projects, we have the skills and experience to respond to demand and provide staff augmentation when necessary.

With these types of clients they have an immediate tactical need. Perhaps they have a mission critical project that is late and over-budget. They need us to dig them out of the hole. So we do that for them. Their need is tactical. They are not concerned about institutionalized change. They are not concerned about resistance to change. They will use positional power and require staff to acquiesce or drop out. Delivery of the project is success for them. And if the process doesn't survive past the delivery of the project then so be it. Technorati tag: David+Anderson, agile+management, CMMI, FDD, Kanban, MSF

[Over the summer, I wrote a number of blog posts for Modus Cooperandi. I'd like those posts to get a wider audience. Starting with this one about the relevance of level 4 organizational maturity...]

CMMI Model Level 4 is often thought of like Nebraska or Kansas - it's the flyover territory of CMMI. The big offshore outsource companies often think of Level 4 as something that they can skip - jumping from level 3 to level 5. After all, there are only 4 process areas. Two in Level 4 and two in Level 5.

When I was at Microsoft, working on MSF for CMMI Process Improvement, we talked about the future prospect of an enhanced edition that provided full coverage of Level 4 and 5. [The current release has about 80% coverage of Levels 2 and 3, and 20% coverage of Levels 4 and 5.] There was no market demand for a Level 4 solution. Our market research was telling us that there was a market for a Level 3 solution - the one we produced - aimed at the government contracting market in North America and the ISO 9000 compliance market in South America. We also knew that there was a market for a Level 5 template for TFS - mostly aimed at the offshore outsourcing companies. Level 4 just didn't come in to our plans. It was flyover territory. It seemed no one does Level 4. If you look at the list of CMMI appraised firms, there are very few at Level 4. So why am I suddenly a big advocate of Level 4?

Well, it seems from discussions with clients and potential clients in America and Europe, our clients need to have the equivalent of Level 4 organizational maturity in order to meet their business goals and strategic objectives. They don't need to be an optimizing organization at Level 5 - that would be icing on the cake. But they do need to be predictable. They want to have strong delivery with low variability. The want to be proactive and drive down cycle times using objective quantitative management. They need all of this to deliver on business goals within the tight financial controls and corporate governance that they now find themselves under. They need to be the equivalent of Level 4.

The real problem is that typical Agile methods can only take them to Level 3. So Agile isn't enough. That's where we come in. Our experience in creating cultures that drive towards high maturity (Levels 4 and 5) while implementing Lean and Agile techniques is still fairly unique. We help clients reconfigure their organizational culture to enable a high maturity organization to emerge while still gaining all the benefits of Agile and Lean methods.

The aim is to generate a clutch of Level 4 equivalent organizations. Clients who can estimate projects and iterations and deliver results with a low degree of variation from the original estimate. Firms who use predictive methods and leading indicators to learn and adapt quicker than those simply using retrospective methods and lagging indicators. And businesses who are led by objectivity and have left superstition and subjectivity behind in their organizational past.

CMMI Model Level 4 has real business relevance. Business that achieve it will achieve their business goals, hit their numbers and delight customers, shareholders and employees. Getting to Level 5 will allow a firm to become ever more competitive and to dominate their market. But for many firms the need to achieve the equivalent of Level 4 maturity is a business imperative, now! Anything less will leave all stakeholders dissatisfied. Technorati tag: David+Anderson, agile+management, CMMI

Karl Scotland has a good introductory article on how to do kanban for software engineering. Karl likes to use the catchy acronym KFC - Kanban, Flow & Cadence. Another useful addition to the body of knowledge on kanban. Thanks Karl! Technorati tag: David+Anderson, agile+management, Kanban, Karl+Scotland, Lean, Software+Engineering, Project+Management

I'm going to reprising my key note from Brazil at the Bay Area APLN meeting in San Francisco on Monday night November 3rd. I hear that RSVPs have been strong already. If you'd like to come along, details are here. Technorati tag: David+Anderson, agile+management, APLN

Here are a few pictures from my 2 day Zen of Agile Management class in Sao Paulo this week. I'd like to thank Adail Muniz Retamal of Heptagon for organizing the event and hosting me in Sao Paulo. The class was a huge success and I hope to be back in 2009 teaching it again and expanding the offering to include Agile+CMMI and FDD+Color Modeling. If you are interested in attending these classes in Brazil please get in touch or contact Adail directly.

Explaining advanced iteration estimation and planning by showing how to incorporate the velocity of the bottleneck, and its spread of variation, the anticipated waste as transaction and coordination costs against the iteration, and insuring against external (special cause) variations by buffering the schedule. This technique for estimating is both quick, as it's based on historical data, and compatible with high levels of organizational maturity that require predictable (low variability) and quantitative management. It's good all this material was included as the participants included folks from CMMI level 5 organizations.

The class breaks out into four teams for the exercises. Here they are trying to imagine how to destroy trust in an organization. ;-) We do this exercise to help them reflect on angti-patterns that exist in our organizations. Not so that they go home and implement it. :-D

And after a long tiring 2 days, it's 6.30pm on Wednesday and time to celebrate and decant to a local hostelry for some chopp and pastel.

I'd like to thank everyone for coming. I really enjoy teaching this class and you it wouldn't be the same without each and every one of you. Technorati tag: David+Anderson, agile+management, agile+CMMI, agile+brasil, Adail+Retamal, Heptagon, agile+Sao+Paulo

Eric Landes of Robert Bosch, one of the earliest adopters of kanban, and an enthusiastic member of the kanban Yahoo! group, has a pragmatic article on implementing kanban for software maintenance published at developer.com.

"But how will limiting our work to one item at a time increase our productivity?" Tristin asked. Jake replied, "That is a great question, Tristin. I believe that the multitasking of requests that we currently have is not an efficient way to work. A blog post I read from Johanna Rothman mentions the evil of multitasking and how it is the root cause in reducing an organization's throughput. We want to focus on the right things. I believe that focusing on work until it's completed should increase quality and eliminate the waste encountered when switching between tasks."

Congratulations Eric!Technorati tag: David+Anderson, Eric+Landes,Agile, Lean, Kanban, Software+Engineering

I've been greatly encouraged by the feedback from my Agile 2008 Main Stage presentation. It was so fortunate that InfoQ chose to video it and make it available to a wider audience. I came across this reall detailed summary by Reinout van Rees.

However, there is a brief mention of something I've heard elsewhere. My assetion that a high level of organizational maturity is required to achieve institutionalized enterprise scale agile adoption, is being misinterpretted as me saying teams must seek an CMMI appraisal in order to deliver on their goal of enterprise agility.

from Reinout... In David's opinion, kanban is the method that can help us achieve both agility and high maturity. It will push us forwards. It creates a cultural shift. A shift that allows some teams to reach cmmi level 4 certification.

I am not saying that appraisal is necessary. What I am saying, is that the CMMI is an existing model for organizational maturity. It is a model with 20 years of learning and iteration built in to it. The people in charge of it are still learning and still iterating. My observation of real teams adopting agile is that they appear to more or less follow the CMMI's model of organizational maturity. In other words, level 2 practices appear first, then level 3 and so on. My conclusion from this observation is that the CMMI model for organizational maturity is more or less correct. Close enough to be good enough.

What I've observed with teams pursuing a kanban approach is that it creates a culture suitable for the CMMI generic practices that lead to high maturity. In addition, kanban appears to create an appropriate framework for the practices in levels 2 and 3 of the CMMI model to emerge naturally/organically/spontaneously without the need for a CMMI process initiative. This is a significant win because a common anti-pattern with CMMI is "management by objectives" where the objective is to get an appraisal at a specific level.

Hence, what I am saying is, if we know that a high level of organizational maturity is a key indicator of success with enterprise scale adoption, then it makes sense to pursue organizational maturity as a driver to success. If pursuing organizational maturity is goal then we need not re-invent the wheel. We can follow the model that the Software Engineering Institute has provided us. Getting a CMMI appraisal is not part of the message at all. An appraisal might make sense if you are in a regulated industry, have a business driver for an appraisal such as competing for government contracts. However, appraisal does not enter my message concerning success with enterrpise scale adoption. The message is...

A high level of organizational maturity appears to be essential to successful enterprise scale adoption. There is an existing model for organizational maturity that appears to be broadly correct. That model is CMMI. Technorati tag: David+Anderson agile, CMMI, SEI, Software+Engineering, Management

Today, I packed up my desk and books and moved out of the Modus Cooperandi office on Lake Union in Seattle. Going forward, my new business entity is David J. Anderson & Associates Inc..

This change may seem a little strange to many as the Modus Cooperandi name is largely associated with me. The reality is that the name was first registered by my business partner Jim Benson. We started Modus Cooperandi with the intent to build a software company focused on social media for the enterprise. The management consulting practice was intended to help fund and bootstrap that software business.

With the current economic climate, I decided to focus on management consulting and minimize the overheads the business was incurring. Meanwhile, Jim has a passion for social media and for food and eating out. He has been building a pratice to offer consulting services to restauranteurs and publicans. As this is really his personal hedgehog concept, I feel he should pursue that. He wanted to keep the Modus Cooperandi name as he originally thought of it and registered it. While changing my business name and entity is very incovenient, I feel it was the right thing to do. So Jim continues with Modus Cooperandi. And I start again with a new business entity.

From a the perspective of prospective clients, nothing has changed other than the name to use on the contract. Existing contracts with clients written under the Modus Cooperandi name will be fulfilled. It is likely that most of the existing associates will follow me to the new business - Daniel Vacanti, Corey Ladas, Oksana Schubert and Eric Willeke have confirmed that they'd like to be involved.

So onwards... The new business online presence is aliased at davidjandersonassociates.com, and djandersonassociates.com and djaassociates.com. For now the site has a mirror of the agilemanagement.net content. Expect that to change at the end of November when I get new corporate content up-and-running. Technorati tag: Modus+Cooperandi, David+Anderson

The partnership deal between Modus Cooperandi Inc., and Valtech Inc., came to an end at the beginning of October. As a result I am no longer the Chief Process Scientist with Valtech. I don't want to disclose too many details publicly but it seems Valtech significantly restructured their business in the United States, reducing the work force and cutting costs. The partnership with Modus Cooperandi appears to have ended as part of that restructuring.

For those attending the Agile Edge event in London, my participation at Lords is unaffected. So I will be delivering the key note speech on 28th October. See you there! Technorati tag: Modus+Cooperandi, David+Anderson, Valtech

This is an updated test

I'm late to the Twitter party - embarrassing for a guy with a business that claims (at least in part) to be consulting in the social media space. So if you tweet, you can now follow me on Twitter at twitter.com/agilemanager. Technorati tag: David+Anderson, Agile, Management

For ages, Nick McCormick's little book on leadership, Lead Well and Prosper has been lying on my desk waiting for me to blog about it. I've moved offices. The first copy got lost. He had to send me another one. :-S But finally I'm managing to blog about it.

It's under 100 pages and has 15 chapters. 15 successful strategies for becoming a good manager. One in each chapter. It's a very readable straightforward little book. You could read it all in a single sitting. It's got some lovely funny cartoons. The end of each chapter has a short bullet point summary of do's and dont's.

You might find yourself nodding thinking - yep, I know that! yep, that too! But it is often advice we struggle to use in our lives as managers and our relationships with others in the workplace. However, this stuff is so hard to do. Take Chapter 11 for example, "Clean up your own house first" (actually advice I heard continuously from my boss at Sprint, John Yuzdepski. He really believed that as a business unit we had to demonstrate we could run the web site perfectly before we raised issues with the IT or network folks). So here are the bullet point advice from the end of chapter 11.

Do's

• Keep a positive attitude
• Voice concerns constructively. Be prepared to offer solutions - and work them
• Vent occasionally to your boss but not with peers or team members

Don'ts

• Disparage other people or groups within your company
• Be a whiner. It is OK to raise concerns
• Vent to peers or team members

This is great advice! It is just hard to do. The suggested action is to pick a problem you have with another group and pull the team together and try to work it out. Encourage collaboration. Don't let it turn in to a blame fest. Keep the focus on the solution.

Of course, all of this assumes the manager of the other group actually wants the problem solved and that they are willing to collaborate with you. They might want the problem solved but only if they get to take credit for it. So it doesn't work if the initiative comes from someone else. Good management and (some aspects of) leadership can be taught/learned. This is a great little book for that. But ultimately, no end of advice will overcome dysfunctional people in your organization. Technorati tag: Management,.Leadership, Book+Review, Nick+McCormick

My long time colleague and collaborator Daniel Vacanti does not blog. He occasionally writes stuff down and some of that might even get published one day, but he doesn't blog. So I'm going to blog for him today...

Dan has his own alternative to my Recipe for Success. I thought it might be interesting to list Dan's four hot points and then add some commentary.

1. Break work down in to small fine-grained similarly sized elements
2. Prioritize
3. Emphasize quality throughout the lifecycle
4. Make frequent incremental releases to production

Number 1 requires that each work item is independently testable and preferably independently deployable

Number 4 requires the use of latent code patterns (assuming a single code line is being maintained in a continuous integration fashion) to prevent code that isn't ready for release from escaping in to the wild accidentally. It also requires that latency is added to the test suite as a standard part of testing prior to release. Test the functionality being released and test the latency of the functionality that is complete but not being released.[Why does this happen? Well completed functionality may belong to a different project with a different release schedule but may be living in the same code base and environment. This is more likely to occur in an enterprise environment than a product or service company.]

Comparison and Commentary

Breaking work down to small fine-grained similarly sized elements has been a core part of Feature-Driven Development (FDD) since the days when it was still known as the The Coad Method (circa 1995). I made this a key tenet of the message in my book. So why did I drop it from the Recipe for Success? The recipe was originally called "low hanging fruit" and was supposed to highlight 4 things that a new manager could do to quickly generate improvement in a dysfunctional team or project. I've been under pressure (from commentators on this blog) to add a fifth element to my recipe, stating that reducing variability in the process is also important. The notion that we break work down to small fine-grained similarly sized elements is precisely the same idea. It's a low variability play.

I didn't include reducing variation in the Recipe because in my opinion it is hard to do and meets with a huge resistance. It asks people to heavily change their behavior in such a way that they don't comprehend the benefit. My belief is that while a team gets on with the 4 steps in my recipe, they will eventually realize that they have to reduce variability. In other words, reduction of variability is a higher maturity activity. No coincidence, in my opinion, that the same idea appears at CMMI level 4. A High Maturity level in CMMI.

Dan's view can be made to work through strong management and enforcement through positional power. The team can acquiesce or move elsewhere. While this can have tactical advantages, I'm on record several times since August 2006 stating why I don't believe in using position power like this. Acquiescence is not conducive to institutionalization and long term adoption of an approach. Hence, I believe that you fix other things first and let variability reduce over time.

Dan includes prioritization and he puts it at number 2 while I had it at number 4. Again, my reason for this is that it is hard and it requires the collaboration of people from other departments outside engineering. Of the low hanging fruit, it is the highest placed and hardest to obtain. Hence, while Dan and I are in agreement, I feel that some basic organizational maturity is required before prioritization can be done successfully.

We're in complete agreement over quality. As Robert C. Martin said in his after dinner speech at Agile 2008, "The jury is in on this one!"

Finally, Dan suggests that frequent incremental releases to production are key. And yes they are! So why doesn't it appear in my recipe? Well I like Dan making it explicit. The notion that your reduce (or limit) work-in-progress appears at number 2 in my list. You can't achieve this without being capable of making frequent incremental releases to production. However, as I said, I like that Dan makes it explicit. It was explicit in the Principles Behind the Manifesto and it still should be.

So Dan's recipe and mine are not so different. The order and emphasis is a little different. Dan wants to focus on reducing variability. If it were in my recipe, it would be number 5. We agree on quality, small amounts of work-in-progress released to production often and prioritization. The one thing Dan misses from my recipe is balancing demand against throughput. This is the mechanism I use to achieve sustainable pace and to implement a pull system which provides a nice mechanism for simple prioritization. Prioritizing becomes easier when you have demand balanced against throughput of work items.

Combing Ideas

So if we combine Dan's recipe with mine, we'd get something like this...

1. Focus on Quality Throughout the Lifecycle
2. Reduce (or limit) Work-in-Progress and Release it to Production Frequently
3. Balance Demand against Throughput
4. Prioritize
5. Reduce Variability in the Process by analyzing work items in to small, fine-grained, similarly sized elements that are independently testable and deployable

:-D It won't fit on a T-Shirt quite so readily ;-) Technorati tag: Agile, Agile+Management, David+Anderson, Daniel+Vacanti

A post in the Agile Management Yahoo! group has prompted me to make this second post with an example to elaborate on prioritizing and planning for market risk.

Steven Gordon wrote:

This approach seems oversimplified to me. In particular, I challenge the assumption that the low risk items should always be implemented first. For example:

1. A company might not even choose to bother with the market unless they can bank on a successful differentiator. In this case, shouldn't at least a slice or two of the intended differentiator be developed very early to obtain market research feedback on whether the idea really is a differentiator, whether it is really feasible to develop, and whether it might need tweaking or rejection.

2. A truly innovative differentiator can reshape the market and development vision of the whole product. Such a paradigm shift could totally change how the commodity features should be presented and developed.

I am more comfortable with the general notion that features should be delivered in order of immediate value than risk or risk of change. So, differentiators that have a large impact on how the whole product would be designed or on whether the project is even worth doing have large immediate value.

Here is my reply...

I believe a real world example would help. Let's imagine we are going to enter the cell phone market. Let's first define the table stakes commodity features. As entering the cell phone market has a huge setup cost, it will be necessary to offer a broad service attractive to many market segments. As I mentioned today's post really only deals with a single market segment.

I like to keep blog posts to under 1500 words and I will deal with market segmentation and product mix later. So let's try to define the general subset of features that represent table stakes for entering the cell phone market.

We will need...

A cell tower network
A deal with a long distance carrier to back haul our calls
A PSTN/SS7 telephony stack and associated infrastructure
Dial-tone
Ring-tone
Call setup across multiple networks
Call tear down across multiple networks
A Billing system with the ablity to bill individual calls and reconcile billing across networks to terminating or originating networks
An SMS Gateway
A Voicemail system
Handsets (one model might suffice but unlikely) with firmware to support voice calling and SMS messaging
Address Book feature on the handset
Inbox Feature on the handset
A support infrasture and call center
A market channel / delivery mechanism - such as a retail network

While we could argue the fine points of this set of features, the evidence from the market suggests that they are broadly correct. For example, if we study the MVNO market entrants in this century such as Virgin Mobile USA. Virgin rents its network from Sprint. At the time the deal was struck Sprint did not offer SMS messaging. It offered a rival service and technology from Qualcomm. Virgin thought it sufficiently important to include SMS that they deployed their own gateway to augment the Sprint network infrastructure.

While other features may be argued as "table stakes" the reality is that they are probably table stakes for specific market segments rather than the general market. This is a common problem with many firms. They do not perform good market segmentation and fail to truly understand which features of their product or service relate to specific segments. As a result they believe the table stakes are higher than they are. Smart market insurgents can exploit this situation by offering bear bones or white label products or services that offer just barely sufficient functionality to a market that needs unsophisticated features. A recent example of this would be the market entry of Google Docs which started life as a barely sufficient word processor that was only slightly more advanced than Notepad.

You suggest that differentiating features should be developed early in order to test them in the market and prove their value and market acceptance. I believe you are confusing research with production development. I believe these are parallel activities. Returning to our real example, let's imagine a differentiator is picture messaging. It would not be possible to demonstrate this feature on the production network without first delivering the table stakes. Though it is technically possible to skip the deployment of the SMS gateway, there is an issue with market acceptance if the SMS service is not offered.

However, the cell phone operator could test the market for picture messaging using research equipment. A COW (cell on wheels) could be deployed for market research. Typically COWs carry new network technology that is not deployed in production. COWs demonstrating full W-CDMA technology were available in 2001/2002 while most operators are yet to deploy W-CDMA for general use in 2008.

If you are able to deploy a differentiator prior to completion of the all the table stakes features then you simply haven't done your market segmentation and feature classification properly. The table stakes that remain to be completed are probably related to specific segments and not to the segment where you are testing the new functionality.

You state that value is more important than market risk or risk of change. Really? As recently as 3 years ago, I probably agreed with you but I've come to realize that I'm wrong. Why?

First, value is very difficult to define. Value is contextual and context is temporal. At best definitions of value are crystal ball gazing and are projecting value today based on market conditions today. Let's imagine that a new feature envisaged as a differentiator is planned. Let's say it is picture messaging and market research suggests that it is worth a $10 per month increment in MRC (monthly recurring charge). The lead time to develop it and deploy it is 18 months. 12 months in to the project a rival network launches picture messaging at $7 per month. What is picture messaging now worth? First it is no longer a differentiator. It is a spoiler. And it is probably not worth $7 per month but somewhat less. Either the price falls, or the size of the market falls because the insurgent stole some of our market share while we waited to bring the feature to market.

Let's now imagine that the competitor launches the feature early in our development cycle. Say month 2. The feature is a differentiator for a small market niche. Because we are following your strategy of prioritizing value first, we are building this differentiator first. We have started work. Have sunk cost in to it. When the competitor launches we redo our market forecasting and come to the conclusion that the feature is no longer viable. The cost outweighs the perceived gain in the market. So we cancel the feature and order another one. We just wasted valuable energy that could have been used developing a lower risk table stakes, cost saver or spoiler feature that is still awaiting engineering.

Hence, there are two reasons for not pursuing a value first strategy. The first is that value is hard to define and has a high variability to it. The second is market risk that puts the viability of the feature at risk. It's simply bad use of real option theory to prioritize something before we have enough information to be sure that we want the feature delivered. Technorati tag: Agile, Agile+Management, David+Anderson, Real+Option+Theory

Three years ago this week, I introduced a scheme for prioritizing requirements that was aligned with strategic planning and market segmentation and brought some rigor and objectivity to the art of assigning a priority to requirements.

Initially, the scheme introduced 3 classifications: Commodity (or Table Stakes); Spoiler; and Differentiator. Later I realized a 4 category was required, Cost Saver. With two possible sub-classifications of cost saved by the customer (lower cost of operation or displacement of other costs), or cost saved to you the producer of the software / operator of a service. These four classifications have survived almost 2 years without revision and seem to be quite stable. I think of this system as a lightweight, and very fast alternative to Kano modeling.

Since 2006, I've been exposed to Chris Matts and Olav Maassen's Real Option Theory thinking. Some of you may recall I was skeptical about real options after seeing a presentation in Munich in early 2007, that attempted to use the Black-Scholes equation from financial option theory to assist prioritization decisions. I pointed out that we weren't ready for real options because we couldn't furnish the equation with sufficiently accurate data. Well the Matts-Maassen approach to real options does without Black-Scholes and is the better for it. Matts-Maassen tells us to push back decisions as far as possible and to gather information, create options and understand when they expire. This helps us to optimize decision making and minimum the risk of a decision being a bad one.

We can treat the requirements in a backlog of features/stories as options. Now we can consider the market risk and likelihood of change occurring to a specific requirement based on its classification. We see that commodity/table stakes features have the lowest market risk. When did you ever hear of the table stakes going down? and that differentiators have the highest market risk.

Figure 1. Mapping Requirement Classification to Market Risk

Commodity features are unlikely to change because the table stakes for market entry never go down. They only ever go up.

Cost Savers are more likely to suffer change during the life of a project but still very unlikely. There is some risk that the cost is mitigated in other ways or that shifts in the market, strategic plan, or go-to-market initiatives of the business may de-prioritize the need to save costs. Hence, there is some risk that cost savers may be dropped from scope or unneeded before the project is delivered.

Spoilers are features being introduced to spoil a competitors differentiator. They primarily protect market share. The main risk with spoilers is that by the time they are introduced they have essentially become table stakes. This doesn't really affect our planning decisions. What would affect a planning decision would be a choice to focus on a different market and concede an existing market to a competitor with a more compelling offer.

Differentiators are the most risky because they may turn out to be features that the customer will not want. They are essentially experimental in nature. If the customer likes them then they are worth a lot of new profit margin. If not then they don't produce profits. There is also a chance that a delayed differentiator is in fact a spoiler by the time it comes to market.

Now applying what we know about market risk and using a real options approach to decision making and prioritization, we should delay risky items that are likely to suffer change until the last possible moment. This implies we should code up all our commodity features first and delay differentiators until closer to the release date. This is shown in Figure 2.

Figure 2. Planning a series iterations using market risk and feature classification

[I first presented this material at the APLN Summit in Seattle in July 2008 in response to an audience question and then later as a 5 minute "lightning talk"at Agile 2008 in Toronto.]

I have more to say about this approach as the model presented is somewhat simplistic and only accounts for a single market segment. I also want to discuss how this approach relates to the Minimum Marketable Feature (MMF) approach first presented in Software By Numbers. Chris Matts has been marrying up MMFs, with his Feature Injection analysis technique and Real Option Theory. In a later post I'll discuss my own views on this and how I see it relating to the model I've presented here.

And finally, I'm looking for a name for this model. I've kicked around names like Strategic Alignment Prioritization Analysis (SAPA) but I'm not entirely happy with anything I've come up with. Please leave your suggestions in the comment box. Thanks.

Related Articles
Prioritizing Requirements, September 6th, 2005
Revisiting Prioritizing Requirements, December 26th, 2006
Why we are not Ready for Real Options, February 20th, 2007
Exploring Real Option-based Software Engineering, February 27th, 2007
InfoQ: "Real Options" Underlie Agile Practices, June 8th, 2007
Technorati tag: Agile, Agile+Management, David+Anderson, Real+Option+Theory, Chris+Matts, Olav+Maassen

For several years, I've been promoting the notion that "Trust is the essence of agile." Others like Clarke Ching have joined that chorus [See Carnival of Trust]. This year, I've been articulating that the statement "[We value] Customer Collaboration over Contract Negotiation" was the statement in the Agile Manifesto that really captured this concept. High trust, high social capital cultures allow the overheads of contract negotiation, commitments, audit and arbitration to be eliminated - saving time and money.

But it was back in December 2007, when I was in Belgium for the Javapolis event, giving an evening talk to the Belgium XP Users Group that some of the Dutch attendees came up to me and said, "So, if agile is all about high trust culture and Holland is one of the highest trust countries in the World, why is agile adoption in Holland so slow?" This got me thinking.

The answer came to me early this year, while I was reading Collapse by Jared Diamond. This is a book many claim to have read. It is a best seller. You can get it in many airport bookstalls. But it is one of the most dense and detailed texts I've undertaken to read. It took me about 4 months to read it through. But it was worth the effort. The most valuable and relevant insight for us, in the Agile community, I would suggest comes in Chapter 9 during the discussion of the demise of the Greenland Norse.

The Norse were actually in Greenland before the Inuit. They were eventually displaced by the Inuit who were moving south as the Earth cooled in the early part of the 2nd millenium AD. The climate change eradicated the Greenland Norse. The Inuit were not native to the region. They had moved in and displaced the Dorset people to the North some centuries earlier. They rarely encountered the Norse but when they did it led to fighting. Eventually, the Inuit eliminated most of the Norse population in a battle one summer. The following year the rest of the population appears to have perished in the winter. So what went wrong?

It seems the Greenland Norse would not change and would not adapt to changing conditions around them. They remained European. And practiced European farming methods. They had a European structure to their society including a cathedral, bishop, and tribal hierarchy associated with government. They took their lead from these civic and religious leaders. It seems they stopped eating fish early in their tenure in Greenland. Why? No one knows. They maintained a mainly European diet, consisting of animals and crops they farmed. As the climate cooled, the yield from the land would not sustain the animals and crops and they eventually starved to death.

Meanwhile, the Inuit thrived. The Norse had the opportunity to observe the Inuit. There are writings. In fact every Norse encounter with the Inuit appears to be documented. It seems the Norse believed themselves superior to the Inuit who were savages and heathen as they were not of the Christian (Roman Catholic) faith. Hence, the Norse did not value the Inuit or their methods. But the Inuit were thriving. They had fast canoes. They could fish. They ate fish. And they had survival techniques that allowed them to cope with changing conditions. But as the Norse slowly perished they did nothing. They refused to change.

To (perhaps overly) simplify, the Greenland Norse were a conservative culture. They stuck to what they new. The continued to do things the way they always had and they hoped it would see them through adversity. In the end, this conservative approach that was resistant to change and preferred the status quo was what killed them. Had they been a liberal culture, ready to embrace new methods and open to the influence of other people and their ideas, then the Norse may well have adapted and eventually assimilated with the Inuit and lived harmoniously with them. But they didn't. Refusal to adapt to change killed them. They ceased to exist in the 14th Century.

So, this brought me to the conlcusion that the ideal circumstances for Agile to thrive and gain adoption were in cultures that have both high social capital (high levels of trust) and are liberal (small "l") in thinking and open to new ideas, new thinking and influence from outsiders. While Holland is seen as a liberal country in several social ways - soft drugs are legalized (regulated and taxed) and so is prostitution - in business Holland is a conservative country. Any Dutch people I've discussed this with have tended to nod vigorously.

The other very high trust culture where Agile has struggled for adoption is Japan. Again, despite the goths in Harijuku on a Sunday, in business Japan is truly a very conservative culture.

So where is the broadest Agile adoption in Europe. It's mainly in Britain, and the Nordic countries. The Scandavian countries (Norway, Denmark, Sweden) are all high trust cultures, though not (I believe) just quite as high as Holland or Japan (or perhaps it is the length of track record that matters - as Holland and Japan have been recognized as high social capital countries for as much as 300+ years). Anyway, why is Agile adoption in the Nordic region higher. Is it because businesses in Finland, Sweden, Norway and Denmark are more open to change? more open to ouside ideas? more open to influences? and generally more adaptable in their outlook to process and business methods? [I'm asking the question. The Scandanavians and Finns reading this can tell me if they agree.] As for Britain, it's a pretty liberal culture despite its reputation. It isn't a particularly high trust culture but neither is it a low trust culture.

Meanwhile, the low rate of adoption in southern Europe and Latin countries does seem to be predicted by a lack of social capital in society and/or a conservative approach to business.

What I'm wondering now is whether Agile can become established in low social capital, conservative cultures and it simply takes time, or whether it simply will never be adopted. This would beg the question, will the economies of these countries suffer, as they fail to adapt to change. Will they economically suffer a similar fait to that of the Greenland Norse? As the climate changes will they fail to adapt and instead of being eliminated, simply become 2nd or 3rd rate, with greatly reduced relative economic performance significant drop in GDP per capita ranking compared with other countries, as the 21st Century unfolds?

It will be interesting to watch.

References
Trust by Francis Fukuyama
Collapse by Jared Diamond

Related Articles
Trust is the Essence of Agile, June 25th 2005
Clarke Ching, Carnival of Trust, June 2008
Pascal Van Cauwenberghe, David Anderson on Trust, December 15th, 2007
You are What You Read, December 29th, 2005
Naked Review, Feb 5th, 2006
Dennis van der Stelt, Trust is the Essence of Agile, July 5th, 2005
Technorati tag: Agile, Agile+Management, David+Anderson, Sociology, Trust, Social+Capital, Culture

Mike Bria has been following the trend that's emerging in the agile community to stop estimating user stories and adopt a pull based system, Is Estimating a Wasteful Practice? The idea that you don't estimate but focus on a low variability analysis technique such as the use of a user story template like the one Liz Keogh recently proposed as an adaptation of Tim McKinnon's original, is becoming more popular. It seems to work particularly well with pull system like Kanban or Naked Planning.

Mike wrote to me in email today. So I'd like to remind everyone of the blog posts that started all of this off - from March 2005. These posts were based on observations emerging from the XIT team at Microsoft. The case study was later published at the TOCICO conference that fall.

March 15th 2005 - Stop Estimating
March 17th 2005 - Agile Estimating

At the time, stopping estimating was considered just another heracy from the mad Scotsman, FDD guy! Three and a half years later, folks as respected as Joshua Kerievsky, J.B. Rainsberger, Arlo Belshee and Amit Rathore have all been publicly saying something very similar. Perhaps, I'm in danger of becoming mainstream ;-) [Update: Karl Scotland has blogged his thoughts on how this was handled at Yahoo! in the UK.]  Technorati tag: Agile+Management, Lean, Kanban, David+Anderson, InfoQ, Mike+Bria

My main stage speech from Agile 2008 is available on InfoQ. It a 90 minute video with the powerpoint slides simultaneously displayed. This talk was aimed at the Agile community and pulled no punches about what I see as the failings within the Agile Alliance. It has attracted a lot of attention - most of it positive. Here are some of the comments...

I've just watch your presentation at InfoQ (Agile2008 - Future Directions...) and have to say that your ideas about the agile movement are like an island of wisdom in a sea of resistance for changing and adaptation (mainly at the enterprise level). We really need some fresh ideas like yours.

Your topic on organizational maturity, and the role it plays on a group's preparedness for new methods of thinking and working really resonated with a few of us and we are looking to get closer to some of the latest thought on the topic. Also, your encouragement to look for ways to improve your effectiveness 10-fold seems simple, but immediately helped me recognize some of my own blinders. Raised very good points. Excellent ideas. Insightful.

Will be interesting to see cmmi & kanban evolve. ... real options seem very complementary

Thought provoking stuff

Refreshing honesty about prejudice in agile community and how this hurts adaption and growth to "cross the chasm?"

Great talk, David. There's no reason CMMI & Agile can't coexist. We need to open to new ideas, even if they're old.

This was the presentation I was looking for and hadn't found in the conference so far. Compliments!

But there are always the dissenters. They represented about 15% of feedback. Here is a sample...

Very, very boring session

This seassion was a sales pitch for "Kanban" and Agile + CMMI (Dave's agenda) I have serious doubts on many things Dave tries to sell, regarding how well he really understands them. I think he is 80% fluff

As for that last comment, I let my work do the talking. If I don't understand CMMI why was I invited to co-author the official SEI Technical Note on CMMI + Agile and why is my book one of only two that the SEI endorses and allows to be sold at their SEPG conference - the other one if Boehm and Turner's Balancing Agility with Discipline? Meanwhile, the body of work that Corey and I have published on Kanban can be judged on its own merits and through the adoption we're seeing around the world. Anyway,... If you haven't seen it and have 90 minutes of your precious time to spare, check out what I had to say about the Agile community and what I would like to see in its future. Technorati tag: Agile+Management, CMMI, Lean, Kanban, David+Anderson, Agile+2008, InfoQ, Software+Engineering, Project+Management