« June 2007 | Main | August 2007 »

July 31, 2007

"The Brain that Changes Itself" - Book Review

It has been a long time since I read a book in a single day. Yesterday I started and finished reading "The Brain that Changes Itself" by Norman Doidge, MD. As an educator, father and individual interested in self improvement, I was absolutely astounded by most of what I read. As an agile methods coach, I discovered some important, directly applicable ideas. Read on for a review of this book.

Myths of the Brain

You have probably heard or read somewhere that different parts of the brain control different parts of our body. Wrong.

You have probably heard that after a serious stroke, a person is crippled for life. Wrong.

You have probably heard that mental decline in old age is inevitable. Wrong.

"The Brain that Changes Itself" provides specific compelling evidence to show that these and other beliefs about the brain are dead wrong. Our brains are remarkably flexible, malleable... plastic. This basic point of the book is shown through a multitude of compelling examples. There is the story of the woman born with half a brain who is able to function almost completely normally. There is the story of the surgeon who had a stroke that paralyzed him on one side... only to have total and complete functionality restored to that side. All of these stories are backed up with rigorous scientific investigation and a complete set of notes.

About the Book

The book itself is written in a compelling fashion. The style of writing is light and accessible, the stories are well-told, and the scientific details are present yet unobtrusive. Some of the stories are deeply moving.

On the other hand, some of the material is a bit stretched. There is a chapter on talk therapy which is over-long. There is a chapter describing some deviant behavior which children should not be exposed to and which even sensitive people would probably avoid to their benefit (Chapter 4).

The books is pure text... and it suffers from the lack of pictures or diagrams. There are numerous places where a diagram of the physical structure of the brain, or a photo of a miraculous device would really make for a stronger presentation. For example, there are numerous discussions about how our physical body is "mapped" to areas of the brain. I have seen diagrams of this mapping in other texts and they would help make the idea much more concrete.

The book itself is a good-quality hardcover. It consists of 427 pages including eleven chapters, and two appendices. The table of contents can be found below for your reference.

Agile Brains - Agile Teams

The books is full of stories that bring fresh optimism to my work as an agile coach. Often I encounter individuals or organizations that don't seem to "get agile". This book provides some interesting guidance on how to overcome these mental blocks and has resulted for me in some insights.

The first insight is just practice. Actually doing agile is probably the best way to learn it and "get it". The trick here is to follow an exact and complete set of rules until they are perfected and only after that try variations. By perfecting the rules, we allow our brains to demonstrate that we have truly internalized (or mapped) agile methods.

The second insight is also practice... but related to time and frequency. I have long believed that shorter iterations are a more effective way of learning agile methods. Shorter iterations allow for more repetition of the basic rules and structures of agile methods, which allows for more effective internalizing of agile practices. Under the right conditions, brain maps change quickly (minutes), but in order to "stick", the changes have to be reinforced over the course of months.

The third insight is the importance of coaching itself. In order to change brains, it is necessary to get it right. The most reliable way to get it right is to have a coach who can help a team by demonstrating, guiding and sometimes correcting.

The fourth insight is the importance of practice when I am delivering training (rather than when I am coaching a team). My courses would be much better off if they were simply packed with a mini project that was executed over multiple extremely short iterations.

Recommendation: MUST READ!
Caution: not for children or sensitive types.

The Brain That Changes Itself: Stories of Personal Triumph from the Frontiers of Brain Science (James H. Silberman Books)

Posted by Mishkin Berteig at 11:11 AM | |

July 25, 2007

Time is Not Negotiable

The Project Management Institute refers to three variables that can be negotiated or constrained for a given project: scope, resources and schedule. Schedule is an interesting "variable" in that we have no choice about how time flows. We can control how much scope to ask for, we can control how much money to put towards the work, but we cannot actually "buy" more time than, say, our competitors. This has important implications which deeply challenge the PMI's PMBoK model of project management.

In a related article "Quality is Not Negotiable" I wrote about the strategic important of maintaining a high level of quality, and that allowing defects into your work is like taking on a debt with an unknown interest rate. With time, the problem is a little different.

The idea of sunk costs, also know as "don't throw good money after bad" is difficult for most people at a psychological level. We often feel like making just a little more investment of time, work or cash will turn an ailing effort around. Unfortunately, a traditional waterfall or phased-based approach to project work increases the psychological pressure to continue working, even when the project is "bad".

We know from the recent Chaos report statistics that two thirds of all IT projects are still either failing or challenged. We know that the bigger the project, the more likely it is to fail. We know that in other industries such as construction and economic development projects also have low success rates. How is it that we put all this money and time into these projects without knowing earlier if there are problems?

