Yesterday I had a bit of an argument on Twitter about differences between Scrum and Kanban. Personally I don't care which is better than the other, because I believe that all models are wrong, but some are useful. And both Scrum and Kanban can be useful, given a certain context.

In yesterday's keynote speech at the Scrum Gathering in Orlando Jeff Sutherland said he had seen teams that were "doing Scrum" while they didn't even have a backlog. And there are reports of "Scrum teams" not practicing daily standup meetings, and teams not delivering a new product release every week.

These are not Scrum teams. They are ScrumBut teams. They do Scrum, *but* without some of the key ingredients.

Unfortunately, some people arguing against Scrum include these ScrumBut teams in their evaluations of the "high failure rate" of Scrum. They love quoting that "at least 75 percent of Scrum implementations fail." And I think "Yes of course, 75% fails when that includes the teams that don't understand what they're doing."

I believe that right now Kanban doesn't suffer from this problem. Kanban doesn't have a high failure rate because Kanban is still at the start of its adoption curve. Only very smart people like David Anderson and Karl Scotland are practicing it. And they know how to do it right!

But just wait a few years and see. When idiots like me get their hands on Kanban, we will start implementing KanbanButs, but we'll be calling it Kanban. We will have absolutely no idea what we're doing, because value stream mapping is not as simple as story point estimation. And we will introduce "Kanban teams" without limited WIP, or "Kanban teams" without a vizualized workflow.

Then the world will see a 75% failure rate of "Kanban" implementations.

And then there will be a great new software development method called Bonkiborki (which is the Mongolean word for 42). And I will have invented it. And it will have a much higher success rate than Scrum and Kanban, because I will be the only one who knows how to do it right.

(image by Misserion)

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo';
Latest, greatest and favoritest posts:
Yes, Good Managers Are Manipulators
Reduce Your Fear, Increase Your Status
Planning for Feature-Complete Deadlines

Here it is: my latest presentation. Five days of work, 38 drawings, 14 photos, 81 slides, and plenty of texts, to be delivered for the first time at the Scrum Gathering in Orlando next week.

The Dolt's Guide To Self-OrganizationView more presentations from Jurgen Appelo.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo';
Latest, greatest and favoritest posts:
Self-Organization vs. Emergence
Self-Organization vs. Evolution
Self-Organization vs. Anarchy

I know you're busy. We all are.

But no matter how busy you are, you still find the time to brush your teeth.

No matter how full your agenda, you still have room to socialize with your peers.

No matter how many stories on your backlog, you still make time for your unit tests.

And as a manager?

No matter how many meetings and presentations, you still have time to write a blog post.

Yes, you may trim the activity to its bare essentials. But you don't skip it.

So here it is.

(image by bark)

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo';
Latest, greatest and favoritest posts:
Yes, Good Managers Are Manipulators
Reduce Your Fear, Increase Your Status
Planning for Feature-Complete Deadlines

Together with several other people I have been busy preparing a re-launch of Management 3.0. It is a site for (and by) agile managers and agile team leaders.

Like my own blog, this new site will have absolutely no information about technical practices or cool technologies. Instead, it will be about leading technical people, with blog posts about motivation, hiring, competence, knowledge, improvement, and fluffy bunnies.

And unlike my own blog the Management 3.0 site is open for submissions by everybody! Yes, it is the perfect place to do a guest post and show off your writing skills! If you do well, you can draw billions of readers to your own blog or book. I think.

The site already has guest posts in queue from Israel Gat and Pawel Brodzinski, and I have blackmailed at least a dozen other well-known authors to deliver a contribution in the next few weeks and months. So don't be afraid and submit your own blog post at Management 3.0. Have a look at the guidelines if you need a little help with it.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo';
Latest, greatest and favoritest posts:
Make a “Social Contract” with Your Team
Communicate Your Goals!
People Motivation: Target Intrinsic Desires

I was writing this text right after Christmas, one of the most successful examples of mass delusion of all time. It is a time of the year I always look forward to, and not only because of the food. I admit that I enjoy participating in the silly behavior of putting up a Christmas tree, lighting candles, buying presents, watching movies, and singing Christmas songs, as much as anybody else.

Ideas, concepts, beliefs, theories, ideologies, fads, and fashions are often called memes. People copy these units of information from each other through mimicry, interaction, correlation, teaching, and learning. Santa Clause is a meme; the Christmas tree is a meme; putting presents in stockings (or in shoes as we do here in Holland) is a meme; Rudolf the Red-Nosed Reindeer is a meme; the birth of Jesus Christ is a meme; and angels and elves are all memes.

It is the same with rules, procedures, and practices for software development. They are ideas, concepts and beliefs that people copy from each other through mimicry, interaction, and learning. Stand-up meetings are a meme; pair programming is a meme; refactoring is a meme; iterative development is a meme; and user stories are a meme. Memetics is the study of evolutionary models of information transfer, often in a cultural context.

We refer to a collection of interdependent memes as a memeplex. Christmas is a typical memeplex. And so is agile software development. Universal Darwinism shows us that memes group together in a memeplex because they will copy themselves more successfully when they are “teamed up.” (Genes do the same thing, in which case they are called gene complexes.) Christmas is a successful memeplex in that all the different memes, despite having many different origins, now reinforce each other, rendering them virtually indestructible. Rudolph the Red-Nosed Reindeer probably wouldn’t have survived on his own. But the meme has, quite literally, teamed up with Santa Claus, and now seems to have reached an immortal status.

