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

“To deal with complex projects there is an increased need for agile and flexible project management… In future, ‘people’ and leadership skills will be viewed as more important than technical skills.” Statements like these hardly seem surprising to regular readers... Mike Griffiths

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

Next week I will be teaching two one-day agile workshops and an executive summary session in Costa Rica. The courses are organized by Invenio University Research and Education and will be taking place in the capital, San Jose. I will... Mike Griffiths

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

The URL for the Alistair.Cockburn.us RSS feed has changed to http://alistair.cockburn.us/Rss/Rdf. Please update your links. Thank you.

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

To be truly effective you need ability and passion. Some people use the formula: Performance = Ability * Passion However, you also need time to dedicate to the work at hand; and so Availability factors in also. In the volunteer... Mike Griffiths

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

I have just returned from a great trip to Alaska. It was made possible by a request to speak at the PMI Alaska chapter and deliver two one-day training courses. Alaska is one of those places I have always wanted... Mike Griffiths

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