The problem is, of course, time. We can't predict the future. The farther out we need to see, the more uncertain the view. Not only that, but we can't "go back" to correct mistakes. We can only correct past mistakes by changing our future behavior... by using up more time.

One organization I worked with wanted to do a small web-based project. They had been "thinking" about this project for three years. At various times they had done requirements gathering and analysis with various stakeholders... and then failed to execute on the project. Finally they got around to starting the project. Using an agile approach, the first release of the project was completed in about eight weeks. How does this relate to time?

Well, first off, the project success was measured only in terms of the eight weeks of labor, not the time value of the sunk costs over the past three years. Now of course, the reasoning behind not including sunk costs is exactly because they are non-recoverable. Unfortunately, that doesn't give a very good picture of the investment made in the project. The fact that the costs are non-recoverable is not because of money, scope or quality (the other project variables) but because time is not negotiable: you can't get it back, you can't get more of it, you can't store it up, and you can't transfer it to other people. Sunk costs are really better thought of as sunk time.

A project is a temporary and one-time endeavor undertaken to create a unique product or service, which brings about beneficial change or added value. [Wikipedia]

This helps to explain why large projects have such low success rates. The larger a project, the larger the sunk time. It's hard to re-start projects, and the larger they are the harder they are to re-start. And yet, the proper approach to sunk costs (time) is to ignore what has gone past and treat your work as if you were starting from scratch. A project approach specifically does not allow you to do this. Hence the fiction of "earned value" (which is a whole other topic).

Only an agile or operational approach allows for low sunk costs. By doing work in extremely small pieces, each of which actually delivers value, an agile approach is best suited for the reality that time is not negotiable. Agile methods acknowledge that the best way to avoid sunk time is to not do much work until you deliver results. As well, since we can't go back to change our mistakes, agile methods allow us to check our work frequently and learn as we go.

In what other ways is time a different sort of variable than scope or cost? In what other ways does an agile approach take this into account?

Posted by Mishkin Berteig at 10:05 AM | |

July 23, 2007

Designing Truly Collaborative Spaces

While it may look like Agile teams all work in big empty “common rooms", the truth is that people need more than that. Elements like light, air, traffic flow, noise, refreshments and comfort are not negligible: high productivity teams still consist of people, not robots, and these hard working people can be enabled or discouraged by the spaces in which they work.

While it may look like Agile teams all work in “common rooms", the truth is that people need more than this. We forget that the classic XP teamroom layout was called “CAVES and commons” and it explicitly recommended that people have access to some personal space (caves), as well as the common space. After so many years of using professionally designed work spaces, teams sometimes “throw the baby out with the bathwater” when they start over from scratch with their own designs. Elements like light, air, traffic flow, noise, refreshments and comfort are not negligible: high productivity teams still consist of people, not robots, and these hard working people can be enabled or discouraged by the spaces in which they work.

Today I published an article on this topic, addressing a common issue with new teams: what should our collaborative space look like? The article gathers the wisdom of dozens of teams, as collected by experienced Agile coaches Joseph Little, Scott Ambler and Mishkin Berteig. The article suggests looking at the status quo for clues as to what a team needs, as well as imagining what tools their future collaborative process will use: projection, flip chart, continuous integration server, whiteboards, etc. The article looks at how much and what kind of space is needed, and reminds designers of facilities that teams need to have in or near their space.

You can read the entire article on InfoQ.com'a Agile community queue.

Posted by Deborah Hartmann at 10:23 AM | |

July 19, 2007

Agile is Not Communism

Last week I taught an introductory course on Agile Work. Normally this is pretty easy stuff. However, I was teaching this course in Bucharest, Romania (cool), and I have come across a substantial, strong and vigorous objection to agile (also cool, but challenging too). Several people in my class are asserting that agile is just like communism and since communism failed, agile is not likely to succeed either. I'm looking for help on this!

I have Googled "agile communism" and come up with some interesting reading:

Does Scrum/XP Violate the Agile Manifesto?
The Agile Method and Other Fairy Tales: QED

I have also done some quick research on communism to check that I understand the comparison and objection. Here is a wiktionary definition of communism:

1. A term used to refer to a number of political philosophies or ideologies which share the belief in the virtue of holding the production resources collectively. 2. A society organized in line with the communist theories, the ultimate aim of which is the abolition of the state and the creation of a classless, stateless society whose members produce according to their abilities and take what they need.

So let's start with that definition.

Holding Production Resources Collectively
Also called: common ownership of the means of production

