Agile Management | NOOP.NL

The Big-Ass View on Competency (video)

Here's a video of a talk I did at the Norwegian Developers Conference. The talk is about different ways of developing competence in an organization, and it draws on traffic management as a metaphor. The original slides can be found here.

The talk scored quite well: 31 green cards, 3 yellow ones, and no red cards. I calculated that this would correspond to 95% satisfaction (assuming that green = 100%, yellow = 50% and red = 0%).

A kind word to my Swedish and Belgian readers: I didn't really mean what I said in this video... I'm sorry. :)

BTW, You cannot hear the Norwegian audience laughing out loud during my presentation. But they actually did!

This video is provided courtesy of my friends at Programutvikling AS, the organizers of the NDC2010 conference.

p.s. Go to the Tandberg Content Server for 122 other fantastic presentations!

 Twitter -  Subscribe - Newsletter - LinkedIn - SlideShare

Latest, greatest and favoritest posts: OK, Let’s Talk About Certification Quality: You Don’t Get What You Don’t Measure About Project Success and Failure

T-Shaped People

I love specialists.

But specialization has its problems. It can lead to bottlenecks when specialists are unable to cope with demand, and others are unable to take over for them. For example, I personally designed the corporate web site of our business unit, including interaction design and graphics design, because our regular designers were unavailable for weeks.

And specialization can lead to stagnation when the specialists are unable (or unwilling) to pick up work that they are unfamiliar with. For example, I did ask a software developer to help me carry out some marketing activities I could not have done on my own. Our marketing efforts would have stalled if he had not willingly co-operated.

I have no use of people telling me they have a “broad range of skills,” meaning that they never specialized in any specific area. I prefer specialists over generalists. But I like it even better when the specialists have a few extra areas in which they have built up some knowledge and expertise. Fortunately, I’m not alone in that opinion.

A generalizing specialist is someone who: 1) Has one or more technical specialties […]. 2) Has at least a general knowledge of software development. 3) Has at least a general knowledge of the business domain in which they work. 4) Actively seeks to gain new skills in both their existing specialties as well as in other areas, including both technical and domain areas. – Scott Ambler, “Generalizing Specialist: A Definition”

A generalizing specialist does one kind of job very well and some other jobs adequately. With generalizing specialists your teams enjoy the benefits of high productivity, while lowering the risk of bottlenecks, and retaining flexibility. Generalizing specialists are sometimes called T-shaped people:

We look for people who are so inquisitive about the world that they’re willing to try to do what you do. We call them “T-shaped people.” They have a principal skill that describes the vertical leg of the T -- they’re mechanical engineers or industrial designers. But they are so empathetic that they can branch out into other skills, such as anthropology, and do them as well. They are able to explore insights from many different perspectives and recognize patterns of behavior that point to a universal human need. - Tim Brown, “Strategy by Design”

When hiring people, and putting together teams, look for T-shaped people. Always check if they are specialists in at least one useful area, and then verify that they are willing and able to pick up other kinds of work as well. If you’re looking for a software developer, make sure it’s a good one. But also ask some questions about graphics and design. Maybe even marketing. Or you could go totally crazy and ask about blog writing.

(picture by TooFarNorth)

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

Latest, greatest and favoritest posts: OK, Let’s Talk About Certification Quality: You Don’t Get What You Don’t Measure About Project Success and Failure

Standards: Grow Them, Don't Make Them

Every time I’m in the United States I waste time on physical and mental conversions of standards. I convert all transactions from dollars to euro’s, and vice versa. I convert miles to kilometers, gallons to liters, and am/pm to 24 hours. And by now I have at least four adapter plugs to convert from European electrical sockets to US sockets, because I sometimes forget to pack them, despite the fact that they are listed on my traveling checklist.

Despite the hassle that travelers worldwide have to put up with, I don’t think it is a good idea to ask the United Nations to enforce global standards for sockets, currencies, and measurement systems. Different parts in a complex system will always try to optimize for themselves, and therefore local systems will switch to global standards when it is optimal for them to do so. This is exactly what happened in Europe: 16 European countries voluntarily switched to a new pan-European currency because they figured that the opportunities and long-term cost savings were higher than the one‑time switching costs. Some other European countries have not (yet) taken this step because their perceived costs (financial, political, and cultural) are apparently still higher than the benefits.

Standardization is usually not something that needs to be enforced. No worldwide government was necessary to make billions of people around the world to standardize on the 24-hour clock, the Gregorian calendar, the English language, or Right-hand traffic. True, there are plenty of deviations from the international standards. Positive feedback loops will only lead to adoption of standards when it pays to do so.

