Tuesday, March 29, 2005

Paradigm Shifts

I’m taking a breather from tribalism and this may be my last post for a couple of weeks. I’ll be taking in the hanami season in Tokyo in the meantime. I won’t be going online. I won’t be taking my personal laptop with my blog content management system with me and I won’t have a broadband connection to temp me to the dark side. I will return mid-April having restored my spirit after celebrating the beauty and fragility of life and how quickly it passes.

But before then…

There has been a lot of discussion in my Yahoo! group about paradigms. I’ve been pushing the idea that Agile Management is about applying a new paradigm of thought to managing software engineering projects. One reader and fan of my book actually sent me a summary of what he called the “Anderson way” against the established wisdom. It had 21 lines on it. That’s a lot of paradigms to go breaking in a single blog post, so I thought I’d summarize what for me are the top five. These actually dropped off the top of my head in a meeting the other day when I was put on the spot to explain what it is I’m doing differently. So it’s like second nature for me now. All of these are fully compatible with the Declaration of Interdependence and represent why the DoI is bringing project management guidance up-to-date with more recent management science thinking.

• Flow through value chain, focus on throughput and effectiveness - as opposed to, cost and effort estimating and tracking, cost accounting, efficiency and earned value analysis
• Theory of variation (common and special cause) and buffering - as opposed to, deterministic scheduling and Gantt charts and deviation from plan
• Synthesis and systems thinking - as opposed to, Cartesian decomposition, (bottom up rather than top down)
• Process control and continuous improvement - as opposed to, conformance to plan and specification
• Empowerment and service - as opposed to, command and control

I see this as the embodiment of modern late 20th Century management thinking applied to software engineering. These five paradigms represent the work of many but mostly Drucker, Porter, Goldratt, Deming and Weinberg whilst traditional established software engineering management and process guidance seems to be rooted in the ideas and concepts of Fayol, Taylor, Gantt, Sloan and Brown, and Crosby.

When you see this list, it underscores the magnitude of what we’re all trying to achieve here. If you are out there trying to be an agile manager, it takes courage and bravery but stick with it. Attitudes will change given enough time. Unlearning is painful. It’s a chemical process in the brain. Giving up a paradigm (or “mindset” - think about that “mind” and “set” - wiring in the brain) is painful. It’s like the grief process. First there is denial. We’re seeing some of that with the DoI. Next there is anger. We’re seeing more of that with the DoI too. Then there is bargaining. We’re seeing that too. In fact, the whole project management world is seeing it, as techniques get more and more complicated to try and compensate for their inadequacies. Bargaining is about trying to keep a grip of the incumbent paradigm whilst modifying it to accommodate new demands. [Viz - the risk management section of the new PMBOK]. Then there is depression - the “Gee, I’m not with it” feeling. And the “Oh no, I need to learn something new and I will be a novice at it” feeling. Finally, there is acceptance. The brain has been rewired. The chemical pain is gone. “Yes, this paradigm is better than the one I left behind.” And the realization that a new paradigm is an opportunity - an opportunity to realize your potential - to get more out of life. On any given day, you may meet people in any one of these five states of mind, with respect to agile software development and management. That’s why it is tough to walk the agile path and to go the whole way - not just development practices - but to rewire the whole organization, how it’s managed, how it’s organized, how people communicate and report progress.

Thursday, March 24, 2005

5 Tribal Dimensions

Before I can talk meaningfully about harnessing tribal behavior in software engineering, I need to explain Immelman’s basic framework. So today’s post is merely passing on a few details. The thesis of Great Boss, Dead Boss is based on notion of the five tribal dimensions

1. Individuals are socially, emotionally and psychologically defined by their tribal membership
2. Individuals act to reinforce their security when under threat (Individual Security or IS)
3. Individuals act to reinforce their self-worth when not under threat (Individual Value or IV)
4. Tribes act to secure their self-preservation when under threat (Tribal Security or TS)
5. Tribes act to reinforce their self-worth when their security is not under threat (Tribal Value or TV)