The Christmas memeplex

Likewise, the memes in agile software development also tend to reinforce each other. Refactoring suggests test-driven development, weekly iterations suggest working with user stories, and stand-up meetings work better with a task board. Most of the agile practices already existed long before agile software development, an argument often heard from agile skeptics. But that’s beside the point. The important thing is that the rise of the Agile memeplex has catalyzed a copying frenzy of the many agile practices, to a level that they never would have reached on their own.

The fact that an agile memeplex is much stronger than the individual memes is something I have been able to experience myself. My early attempts at introducing timeboxes and high-level requirements were total failures, because I selected individual practices that (I thought) would be beneficial for our organization. They failed to catch on, and not because of lack of effort on my part. It was like trying to get everyone to sing to the tune of Rudolph the Red-Nosed Reindeer, in the summer. It just didn’t work. The memes by themselves weren’t strong enough. However, at some point I realized that it was better just to try Scrum. By the book. Scrum was more specific, more extensive, and far more successful than any of my own attempts at process improvement. Scrum is a memeplex. The memes reinforce and help each other to be copied around in the minds of the people. This makes it easier to implement Scrum-by-the-book than it is to implement only timeboxes and high-level requirements.

There are a few interesting observations we can make when looking at agile practices as memes:

1. It can be easier to get people to adopt multiple ideas, concepts or practices simultaneously, then it is to have them adopt just one. (For example: teaching them to apply Extreme Programming instead of only unit testing);
2. In a memeplex not all ideas, concepts and practices need to be beneficial. In fact, some of them can be harmful. But because they are all part of the same memeplex, the bad ideas help the good ideas to be copied around as well, which neutralizes the bad effects. (An example which might be on dangerous ground: I have seen no conclusive evidence of the value of collective code ownership, but this practice seems to reinforce the other agile practices, so it won’t hurt copying it along as well);
3. Removal of individual memes from the memeplex may weaken, or even destroy, the strength of the memeplex. (Example: removal of collective code ownership might lead to an agile adoption breaking down completely);
4. There may exist multiple competing memeplexes that reinforce and need each other because their competition draws attention away from alternatives. (Example: competition between XP, Scrum, and Kanban within the Agile world draws attention to the agile brands in general);
5. Memes may have different origins, and can even be exchanged and shared across multiple memeplexes. (Example: user stories started as a meme within XP, but are now firmly locked into the Scrum paradigm as well).

I think it is useful to think of agile brands and methodologies as memeplexes. Their sole purpose and value is to catalyze the copying of the individual agile practices. Anyone claiming that Agile didn’t bring much to the software development profession that wasn’t already there, completely misses the point from an evolutionary perspective. The moment when self-replicating molecules started teaming up in gene complexes, to help each other being copied around, was pivotal for evolutionary biology. Similarly, from the perspective of cultural anthropology there wouldn’t have been cultures, religions, and sciences, when humans had not invented the concept of grouping ideas and copying them under one name.

I therefore believe that we will look back at the rise of the agile brands, being nothing more and nothing less than named collections of good practices, as a crucial step in the evolution of software development.

(picture by 1Happysnapper)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo';
Latest, greatest and favoritest posts:
Discipline * Skill = Craftsmanship
If You Want Something Done, Practice Your Patience
Managing Risk vs. Managing Yourself

It struck me several times that the flow of traffic at the Hofplein in Rotterdam, one of the busiest roundabouts in my city, is better when the traffic lights are turned off. Despite the anarchy that such a situation brings to the streets, people get to the other side of the roundabout faster than when the lights are operational. And this not only applies to motorists but to pedestrians and cyclists as well.

In a Dutch article titled “Traffic is safer without rules” traffic expert Hans Monderman explained that the flow of traffic at an intersection can increase, while at the same time casualty rates decrease, when all traffic lights and road signs are removed. The reason is that, in a situation without rules or guidance, people feel compelled to take responsibility and to judge for themselves how to reach the other side safely and in one piece.

The cause of this paradox can be found in risk perception and false security. Remove the green traffic light (false security) and car drivers will not blindly go full throttle on the assumption that they have priority over everybody else. Wipe away the crosswalk and pedestrians will better watch out for any dangerous vehicles (increased risk perception). Monderman claimed that the number of accidents diminished, and traffic throughput increased, in all situations where this concept was introduced. The idea is called shared space, which entails that all participants in traffic are equal, and that they all have to watch out for each other. Nobody can assume priority over others.

I dare claim that the shared space principle also applies to software development practices. Rules on how code should be developed, how it should be tested, and how new versions are to be built and deployed, may not automatically lead to higher quality products. On the contrary, a documented test procedure that doesn’t take specific project characteristics into account can lead to false security among team members. And an official requirements specification process that is deliberately ignored by team members may actually help them to increase their risk perception, seeing problems more clearly because they know they have to watch out.

In most projects, existing rules have to be treated not as laws but as rules of thumb. They point people in a direction that is often a smart solution to a problem, but not always. Sometimes it is necessary to abolish rules precisely to prevent people from blindly following them. In some of the most successful projects I participated in, we ignored rules and made better decisions on the spot. By going around road blocks and ignoring traffic lights we were able to reach the other side of our timeboxes timely and safely.