I suppose there are a few ways to look at this. In an agile environment which encourages (for example) collective code ownership, it might seem like holding the production resources collectively. However, the code is actually the result of production, rather than the Means of Production. This distinction is not trivial. The means of production for a team in an agile environment still include both the tools and the raw materials upon which those tools exercise. In software development (and in most creative work nowadays), the tools are computers and software and other electronic gadgets such as video cameras, telecomm systems, etc. The raw materials are typically intellectual constructs such as images, sounds, ideas, processes (and of course their legal counterparts such as trademarks, copyrights, and patents). Agile methods do not require the team of workers to own these means, nor do agile methods forbid workers from owning these means. In fact, There is one important way in which agile methods are decidedly not communist: every individual owns their own creativity, experience, and knowledge and is only asked to share willingly (and usually in exchange for pay such as salary, stock options or outright corporate ownership). I believe this passage clarifies things nicely:

Marxists define economic systems in terms of how the means of production are used, and which social class controls them. Thus, in capitalism, the means of production are controlled by the bourgeoisie, (the "capitalists" - the owners of capital), while in socialism they are controlled by the people's elected representatives and in communism they are controlled collectively by the people themselves. [Means of Production]

Agile methods, if anything, tend towards capitalism in this regard. (Although a whole other question could be asked about just how much control the owners of a corporation really have given delegated authority through the board of directors to the chief executive staff _and_ the abrogated authority through mutual funds, pension funds, holding companies, and trusts _and_ the limitations on that control through the blunt instrument of voting shares _and_ the influences on that control through the control of information by financial analysts and the media...)

Ultimate Aim of The Creation of a Classless, Stateless Society

Well, this certainly isn't the aim of agile methods that I am aware of. The aims of agile methods as I understand them includes:

Again, I can understand why there might be some confusion here. Agile methods promote these three aims by doing something that looks just a little like a classless organizational structure. Typically, agile (and lean) environments start to have a higher manager to staff ratio (fewer managers), encourage self-organizing, cross-functional teams, and emphasize team goal setting, commitment and accountability. This might seem classless (and stateless/managementless) until one examines what is not said: Agile does not claim that every team member is exactly equal, it does not require that every team member do exactly the same thing, it does not require that every team member give up _all_ their individual preferences (although certainly it would be hard for someone who didn't like talking to other people to be part of an agile team... so I guess some individual preferences won't work in an agile team), it does not encourage every team member to do exactly the same amount of work regardless of if you are measuring effort or output.

Now admittedly, when I am presenting examples of self-organizing teams, I do sometimes use examples that come close to classless stateless teams... but that's just to show that this is a possibility and allowable in an agile environment, not that it is the only way.

Those practices in agile methods that do seem like classlessness and statelessness are not aims... they are means. A self-organizing, self-managing team, is means to an end. It is not an aim in itself. Why does this matter? For the simple reason that it is always bad to confuse means and ends. The end cannot justify the means (classlessness and statelessness imposed by revolution)... and nor can the means justify the ends (classlessness and statelessness that results in apathy, boredom and low productivity). So the fact that self-organization is a means is a way for us to decide if it is worthwhile. The evidence for self-organizing teams in a business context is strong (lots of links and articles and books on this blog as well as others). Most team members enjoy being self-directed in a way that is collaborative with other professionals. So both the ends are good - productivity - and the means are good - happy people.

Members Produce According to Their Abilities and Take What They Need

To me, "produce according to their abilities" sounds a lot like a tautology. Certainly, team members can produce no more than their abilities! From an agile perspective, this isn't even what we are interested in... we are interested in the multiplicative effect of teams of people working together effectively so that the result of the work is greater than the sum of the individual abilities. There is now substantial evidence that this is not just possible, but a likely outcome of group work (see Research on Group Effectiveness vs Individuals among many others). My favorite phrase for this is "Unity in Diversity" which describes a group of people who have united around a common goal, but with each individual having talents, experiences, knowledge, patterns of behavior, and insights that are all different from each other.

The second part of the phrase "take what they need" is another piece of this pie that has absolutely no relationship to agile methods. Again, there is evidence that this is specifically not supported. Lean methods encourage compensation that is based on a number of things including: contribution to results in one's sphere of influence (rather than the more limited sphere of responsibility) and the number of skills you have mastered and use to contribute to the work.

Disconnecting reward from results is an obvious problem. While people do have altruistic feelings, we also are clearly motivated by praise

Some Similarities

One of the attendees of the course, a woman by the name of Christina, provided me with some notes based on her understanding of Agile and Communism and she listed these similarities:

And What about Reality?

Well, I haven't lived in a communist environment so I admit that my ability to talk intelligently about this is not what I would like it to be. I am interested in people out there who might be able to help me with this.

Here are some questions for people who have actually experienced communism:

Can anyone out there help please?

Posted by Mishkin Berteig at 06:13 PM | |