Note that self-worth or individual value is measured purely in the tribal context. Individual value only increases if the fellow members of the tribe recognize the contribution and ascribe higher value to it. For example, praise from a non-tribal member would not count and would not increase self-worth. This is the critical premise of the first dimension - everything is tribal.

So here is a list of some of my tribal affiliations which may be weaker or stronger but they are all entities to which I feel an affiliation

• Anderson family
• Anderson clan
• Scotland (Scottish)
• Britain (British)
• Europe (European)
• Software Engineering Profession
• Manager
• Microsoftie
• Feature Driven Development
• Coad / Color Modelers
• UML Users
• Agile Community
• Ballard residents
• Seattle residents
• Western Washington Residents
• Mountain Bikers
• Skiers
• Strathclyde University Alumni
• IEE Members
• Kansas City Wizards
• MSF Champions
• TOC (Theory of Constraints) community
• Lean Design Community (CFD user)
• Real Ale drinkers
• Sprintpcs.com Mobile Portal (former leader)
• and on and on…

Have a think about it and make your own list? What threatens your security and how do you react? Then ask yourself, how do you increase your self worth? What makes you feel good or worse? If someone insults you, why does it hurt more or less depending on who it is? How strong are your tribes? What threatens their security? How do you feel about it when their security is threatened? How valuable is your tribe? What can be done to increase or decrease its value?

Wednesday, March 23, 2005

Tribalism Revisited

So I’ve been very patient. Last month I blogged my enthusiasm for Ray Immelman’s Great Boss, Dead Boss. I purposefully didn’t spoil it for any prospective readers by spilling the plot or the underlying theme. However, I’ve been getting mail and it is now time for a series of blogs with lessons learned from Ray. If you intend to order the book, or are reading it now and don’t want the plot spoiled then look away now and ignore my next 3 or four postings, come back in week or so and squint at the top of the screen, don’t look down .

Last year, I wrote a treatise on my discomfort and dissatisfaction with tribalism in the agile community. My feelings were based on the assumption that we are all highly educated and articulate and should be able to put our tribal past behind us and act objectively for the greater good. Well I was wrong. So it’s time to eat humble pie. Ray Immelman takes a whole different view on tribalism. He basically believes that it is a force of nature. We are genetically wired to behave in tribes. This genetic wiring is pre-human. It can be observed in our close genetic cousins such as chimpanzees. Hence, it is so old as to be impossible to undo through training and education. Immelman argues that denying our tribal wiring leads to dysfunction. He takes the view that to improve productivity, we must harness the tribal force in nature and use it to our benefit. [Hint: functional orgs are not tribes]

If you want to understand why Extreme Programming has been so successful and why people are so passionate about it, then you need to understand Immelman’s 5 tribal dimensions and his 23 tribal attributes. I’ll be writing more on this tomorrow. Meanwhile, we can use Immelman’s primary approach to understand what might be wrong with the agile community as a whole. When the tribes are warring, the way to unify them is not to appeal to their intellect (as I did) but to create a super-tribe to which they can all affiliate. A super-tribe which is stronger than the local tribe. A good example of this would be the United Kingdom. Where people like me feel Scottish and would identify with the Scottish tribe - an affiliation underscored with a broad brogue accent, a penchant for wearing a plaid skirt to formal dinners, and a deeply wired need to eat Haggis around the birthday of Robert Burns on January 25th - most of us Scots identify with being British and being part of the British super-tribe. It is this super-tribal affiliation which holds the United Kingdom together. Compare and contrast with the breakup of Eastern Europe into many small nations in recent years.

Hence, how do you get the agile community to speak with one voice? to work together optimally to change software development for the better, for ever? You create a strong “agile” super-tribe. So far the Agile Alliance has failed to achieve that. It’s membership stagnated at around 1000 people. Until the Agile Alliance can deliver on most of Ray Immelman’s 23 attributes and 5 dimensions, I fear it is inevitable that it will remain a loose affiliation of rival tribes. [Hint: To pick the 22nd attribute from the book - a strong tribe has a leader dedicated to the tribe’s success. (a selfless leader who puts the tribe first before his/her own interests). This would be a good place to start. Can you even name the leader of the Agile Alliance? - I’d have to go look it up.]