After choosing our activities, we begin to perform them. As we do so, the next event in self-management comes into play – monitoring our performance for competence. This event, then, involves making sure that our work activities meet our standards. During the compliance era, work standards were external and set by managers at fixed levels. Workers were charged with doing work that met these levels – doing “good enough” or “satisfactory” work. In contrast, self-management involves committed workers meeting their own internal standards of competence. Internal standards are more dynamic: people raise their standards on tasks they care about as they become more skilled and experienced at the task activities.
– Intrinsic Motivation at Work (Kenneth Thomas)

In software development, competence leaders work with people to discuss their own internal standards, not management-imposed standards. Like naming conventions, coding standards, user interaction conventions, file structures, configuration management practices, tools, error log standards, and security standards. There is no need for management to make top-down standardization happen. Bottom-up standardization will happen when goals and metrics make it painfully clear for employees that it is more optimal for them to change.

(figure by Biking Nikon PDX)

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

Latest, greatest and favoritest posts: When You Are Rejected Yes, Good Managers Are Manipulators Agile is NOT a Risk Management Strategy

OK, Let's Talk About Certification

Like many agile software development evangelists I am somewhat skeptical toward people taking pride in their certificates. In my experience, a certificate proves little about a person’s capabilities, other than that she was at some point in the past in some measurable way aware of some information. That’s it. Even “skill-based” certifications, which supposedly test for a person’s skills instead of their knowledge, prove little more than the ability of a person to perform certain activities in a sandbox. They certainly don’t test the skill in successfully completing a real project.

It seems that certificates have very little effect on a person’s competence. A good friend of mine, who is expert in traffic management, believes that the Dutch driver’s license has been the least important contributor to the Dutch top position as one of the safest country in the world to drive around in your car. The main contributor to Dutch (relative) road safety, he said to me, has been one of culture, not certification. Dutch people care. About their car, their money, and other’s people’s lives. (And in that order, I think.)

In software development and project management we have a similar issue.

The Project Management Institute’s PMP (Project Management Professional) certification seems to have quite rigorous requirements--they require their PMPs to take ongoing education classes, have a certain amount of experience, and so on. And I’m sorry to say that, although I’ve known good PMPs, it’s also true that the worst project managers I’ve met were PMPs who should never have been put in charge of a project. They were also the ones most proud of their certification, and most unaware of their deficiencies. I don’t know what the PMP means, but it does not mean “basic minimum of competence.” – The Art of Agile Development, James Shore

This critique could apply to any certification, and I believe it could easily lead to the fallacy of Hasty Generalization. You see, despite there being many certified people with terrible performances, this doesn’t mean that certification is unable to sort an effect. It could very well be (as I believe is the case) that certification is part of a bigger and complex approach to address the issue of competency. True, certification in itself may have little effect. And certificates may falsely lead people to believe that they have a formal degree of competence. A certificate by itself is useless. It may only have a positive effect when combined with other measures. Certificates can lay a foundation of awareness for what’s out there, and what’s important. When combined with a personal coach, social pressure, proper tools, some supervising, and capable management, a certificate could pay for itself a hundred times.

The Dutch know that a driver’s license alone is not enough to minimize casualties in traffic. But when discipline, road marks, car horns, traffic police, and law making are in place, the effort of obtaining a certificate (or driver’s license) could be the catalyst that makes all the other measures work a lot better.

(image by The Lightworks)

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

Latest, greatest and favoritest posts: 7 Approaches to Competence Development The Delegation Checklist The Three Types of Change

Managing vs. Coaching vs. Mentoring

In many organizations people are used to the idea that functional managers are responsible for assisting people with their personal development. As managers, we care about our people’s skills, their knowledge and experience, their training, and their discipline (or, in some cases, lack thereof). For their good behavior we offer compliments, and for their bad behavior we give a scolding, and maybe a shoulder to cry on.

As functional managers, it seems, we are our people’s personal coaches:

Part of a manager’s job is to coach his or her direct reports to increase their capability and effectiveness within the organization. Coaching can focus on either interpersonal skills or technical work that is relevant to the job. […] You may coach someone who has decided to work on a performance issue, or you may coach to develop new skills and insights.

Behind Closed Doors: Secrets of Great Management
(Johanna Rothman, Esther Derby)

But there are other options as well...