I am usually a bit reserved when an unpleasant incident has occurred in a project and someone is calling out that new rules are necessary to prevent similar problems in the future. When I would do as they asked, I would be no different than the average bureaucrat planting new road signs at intersections for every potential danger that somebody has encountered earlier. Some call this approach the Precautionary Principle and it is an official policy in many governments, including the European Union. Basically it says that, when something might go wrong someday, simply make a new law to prevent it from happening, just in case. And I really don’t like that approach.

Some methodologies and frameworks, like the CMMI, seem to be based on the Precautionary Principle. They suggest adding process descriptions for all kinds of potential problems. Unfortunately, I never saw them suggesting that some processes may have to be removed to make things run better. This is quite understandable, of course: It is unlikely that you will hear politicians and traffic controllers admit that their rulemaking efforts are often in vain, and sometimes even counterproductive.

Fortunately, software development experts seem to be smarter nowadays. They are increasingly aware that no single methodology is appropriate. Ivar Jacobson, one of the founding fathers of the Unified Process, has admitted the same in a three-part article titled “Enough of Processes: Let’s do Practices”. No one should rely on rules devised by others who know nothing of the situation that you find yourself faced with in your own project. In general, you achieve the best results if you create your own rules on the spot, appropriate to the situation of the day. Three researchers who have studied agile software methods came to the same conclusion, claiming that the best way to implement agile processes is to do it your own way.

I have participated in Dutch traffic for almost 20 years, and I’ve never been involved in an accident with other people. That’s because I constantly watch all vehicles, cyclists and pedestrians around me, preferring my own judgment over what the traffic signals are saying. My spouse, on the other hand, failed his first driving test when he trusted a green traffic light and almost drove into a pedestrian who crossed the street while ignoring a red light. Since then he has learned to trust his own senses first, and the official rules second (if time permits).

(image by Ted Percival)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo';
Latest, greatest and favoritest posts:
Scientific Case for Bottom-Up Rulemaking
Managers Are Not Game Designers!
The Three Phases of Creativity

I’m sure you recognize this problem. You are in a hurry, and you skip the routine of checking whether you have all your belongings with you when you leave your house. Half an hour later you’re driving back to the house, snarling and cursing because you forgot your wallet, and now you’re even more in a hurry than you were before.

I believe discipline is one of the two crucial dimensions of craftsmanship. How would you rate a pilot who regularly forgets to check the engines? Or a surgeon who sometimes doesn’t take the time to wash his hands? Or an actor on stage who sometimes doesn’t know his lines? As a consumer, or a patient, would you accept the excuse “Sorry, I was in a hurry?”

The importance of discipline in any craft is evident. Gerald Weinberg wrote about the Boomerang Effect of people not following procedures: some part of quality assurance is skipped, which leads to an increased number of problems in a shipped product, which leads to an increased number of problems reported by customers, which leads to more emergency interruptions, which leads to bigger time pressure on the development team, which leads to more procedures being skipped. We all know from personal experience that, ultimately, skipping discipline makes you go slower, not faster.

In the same vein, Mary and Tom Poppendieck described that a software development team cannot go fast without building quality into their product. Skipping checklists and procedures only seems to make you go faster, at first. But quite soon, the lack of quality in your product will wear you down.

Weinberg described six maturity levels for following processes:

1. Oblivious: “We don’t even know that we’re performing a process.”
2. Variable: “We do whatever we feel like at the moment.”
3. Routine: “We follow our routines (except when we panic).”
4. Steering: “We choose among our routines by the results they produce.”
5. Anticipating: “We establish routines based on our past experience with them.”
6. Congruent: “Everyone is involved in improving everything all the time.”

Weinberg used these six levels to classify organizations, but I prefer to classify only individual people for specific activities. Whatever happens to an organization is an emergent result of the interaction between people, many of them having different levels of discipline for different activities. I am sometimes complimented for my discipline at book writing, which may be at level 5 (anticipating) or even level 6 (congruent). But at the same time, if you hear someone cursing and yelling, it could be me going back for my wallet, an activity that is apparently still at level 1 (oblivious). (Or it could be my spouse. Amazingly, while I was rewriting this paragraph, he returned to retrieve his wallet, after having left the house ten minutes earlier…)

A similar arrangement of six levels was introduced by Ross Pettit of ThoughtWorks, who named his levels Regressive, Neutral, Collaborative, Operating, Adaptive, and Innovating. The meaning of Pettit’s six levels is somewhat different, but, like Weinberg, he seems to be indicating levels of maturity in selecting and applying processes.

The second crucial part of craftsmanship is skill. A skilled software developer can still be undisciplined, while a disciplined developer is not necessarily skilled. Therefore it seems to me that a person’s skill level is another dimension in which we can rank maturity.

There are two similar approaches to indicate the skill level of craftsmen and craftswomen. The guild system, which stems from medieval Europe, lists three ranks for people practicing a particular craft: apprentice, journeyman, and master. This system is practically the same as the Japanese Shuhari variant which describes the three stages of practicing a martial art: Shu, Ha, and Ri. In both systems, people ranked at the first level are learning fundamental techniques; people ranked at the second level focus on exceptions and reflections; while no hard thinking is needed, and everything just comes naturally, for the people at the third level.