As we begin to build the new project management organization behind the Declaration of Interdependence, I’ll be very aware of the lessons from Great Boss, Dead Boss. I’m confident we can build a strong tribe of new paradigm project management professionals.

Tuesday, March 22, 2005

More thoughts from the Lean conference

Some more little notes I took on day one of the Lean conference.

Bart Huthwaite, Institute for Lean Design

Put value in, don’t just take waste out - too many Lean practitioners get obsessed with waste and forget about value. In addition, waste prevention is the purpose of good design - sounds like a Pokayoke tactic to me. [I recall talking about Pokayoke in a similar fashion at least twice before most specifically in Why is Agile not Lean].

The 8 value brothers [Ilities] - performance, affordability, deliverability, usability, maintainability, durability, image(ability), profitability, produceability, marketability

The Evil Ings [which put good Lean Design at risk] - complexity, precision, variability, sensitivity, immaturity, danger, high skill

Always use iterative design cycles (small batch sizes and batch transfers). Huthwaite doesn’t think iterations are about risk management either. Iterate because there are 3 forces of uncertainty - marketplace, technology, competition

People is where the greatest opportunity for improved productivity lies

Innovation must be systematically applied. Must have measurement. Tope 3 are usually, cost, schedule and quality but it is important to also measure value. [By innovation, he means process innovation or kaizen or continuous improvement]

Use measurements to understand and always baseline first to show the improvement

Yaruz Goktas, Motorola University

Change agents must have strong technical skills but must also have leadership. [When you think about this it is so true.]

David Rowe / Steve Unvari - Institute for Lean Design

Understand the “cadence” of a business - it is different for every domain. No one iteration size fits all.

TRIZ method teaches - your problem is not unique, it is merely a variant of someone else’s problem. [This should be printed as a large poster and hung over the cubes of every software engineering department]

Soni Meckem, Intuit

Key values of change

• Be decisive - stick to vision (strong leadership)
• Shared vision
• Over-communicate, over-communicate and over-communicate
• Openness
• Patience
• Surround yourself with the right team [As Jim Collins said, get the right people on the bus and put them in the right seats]

Tollgate process at Intuit asks a specific question at the end of each “phase”. The team focuses on providing the governance information that the leadership team needs to make appropriate decisions. They are not focused on artifact delivery or data. [I was particularly pleased with this news, as it is precisely the governance model we’re rolling out in MSF v4.0. So it’s wonderful to hear that a company like Intuit is already doing this.]

SDLC built from the ground up through a continuous improvement mechanism not simply an enacted prescription.

Each team is encouraged to self-assess their improvement achievements with respect to their “from behavior” and their “to behavior”. Teams always more self-critical than management were of them. Teams always thought they could do better and were eager to improve.

[I didn’t take notes on the second day as I was focused on my own presentation. However, highlights included a case study from Hewlett-Packard’s printer people who presented data which correlated with mine that small batch size, correlates to short lead time, which correlates to better quality. Very refreshing to hear. If we keep this up, correlation of results based on a sound underlying theory, then we might be able to call this world of software engineering a profession someday soon Heck, maybe even a science. Geesh! No more herding cats - what will all the cat shepherds do? Take up gardening I suppose.]

Monday, March 21, 2005

A TOC Eye from the Lean Guy

I’m at Lean Design and Development in Chicago this week. The standouts from day one were Bart Huthwaite from the Institute of Lean Design who kindly gave every attendee a copy of his book The Lean Design Solution - funny how you can do that when you self-publish and Don Reinertsen who chaired the conference. In his keynote, he emphasized again and again that the most important thing was to recognize the bottleneck resource in the value stream and insure that it had excess capacity. He called it basic queuing theory but I had to smile and wonder whether he’s gotten the TOC religion.