Managing people is different from coaching people. As a functional manager you might be responsible for interviewing job candidates, controlling budgets, negotiating salaries, checking daily reports, checking weekly reports, checking monthly reports, checking yearly reports, and reminding people how important it is that they give you those reports. So you can check them.

As a functional manager you must also make sure that people who need it have a personal coach. But that doesn’t have to be you! You can delegate this responsibility and empower (senior) people to coach the (junior) colleagues, in order to develop their skills and capabilities. In earlier centuries it was common for ‘masters’ in a trade to delegate the coaching of ‘apprentices’ to ‘journeymen’. In fact, the journeymen were often better at coaching than their masters.

Every person in the organization has just one manager, but they have zero, one, or even multiple coaches, for different areas of personal development. You don’t even have to be a coach for the senior employees. You can delegate that by hiring an external consultant. While still acting as everyone’s manager, you could save yourself a lot of time, while empowering people by giving them coaching responsibilities, all in a single stroke!

Coaching responsibilities of managers are a frequently recurring theme in management literature. I believe it is a fallacy that has grown from traditional hierarchical thinking, which assumes that managers have higher competency than their subordinates (often a primary reason to be moved up in the chain of command). From a complex systems perspective this is nonsense. Top managers cannot be superheroes. A manager is just as fallible as his subordinates. (Or even more so when the stakes are higher.) The only thing you need to be good at, is figuring out which persons, inside or outside the organization, would be fine coaches to assist in the various competences your people need to develop. Mary and Tom Poppendieck call them competency leaders, responsible for setting standards, and developing people:

What do competency leaders actually do? First and foremost they are committed to developing excellent technology in their organization. They begin by framing good software development in terms of an enabling architecture, mistake-proofed processes, evolutionary development, and technical expertise. […] They set standards, insist on code clarity, and make sure code reviews are focused on enhancing learning. […] Probably the most important role of a competency leader is that of a teacher who guides the purposeful practice necessary to develop expertise. […] Competency leaders are often line managers, but line managers are not always competency leaders.

Leading Lean Software Development: Results Are Not the Point
Mary Poppendieck, Tom Poppendieck

One last word of advice is appropriate here for people seeking mentors. A mentor is not a coach, though the words are often mixed up as if they are synonyms. A mentor deals with an employee’s personal life or career, has no specific agenda, and has focus only on the individual. A coach deals with a person’s tasks and responsibilities, has a specific agenda or development approach, and has a focus on a person’s performance. As a manager you may assign the coach, but you have nothing to do with someone’s mentor. Mentors are like lovers and mistresses. Whether someone has one or not is very interesting, but nevertheless none of your business.

(photo by image42)

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

Latest, greatest and favoritest posts: Doing What Matters, No Matter What Communicate Your Goals! People Motivation: Target Intrinsic Desires

Optimize the Whole = Measure at All Levels

We know that measuring (and awarding) the wrong things in a system leads to nasty side-effects. And we know that self-organization allows a system to optimize for itself. In systems theory these concepts are known as the Sub-optimization Principle:

If each subsystem, regarded separately, is made to operate with maximum efficiency, the system as a whole will not operate with utmost efficiency. - General Systems Theory (Lars Skyttner)

The answer to this problem, and one of the basic principles of lean software development, is to always optimize the whole. Peter Drucker once said: “what gets measured gets managed,” and an alternative saying is: “what you measure is what you get (WYMIWYG).” Logically it follows that, in order to get an optimized whole, we have to measure the whole. What you measure (and constrain) has to cover everything, from start to finish, from top to bottom, or else the unmeasured and unconstrained parts in the system will self-organize toward sub-optimal results.

Many times I have struggled with the sub-optimization principle. I have measured overrun on projects at the team level, and subsequently got complaints from some team members that they were not responsible for the overrun, because they only got involved later in the project. I have measured individual skills, and subsequently got complaints that those particular skills had nothing to do with getting products delivered to the customer. Sometimes it seemed my only reliable metric was the steady number of complaints from people about the metrics.

Agile experts strongly believe that team members have to self-organize to optimize the output of the whole team, and not of the individual team members. I agree. But then many agilists suggest to measure only teams, not individuals. That’s where I am of a different opinion.

If this were a correct approach, then the same reasoning would apply to teams within a business unit, and business units within an organization. In every case measurement of (only) the subsystem would lead to sub-optimization at the next higher level. Taken to its extreme there would be one and only one proper metric: “continued survival and success of the whole organization,” which doesn’t look like a particularly useful one to me. (Note: even “profitability” is not a good metric at the organizational level, now that the credit crisis has proved that this metric alone also leads to sub-optimization.)