(In this figure you can see that I'm a better driver than a writer. I've been driving for 20 years, while I've only been writing for 2 years now. But my daily discipline in writing is better.)

When we draw the two dimensions of discipline and skill we have arrive at a useful diagram for craftsmanship. It nicely depicts that maturity can be measured in two directions. One can lose his skills through old age, physical injury, or technological advancements, and one can lose her discipline through demotivation or distractions. Craftsmanship requires both, and therefore managers need to take care of both dimensions.

(top image by jared)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo';
Latest, greatest and favoritest posts:
Protecting Fish and System Administrators
Reduce Your Fear, Increase Your Status
You're Only as Busy as You Want Yourself to Be

Last week Uncle Bob Martin wrote about seven “serious flaws” in Scrum. I usually agree with Bob, but not this time. Actually, I might even feel a bit sad about all the <method>-bashing I see happening in the Agile world, where all too often <method> = Scrum and the bashing comes from either the XP side or the Kanban side.

Here’s my take on the matter…

“Scrum has no technical practices”
The lack of technical practices in Scrum is a strength, not a flaw. It means Scrum can be (and has been) applied successfully not only in software development, but also in design, marketing, and several other creative domains. As far as I know Scrum has always been presented as a framework, meaning that it must be augmented with domain-specific practices. True, some software teams forget about the technical practices, and they are idiots! But is it a “flaw” of the script writer when the director forgets to use stunt doubles when filming the dangerous scenes? Or is that a failure of the craftsman who apparently doesn’t know how to do his job? If you call it a “flaw” that Scrum has no technical practices, then you can only conclude that Lean and Kanban are seriously flawed as well! Obviously this is a bit silly. To me this flawed reasoning seems like a bad case of tunnel vision. There’s more happening in the world than TDD, Continuous Integration, and Pair Programming. Really! (BTW, it is interesting to see praise on the Lean side for Bob's criticism of Scrum, while Lean and Kanban have no technical practices whatsoever! The few described in Lean books are simply copied from XP…)

“The Scrum Master arrogates project management powers”
Maybe, but it’s a risk worth taking. A much bigger problem I see with teams without a Scrum Master is that they are usually an undisciplined bunch of mandrills. XP requires and assumes that teams consist of self-disciplined, competent, and communicative people. Unfortunately, many software developers don’t fit this description. Scrum at least acknowledges that most teams need some help and assistance in getting their processes and communication in order. I find it particularly strange that people who call for craftsmanship on the technical side should point out the dangers of positioning a master on the process side! Honestly, I would rather run the risk of a Scrum Master taking up PM powers than a dev team completely ignoring their responsibilities. What is worse? (And yes, the sooner a team can do without a Scrum Master, the better. I don’t have one in my own team right now. For us there's no need.)

“Scrum provides insufficient guidance regarding the backlog”
See the first issue above. A backlog for graphic designers probably looks quite different from a backlog for developers. And marketers print their backlog horizontally and call it a road map. What’s wrong with keeping all the options open? Scrum is a framework, not a by-the-minute recipe!

“Scrum carries an anti-management undercurrent”
I don’t get it. How is that different from XP? Management has always been underrated in the Agile world. True, management has done badly before Agile. And we should be glad for the Agile movement and its self-organizing teams. But self-organization without governance is anarchy. This is not a flaw in Scrum, it is a flaw that began with the Agile Manifesto itself, which completely disregarded the role of management. And guess who co-wrote that? :-)

“Scrum doesn’t say anything about multiple teams”
True, and again: how is that different from XP, or any other agile methods? Allow me to quote John Gall here:

A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system. – The Systems Bible, John Gall

Scrum is a small system. That’s why it works. It is specifically designed not to cover technical practices, complicated backlogs, multi-team projects, etc. They tried that with RUP, and they failed. Because a complex system designed from scratch won’t work. A big working system has to start as a small working system. This is not a flaw. It is common sense. And now that we know that (small) Scrum can work, we can learn how to make it grow...

And that's what I had to say in defense of Scrum. I really hope that people would stop pissing on it. No agile method is perfect. But I think there’s a world of difference between imperfect and "flawed".

Please note that I am not a CSM, and will never be one. I like XP and Kanban just as much as I like Scrum, because I believe no single model or framework is enough when managing complex systems. Anyone who favors one method and pisses on another is just showing off his ignorance of complexity thinking.

That's it. I hope to have entertained or annoyed you.

I will be speaking at the Scrum Gathering in Orlando. Hope to see you there!

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo';
Latest, greatest and favoritest posts:
Management 3.0: The Era of Complexity
ScrumButs Are the Best Part of Scrum
The Complex Manifesto for Software Development

In his book Hidden Order: How Adaptation Builds Complexity computer scientist and psychologist John Holland describes a generic pattern for rulemaking in complex adaptive systems (like businesses and software projects).

Performance System
The first part of the pattern is what Holland calls a performance system. It consists of a potentially large number of stimulus-response rules, where the rules are meant to act upon messages received from the environment (or from other rules). The result of applying those rules is that a number of new messages are emitted, either to follow-up rules, or to the external environment.

Being a software developer my mind is filled with plenty of rules for building software. The input that I receive from the environment consists of the things my colleagues are doing (or the things they are only saying they’re doing), the code that I am working on myself, the requirements from the customer, the features and restrictions of the development environment, etc. The many messages from the environment are evaluated, in parallel, using hundreds if not thousands of rules in my mind, both consciously and unconsciously, which results in one or more new actions, like code to be written, changes to existing code, conversations with my colleagues, or discussions with the customer.

I know, this all sounds pretty obvious. But the key concept here is that the performance system consists of many potentially conflicting rules, where different rules are triggered under different circumstances, given different messages from the environment. It is as if the performance system is an ecosystem of rules, where rules are both competing and collaborating with each other, and the “fittest” rules are the ones contributing most effectively to the whole complex adaptive system.

Credit Assignment
The second part of the pattern is called credit assignment. Rules that appear to lead to improved performance of the entire system are credited, which increases their strength within the performance system. Rules that were triggered and subsequently failed to deliver beneficial effects, or even appeared to hurt the total system, will see their strength reduced. The strength of each rule determines the chance of being triggered the next time, for similar input messages.

Credit assignment assures that experience is built up in the system, by strengthening some rules and weakening others. The rules together form an internal model of what the world outside looks like and how the system needs to respond to it. And when the environment changes, strong rules will start failing and weak ones could succeed more often than before. This enables the performance system to adapt to new situations, and to continuously correct and tune its internal model.

Rule Discovery
The last part of the pattern deals with rule discovery: where do the agents in a complex system (or software developers in a project) get their rules from? Holland describes how new rules can be constructed from existing rules by recombination of building blocks. This is essentially how DNA works: by recombination of existing genes and their alleles.

Holland was one of the first to create evolutionary models for rule-based decision-making, which earned him a reputation as the father of genetic algorithms. He not only convincingly described how these performance systems are an interesting conceptual model for complex adaptive systems, but he also showed that they can be implemented easily to create evolutionary algorithms with powerful problem-solving capabilities.

Why am I writing all this?

For one reason only: to help people understand that rule-making is something that must happen bottom-up. And not top-down.

Science proves it.

(image by Syntopia)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo';
Latest, greatest and favoritest posts:
Management 3.0: The Era of Complexity
Self-Organization vs. Emergence
Self-Organization vs. Anarchy

I have told you how to define goals, rules and boundaries for the people in your organization, and hopefully your team is on a great and inspiring mission.

But what do your team members get in return?

Why should people subscribe to your vision? What’s in it for them? Only a salary?

Israel Gat described how he used the idea of a social contract to define the obligations that the manager feels he has towards his employees:

Team, my overarching organizational objective is to preserve our team and its institutional knowledge for our corporation and its customers for years to come. We will achieve this goal by enhancing our software engineering prowess to the level that the resultant benefits will outweigh the repercussions of the current financial crisis. […] Whether you will or will not be with the company in the future, I acknowledge your need to develop professionally as Agile practitioners and commit to invest in your education/training.

In this social contract Israel Gat described not only (part of) a mission, but also what he acknowledged to be his own responsibilities toward the team members. In this case it was investing in education to address their need to further develop themselves professionally.

Social contract theory is a philosophical concept describing how groups of people maintain social order by giving up some of their freedoms to an authority. It is an agreement by the governed on a set of rules by which they should be governed, and it usually applies to societies and their governments. But the idea translates quite well to organizations, even though the “governed” do not have the right to elect their “governors.” What is similar is that the contract lists the obligations of the authorities toward the people, and that everyone is automatically assumed to agree on the contract, or else they are free to leave. (Which, I am sad to add, can be a bit troublesome in the case of some countries.)

A social contract should address the basic necessities of people. In a society, they are not only things like food, shelter, and safety, but also freedom of speech, basic education, equality, and (if you’re fortunate enough to be born in a modern country) healthcare. In an organizational context we’re talking about similar things, like the freedom to voice your opinion, professional development, non-discrimination, and a little help when you’re not feeling well.

This brings us back to a topic I have frequently touched upon before, which is that management is all about people, and that it needs to acknowledge their basic intrinsic desires. A social contract is a simple but effective way of making this explicit for all involved.

(image by madmolecule)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo';
Latest, greatest and favoritest posts:
Protect People
Yes, Good Managers Are Manipulators
People Don't Listen

I am not a saint. There have been some awful quality problems in the products that I was directly or indirectly responsible for.

No, I was not responsible for accidentally sending that email to 1,000,000 people instead of just 10,000 registered users. And it was not me who messed up the home addresses of a few thousand on-line buyers so that their products could not be delivered. And I had nothing to do with the bug that allowed 9 out of 10 players in a lottery to win the main prize. But I will eagerly tell you about my own programming errors. If you show me yours, I’ll show you mine.

The problem with quality is that it is often simply assumed by everyone. This is exemplified by the well-known triangle of constraints, which lists all important constraints, except quality. Customers just assume they will get quality products, and managers assume that employees know how to build them. And, unfortunately, 80% of people actually believe that the quality of their work is above average. Obviously it isn’t.

Self-organization can solve many quality problems, as long as you put the right constraints in place. It is sometimes said that managers get what they measure. If you make it a point that products must be delivered to customers before their deadlines, then self-organizing teams will do exactly that. They will push (sometimes crappy) products out the door on the day of the deadline. If you make it a point that products have to be reliable, scalable, well-performing, and secure, self-organizing teams can build exactly that. They will deliver high-quality products many months after the customer gave up waiting for them and went elsewhere. And if you manage your constraints to have products delivered on time and of high quality, again you get exactly what you want. But the products will contain less than half of the features the customer originally asked for.

I prefer to depict these choices in my favorite adaptation of the iron triangle, where quality is added to turn the triangle into a square. Part of your job as a manager is to think hard about the kind of constraints you place on self-organizing teams. You not only get what you ask for. You also don’t get what you don’t ask for. Too often, managers forget to define clear constraints for quality in their products. And if you don’t define it, you are not going to get it.

(image by Nick J. Webb)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo';
Latest, greatest and favoritest posts:
Yes, Good Managers Are Manipulators
The Do-It-Yourself Team Values Kit
Where There's People, There's Problems

I work for a company with a big open office space, in the Van Nelle Factory in Rotterdam. About 100 people work in an office that was the first of its kind in Europe, when it was built in 1929. And 80 years later architecture lovers from all over the world still come to visit and admire it, taking pictures and making drawings. We sometimes wave at them.

A big open office space has many advantages, and some disadvantages. The main disadvantage is that it is a shared resource for all who work there. Climate, sound, and light are hard to manage in a space like that, and the optimal configuration for the whole is never optimal for all. But our office manager does the best she can in trying to maximize pleasant working conditions, while maintaining tight rules to keep things under control. A shared open office is not the ideal environment to give people full responsibility over their own working space.

When shared resources are not managed by a central authority, self-organization often results in the Tragedy of the Commons. The name refers to a situation in which multiple self-organizing systems, all acting in their own self-interest, overexploit a shared limited resource, even when they all know it is not in anyone’s interest for this to happen. The impact that humanity has on CO2 levels in the air, trees in the forests, and fish in the sea, is right now the most debated and intensively researched case of the Tragedy of the Commons.

Organizations also have shared resources, like budgets, office space, and system administrators. We could see them as the business-equivalent of the air we breathe, the landscape we change, and the fish we eat.

It is imperative that you instill some form of governance to protect these shared resources. (I realize that most modern day governments are not setting a good example of how to do that.) In the case of shared resources, whether it concerns money, space, or system administrators, someone outside of the development teams must act as a ruler, keeping an eye on long-term organizational stability instead of short-term individual gains.

The Tragedy of the Commons proves that multiple self-organizing teams cannot share authority over a shared resource, because the systems will optimize for themselves, and not for the whole. They can only solve this problem by installing a form of governance… that is… a (resource) manager. You perhaps?

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo';
Latest, greatest and favoritest posts:
Protect People
Self-Organization vs. Emergence
Agile is NOT a Risk Management Strategy

This is a guest post by Pawel Brodzinski. Pawel has his own blog called Software Project Management, where he writes about dealing with software projects in real life. (If you are interested in writing blog posts for development managers and team leaders, like this one by Pawel, then be sure to check out the new Management 3.0 site that I am developing with several other writers. We welcome your ideas and blogging material!)

I have a task for you: think about a manager you respect. One you’d like to work for. How would you describe her or him?

Leadership. Strong motivational abilities. Courage. Care about people. Great organizational skills. Openness. Tolerance. Great communication abilities. Support. Mentoring skills. I guess you counted at least a few of these.

Has "being an asshole from time to time" made it to your list? I didn’t think so.

Think about it a bit more. How did the manager of your choice act when there was a serious slip in production, and a team member asked for a couple of days off? Were they still so agreeable? Or did they put project success over comfort of one of the team members? What happened when budget cuts came and they had to fire someone? And how were they described by a person who got fired? How did they answer when you came with the idea to introduce a cool new technology in the middle of development? Were they supportive? What was their reaction when the team had so much fun making some soft jokes at a newbie (as you always did)? Was it fun to listen to their reprimand?

All of these situations have something in common. There is a point where a bad policeman appears. Someone who blocks our private plans, or fires us, or prevent us from learning new things, or simply kills our entertainment. A kind of asshole really. A manager.

Now, these things are crucial when becoming a good manager and a true leader. Managers aren’t needed so much when everything goes fine, a company has loads of money, people are highly motivated, and know which borders shouldn’t be crossed. However when something goes wrong it is a manager who should react first. Very often someone has to play the role of an ass to fix the problem. Guess who it is.

Probably the most difficult example of the issues mentioned above is firing people. It is nothing pleasant. Personally I hate it. That’s a classic asshole-moment. I have to play this role on occasions because, after all, my employer pays me for that. Of course, from the team’s perspective, things look better when you decide on merits and let go someone, who doesn’t suit your group, but think how many times people are fired just because of budget cuts? And that’s still the role of the asshole... I mean the manager. A person who otherwise might be praised by the team.

When it comes to manager-team relationship these (rare) moments when a manager plays a bad policeman remind people about rules to be followed and borders not to be crossed. If the atmosphere gets too loose it’s usually sufficient to experience a flash asshole-moment and, magically, everyone recalls that there are some rules that need to be obeyed.

The interesting thing is, the further we go into agile management territory the less typical the managerial job we expect. Teams are self-organizing and cross-functional, and sometimes we think a manager should just get out of the way. By the way, surprisingly often this is exactly the best choice. But whenever one of the asshole-moments is needed, it is time to show up and do what has to be done. Otherwise the atmosphere starts rotting as people wait for someone who will fix things. Someone who will do something about this guy adding a new technology every time he reads some nice article. Someone who will deal with that lass taking a few days off because she doesn’t really care about the project being late and the team working their butts off to get back on the right track. That’s always a job for a manager, and a harsh one, no matter how self-organized the team is.

If you dig deep enough in the story of the manager you initially thought of, you should be able to recall a few moments such as these. Odds are, from a perspective of time, they even look like pretty good decisions. However, back then, when it was all fresh, your thoughts most likely included “what an asshole” epithet when you were thinking about the manager.

Thanks to Pawel for his guest post! If you have some ideas to share of your own, feel free to contact me about it.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo';
Latest, greatest and favoritest posts:
Management 3.0: The Era of Complexity
The Delegation Checklist
Managing Risk vs. Managing Yourself

The first three years on high school were the worst of my life. Some guys in my class had chosen me as the center of attention in their need for bullying and harassment. I was regularly the victim of vicious... Jurgen Appelo

Happy birthday to me, Happy birthday to me, Happy birthday dear NOOP.NL, Happy birthday to me! Today this blog is exactly two years old! And I'm happy to report that it is still growing strong! The number of RSS feed... Jurgen Appelo

Happy birthday to me,
Happy birthday to me,
Happy birthday dear NOOP.NL,
Happy birthday to me!

Today this blog is exactly two years old! And I'm happy to report that it is still growing strong! The number of RSS feed subscribers stands at (almost) 4,400. It has (almost) 1,000 page views per day on average. My number of followers has climbed to (almost) 2,000. And the blog's page rank stands at (almost) exactly 5.

Here is a big THANK YOU to all readers, contributors, followers, and lurkers. I would have stopped long ago if you hadn't supported me all the way to get here!

Now... in a normal birthday situation you should be giving me presents...

However, I'm feeling generous and decided to give away free books. Actually, it is my publisher who has kindly offered to support my blog by making available three copies of the following brand new books about blogging:

For a chance to win one of these books, I ask you to do one little thing...

Just send the following tweet, today, or anywhere in the world where it's still January 18:

"Happy birthday to NOOP.NL and @jurgenappelo! (http://www.noop.nl)"

That's all! I will let one of my friends blindly select six people who get to win one of these two fine new blogging books.

And many thanks to Heather Fox from Pearson, who is kindly making these books available for me!

(image by xctmc)

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo';
Latest, greatest and favoritest posts:
Management 3.0: The Era of Complexity
The Danger of Lean: Ignoring Social Complexity
Your Project Will Suffer from Power Laws

The first three years on high school were the worst of my life. Some guys in my class had chosen me as the center of attention in their need for bullying and harassment. I was regularly the victim of vicious jokes, bad treatment, name calling, destruction of stuff I owned, and my schoolbag flying over my head across the room. I was unable to stand up for myself because, at that time, I didn’t know how.

A class room full of kids is a fine example of a self-organizing system. True, the teachers have some constraints concerning children’s presence, homework, and tests, but despite plenty of school rules and directives, whatever else happens in and around school is left to the kids themselves to handle. And there are always a few that suffer from this.

Self-organization is not necessarily a good thing. A group of thugs mistreating a timid kid is an effect of self-organization that needs eradication. Self-organization implicitly assumes that people take care of themselves, which is something not everyone is capable of.

Management literature has plenty of examples of people being mistreated by their colleagues at work. They too can be the victims of vicious jokes, bad treatment, name calling, destruction of stuff they own, or their lunch boxes flying over their head across the room.

As a manager you are responsible for both promoting self-organization and protection of people, like my school was responsible for allowing kids to play and protecting them at the same time. (They didn’t do a spectacular job, I must add.)

But how do you find out if someone is being mistreated?

Honestly, I’m no psychologist. But from personal experience I can tell you that it probably won’t help asking someone “Are you being treated well?” Because everyone, including the kid with the black eye, will say “Yeah, sure”. Some organizations have a counselor to whom employees can turn with their personal problems. But my school had a counselor too. Of course, I never went there. What did they expect? That I would enter his office saying “Hi, I just came by to report how sad I feel that the other kids caused a carton of chocolate milk to burst in my schoolbag?”

I think there are two other approaches that might work. The first is asking someone “Who are your friends here?” (This happens to be question #10 of the 12 best questions to ask an employee.) At school I wouldn’t have been able to answer that question (if they had bothered to ask), because truth is I didn’t have any. Note carefully whether the interviewed person can produce a couple of friends’ names at the blink of an eye, without sweating and swallowing heavily. Of course, lack of friends at work doesn’t have to indicate something bad going on. But you might start by showing genuine interest in the person, like “Well, that doesn’t have to be a terrible thing, but why don’t you and I have a drink later this week, and talk about other things besides work?” It could make a big difference to someone. I know for certain my defenses would have crumbled quickly in front of a friendly face.

The second approach could be to ask the other people. Sure, I could have kept my defenses up and named a few neutral class mates as my “friends”. But my teachers could have asked them “Are the other kids in class being treated equally well?” or “Which of the kids in class are having a hard time?” Plenty of other kids knew about my unfortunate position in the pecking order. Unfortunately, nobody ever asked them. And I spent my time in the boys’ dressing room, using my t-shirt to wipe the chocolate milk of the burst carton from the pages of all my school books.

But you still have a choice. You can ask.

By the way, there’s no need to feel concerned about me now. I have learned to bite back so hard, that my teeth needed renovation.

(image by ratexla)

This article will be part of the book Management 3.0: Leading Agile Developers, Developing Agile Leaders. You can follow its progress here.

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo';
Latest, greatest and favoritest posts:
Yes, Good Managers Are Manipulators
If You Want Something Done, Practice Your Patience
Managing Risk vs. Managing Yourself

This post is part of a series of interviews called "6 Simple Questions". Earlier answers to the same questions came from Bob Martin, Andy Hunt, Lisa Crispin, and Alan Shalloway. Neal Ford is Software Architect at ThoughtWorks. He is the... Jurgen Appelo

This post is part of a series of interviews called "6 Simple Questions". Earlier answers to the same questions came from Bob Martin, Andy Hunt, Lisa Crispin, and Alan Shalloway.

Neal Ford is Software Architect at ThoughtWorks. He is the designer and developer of applications, instructional materials, magazine articles, video presentations, and author of 6 books, including the most recent The Productive Programmer. His primary consulting focus is the design and construction of large-scale enterprise applications. He is an internationally acclaimed speaker, having spoken at over 100 developer conferences worldwide. Visit his web site at http://www.nealford.com.

These are the six questions I asked Neal, and the answers that he gave me...

1. What has been the most effective motivator for you to do your best work ever?

I would have to say it's working with smart, impassioned people. One of the things that I really love is pair programming. While this is a pretty controversial topic out in the world, there is no question in my mind that it produces much higher quality code. This is one of the reasons that I work for a consulting company like ThoughtWorks  --- it is very difficult as an independent consultant to convince someone to pay you to pair program because perception is that you're being less productive if you are pairing. Those who have done it for real realize that you are actually more productive when you're pairing than when you're an individual. You write just as much code, but the quality of the code is significantly higher.

Software is much more about people than technology. Working with the best people motivate you to do the best work. If you don't go to work every morning thinking about what kind of cool thing is going to happen today, you should probably find another employer.

2. What work has been the most difficult for you to delegate to others?

Because I've been a technical lead on projects for so long, I have very little problem delegating tasks to people that I trust. If I had to choose something, it would probably be something that I think that I do really well (whether that's true or not), simply because I think I could get it done more quickly and efficiently than delegating it to someone else. Of course, this is a slippery slope: even if I can do something more quickly than someone else, there are probably more things that I should be doing that I cannot delegate.

3. How would you define the purpose or goal of your work?

This question is easy! I had to make this decision about five years ago when I decided to leave my position as CTO of The DSW Group. I wanted to go to work for a company that was investigating the possibilities of agile on an enterprise scale, and I certainly found that in ThoughtWorks. However, I also wanted to be involved in a company that had the potential to truly revolutionized the IT industry. ThoughtWorks allows me to do both of those things. I could actually make significantly more money as an independent consultant but it is much harder for an individual to make an impact on the overall IT landscape. Working for a company like ThoughtWorks allows me to work on interesting, large scale agile projects and also push the envelope on what the true potential of software really is. I fundamentally believe that software is going to have as much or more impact on civilization as Gutenberg's printing press. Thus, it is important for people to make sure that software isn't co-opted by people who view it only as a way to make money. Can you imagine what would've happened to Gutenberg if a catalog merchant had gotten to him before he started printing Bibles.

The other really important aspect of my employer is its social conscience. ThoughtWorks as a company is very committed to try to make the world a better place using software as the lever. Not only do we contribute lots of projects to the open source world, we do charity and pro bono work for people we believe are making a difference. There are a lot of things both within the IT industry (like the general dearth of female software developers working professionally) and in the real world that represent solvable problems. Attacking and diminishing solvable problems is one of my goals.

4. How have you tried to achieve excellence in the work you do?

Reflection is key. I try to look at all the artifacts I create in the most objective light possible (which is sometimes very difficult). I actually like negative criticism because generally people who are in negatively criticizing you are telling you the truth. In fact, based on comments from an attendee at one of my conference presentations, I ended up changing my entire presentation style. And that led to what I'm working on right now, which is a book about presentation patterns and anti-patterns.

I try to accept criticism as gracefully as I can, even if initially it seems unjustified. Even the harshest criticism has at least a kernel of truth in it, and paying attention to that can allow you to find things that you think you did well but have room for improvement. One of the nice things about ThoughtWorks is the almost nonexistent hierarchical structure within the technical community. Any person on any team can point out deficiencies in architecture or design, which will hopefully lead to making it better. Needless bureaucracy and formality is poison to software projects! You need active, engaged people who will speak their mind at any point in time if you hope to achieve the full potential of the development team.

5. Of which one of your failures are you most proud?

I would have to say that my most noble failure was a project I worked on at ThoughtWorks back in 2005. It was a difficult client, and a difficult problem domain coupled with very difficult technical challenges. We finally delivered some software, but it was not the quality that I would like for it to have been. The part of this project about which I'm most proud is where we managed to invent some interesting mechanisms to improve communication between developers in the US and the distributed developers in Bangalore. I have since used a lot of these techniques on other projects, and even wrote about a few of them in my book The Productive Programmer.

6. And which of your successes was completely undeserved?
That would be just about all of them! I work for a company that embraces collaborative work. Even if I was ostensibly the main person who benefited from the success of the project, it is always a group effort. I probably wouldn't characterize it as completely undeserved, but I fundamentally believe that collaborative work always yields better results than singular work, especially when you're building something as complex as software.

Well, these are the answers given by Neal Ford. I hope you liked them.

 Twitter -  Subscribe - Newsletter - Bookmarks

tweetmeme_url = 'http://www.noop.nl'; tweetmeme_source = 'jurgenappelo';
Latest, greatest and favoritest posts:
6 Simple Questions for Bob Martin
6 Simple Questions for Andy Hunt
6 Simple Questions for Lisa Crispin
6 Simple Questions for Alan Shalloway 

Many years ago, during a board meeting, I once heard someone ask: “What was our corporate shared value of this year again?” And the CEO answered that it was courage. I didn’t even know there was a “corporate value of... Jurgen Appelo