Evidently, optimize the whole cannot mean that we need to move all metrics to higher organizational levels. After a few recursive steps there wouldn’t be a sensible metric left to use. A more logical approach is to ensure that the combination of our metrics leaves no gaps in our measurements and understanding of the entire system. A metric of individual performance is fine if and only if it is augmented with metrics at the team level. And metrics concerning individual teams are OK if and only if supplemented with metrics for entire business units, and the organization as a whole.

One could even turn this into a fifth agile value:

Global metrics over local metrics.

While there is value in the item on the right, we value the item on the left more. But that doesn’t mean that the item on the right is unimportant…

(image by Pink Sherbet)

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

Latest, greatest and favoritest posts: Fix the Small Problems First Communicate Your Goals! Are We Abusing Science?

7 Approaches to Competence Development

While preparing for various speaking engagements, I once contacted a person who specialized in representing professional speakers. I sent her an email describing myself, my talks at conferences in Europe and the US, the book I was writing, and the opportunity for new business. I waited three weeks and got no reply. After sending her a reminder I promptly received an apology and the promise that I would be called the very next day. Then I waited, and waited… And after three days I reconsidered my idea of hiring her to handle my business emails and customer calls.

I wrote about skills and discipline before, and I’ve come to the conclusion that there are seven approaches to developing competence in an organization:

1. The Self
Self-discipline and self-development refer to the training that one gives one’s self to adopt a particular pattern of behavior. Nobody needs to tell me that I should answer other people’s calls and emails within a reasonable amount of time. It is part of the behavior I have adopted myself, and that I intend to stick to.

2. The Coach
Coaching is the method of training a person, with the aim to develop specific skills and behavior. A coach might be able to help someone in establishing proper email usage patterns, making sure that she doesn’t leave other people’s emails unattended.

3. The Certificate
A certificate says (or should say) that some external authority has verified that a person has shown the necessary skills, behavior, and willingness to be able to carry out certain tasks. Like picking up a working phone and dialing a correct number.

4. The Signals
Signs and signals are a way to steer people’s behavior by making sure that they know what they need to do. Just one hour before I wrote this paragraph I ticked off “call back customer” from my own To-Do list. I configured the system to notify me in case I forget about such important items.

5. The Peers
Peer pressure refers to the influence exerted by peers in a group to encourage a person to change her behavior in order to conform to the norms of the group. The first time a person keeps me waiting I gently and understandingly remind her when I am still waiting for a reply. The second time I make sure to communicate honest and heartfelt annoyance. The third time I bite her head off.

6. The Supervisor
Supervising is the act of giving instructions to people, and making sure, on behalf of an organization’s management, that people are doing their jobs properly. For example: in some organizations it might be a good idea to check occasionally whether people are handling their calls and emails properly and timely.

7. The Manager
Leading and governing are part of the manager’s job. It is about setting good examples, and about ruling and judging in case someone has acted against the interest of the organization. Like damaging the corporate reputation by completely ignoring a potential customer.

Apparently, developing competence in an organization is a concern spanning seven levels, where each level can be seen as a fall-back scenario in case the one before it fails. Competence is, in the first place, a personal responsibility. When people aren’t capable of developing competent behavior themselves, they may need to be coached into it. If that coach is unavailable, or incompetent himself, development of competence can possibly be achieved through some combination of certification, properly used tools, and the person’s peers. Finally, when none of this works, and a supervisor is unavailable (or incompetent as well), then the manager is the one who (rightfully) gets the blame for any business lost.

These are, what I’d like to call, the seven levels of competence development: self-development, coaching, certification, signs and signals, peer pressure, supervisors, and managers. The first level is where it should all begin, and each consecutive level exists as a fall-back scenario for the previous ones.

(image by Gilberto Santa Rosa)

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

Latest, greatest and favoritest posts: No Maturity Models, But Individual Competence Discipline * Skill = Craftsmanship Quality: You Don’t Get What You Don’t Measure

No Maturity Models, But Individual Competence

There are dozens of maturity models in the world of software development and in other business environments. But I find the concept of maturity models of little use, and perhaps even a bit offensive.

How would you rate the “maturity” of marketing agencies? Would you measure how well they are able to perform tasks like conversion of graphics files, ad placement negotiations, and search engine optimization? Or would you simply look at the success of their marketing campaigns, like this one? How would you rate the “maturity” of plumbers? Would you measure their ability to wield pipes, pumps, gauges, and valves? Or would you just consider whether they are leaving behind happy housemen and housewives? Like some other managers and writers I believe maturity models are too narrowly focused on processes.

While well intentioned, many of these models are mechanistic and […] invariably fail to recognize that the sole compelling reason for a firm to develop business process management practices at the enterprise level is to improve the performance of the organization in delivering value to customers and shareholders. Accordingly, many of these ‘Process Maturity’ models do not explicitly take into account the following two fundamental realities: 1) Organizations are both complex business and complex social systems; 2) Exemplary business process management performance demands that leaders work collaboratively and cross-functionally. - Andrew Spanyi "Beyond Process Maturity to Process Competence"

Organizations are living systems. Assigning one rank (a maturity level) to an entire organization is just as useless, and potentially offensive, as assigning one single rating to me, Jurgen Appelo, for everything that I am, produce, and stand for. It flies in the face of complex thinking. Therefore I don’t believe that maturity models are the proper way to address and assess professionalism in organizations.

If it is performance that really counts, then we need to go beyond maturity to look at how an organization develops business process competence. - Andrew Spanyi "Beyond Process Maturity to Process Competence"

I prefer talking about (individual) competence over (corporate) maturity. Let's try and make people competent, instead of attempting to make organizations mature.

(image: Sukanto Debnath)

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

Latest, greatest and favoritest posts: Discipline * Skill = Craftsmanship Scientific Case for Bottom-Up Rulemaking Management: A Deceptive Metaphor

Fix the Small Problems First

My home desk is a mess. When I look around me I see books, magazines, invoices, glasses, a hideous little white Christmas tree from three months ago, speakers, external hard drives, two calculators, a scanner, a printer, post-it notes, medicines, business cards, pencils, pens, color markers, a ruler, batteries, and there’s even an acorn (from Kiev) and a chestnut (from Helsinki). My desk at the office looks more or less the same, except for the acorn and the chestnut. And the messier my desk is, the messier it gets. After all, with a loaded desktop nobody will notice when I throw another pinecone on it.

In his book The Tipping Point Malcolm Gladwell described how the New York police was able to reduce crime rates in the city by relentlessly targeting small offenses, like graffiti on walls, subway fare evasion, and public drinking. The idea of “zero tolerance” was based on the Broken Windows theory, which says that signs of disorderly and petty criminal behavior trigger more disorderly and criminal behavior, thus causing the behavior to spread. By punishing all the little ways in which people make a mess of their environment, and cleaning things up frequently, it is believed that more serious crimes can be prevented.

Social psychologists and police officers tend to agree that if a window in a building is broken and is left unrepaired, all the rest of the windows will soon be broken. This is as true in nice neighborhoods as in run-down ones. Window-breaking does not necessarily occur on a large scale because some areas are inhabited by determined window-breakers whereas others are populated by window-lovers; rather, one unrepaired broken window is a signal that no one cares, and so breaking more windows costs nothing. "Broken Windows" - James Q. Wilson and George L. Kelling

A number of scholars have criticized the Broken Windows theory. They have found issues with correlation and causality, which may have led to fallacies in case studies like the famous New York city crime rate example. However, there is sufficient evidence that at least the principle behind the Broken Windows theory is sound. The theory is also a logical extension of a more generic idea, called Lewin’s Equation:

B = f(P,E)

This equation, developed by psychologist Kurt Lewin, states that behavior is a function of the person and his or her environment. Or in other words, people tend to adapt their behavior to the environment that they live in.

Given that people also copy each other’s norms and behaviors (memetics), and that therefore bad behavior is likely to lead to more bad behavior (positive feedback loop), it is easy to see how all these concepts combined automatically lead to the Broken Windows theory.

But what can we learn from this? In my opinion, two things:

1. Big problems often start as a small problems, that weren’t nipped in the bud when they were still manageable;
2. If a problem is too big to handle, then target another related but smaller problem.

Address the small problems first, and you'll have less work when addressing the big ones.

(photo: Shoes on Wires)

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

Latest, greatest and favoritest posts: Discipline * Skill = Craftsmanship Quality: You Don’t Get What You Don’t Measure The Three Phases of Creativity

The Success of the Agile Memeplex

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

Latest, greatest and favoritest posts: Discipline * Skill = Craftsmanship If You Want Something Done, Practice Your Patience Managing Risk vs. Managing Yourself