Sure there are plenty of great ideas published. For every great idea tens, hundreds or even thousands of others have been considered and discarded. They didn’t work at that time for that problem in that context. Only the single great idea survived, the rest is discarded.
As time passes, the landscape changes. As this happens, those ideas that came second or even twenty second suddenly become the front runner… but only if they are in the race.

Start meme wombling today and save these ideas that have a life of their own!

Meme

“History is written by the victor.” This is especially the case when we are talking about memes. Memes are those “ideas that have a life of their own”. Originally coined by Richard Dawkins and Roger Penrose, more recently Julian Everret has been doing some important work with creating an entire meme concept. Julian draws heavily on his background in evolutionary biology to map genes to memes. He introduces the idea of a “landscape ” and how a meme expresses itself and behaves differently in different landscapes.

Thomas Edison is famous for saying: “I have not failed. I’ve just found 10,000 ways that won’t work.“. He had researched more than ten thousand materials for the light bulb filament before he settled on Tungsten. What happened to the other ten thousand? What were the materials that almost won but were beaten close to the finish line by Tungsten. That’s a lot of knowledge lost, all we know is the name of the winning meme in the light bulb filament landscape given the context at that time.

Meme Wombling

Wombling is about finding the memes that are lost. The ugly memes that a field of study is ashamed of, and as a result does not promote. Meme wombling is where we hunt down a meme that had little value in one landscape and transfer it to a different landscape where its new behavior helps us address a need.

Meme wombling is very much like going through the waste paper bin of a field of study. Thanks to Dan North for creating the term “wombling”. The Wombles were characters in a British children’s TV show. They went through the bins looking for valuable stuff that ordinary folk leave behind. They found value in other people’s waste.

Agile Meme Wombling

The Agile community is full of super smart people. I know that if I have an idea, chances are that someone else has already had the same idea. If I think studying kitchens will help me better understand software project management, you can guarantee someone already beat me to it and presented an experience report many years ago. If it were a good idea, someone would already be promoting it.

Normally when we want to learn about a subject like kitchens, we would find someone we know who works in the industry, or read a book about it. The person or book would normally tell us the techniques that successfully accomplish the task at hand. Sometimes we are lucky and can bootstrap our learning. Other times we find that our landscape is different in some crucial manner. In that case these ideas don’t survive the transition. They fail. The victor outperforms them and the vanquished idea is cast to the waste paper bin.

As time passes, the landscape changes. As this happens, those ideas that came second or even twenty second can suddenly become the front runner… but only if they are in the race.

Recent Agile Meme Wombling

You may have very well been a witness of this in the recent history of agile. The agile community is full of bright people and we are constantly learning and adapting. Let’s look at two recent examples: Kanban and the system metaphor.

Kanban

Many things we now value as being agile are inspired by lean thinking. These are the ideas that survived the transition. Other ideas borrowed from lean manufacturing didn´t survive the transition from physical productie to knowledge work. One of these ideas is working with a kanban system. Initially it was tried and it didn´t work at that time so it was discarded as unfit for knowledge work.

With some significant tweaks David Anderson was able to make Kanban work for knowledge teams. These ideas met with a great deal of scepticism initially as it had been tried and deemed a failure. David and many others who have applied Kanban with these tweaks proved that it is a good way of working. If David wouldn´t have gone through the discard bin of Lean one of the newer methodologies would have been lost to us.

Metaphor

The other example of the result of meme wombling is the new use of the system metaphor. The system metaphor was one of the initial XP practices and later got less and less attention. Nowadays there are not many teams that use the system metaphor as a way of designing a system.

At XP2010 Joshua Kerievsky presented a session where he described how he had used a metaphor to shape how his company thinks about their learning solution. They choose a particular metaphor for their business and applied this theme to everything.That metaphore is not only part of the architecture but also of the whole application up to and including the user interface.

How to start meme wombling

Here’s how to start solving problems using meme wombling.

1. Assume that anything you can think of someone has already thought of looking for a solution in that domain already.
2. Avoid reading books for ideas, especially the popular ones.
3. Read books to identify practitioners in the community of interest.
4. Network into that community.
5. When you find that practitioner go through the (mental) waste paper bin to discover those memes that came “second place”.
6. Another strategy is to peruse out of print books for ideas that are no longer considered relevant. Second hand bookshops are best for this, although www.abebooks.com is great if you know the author or book title.
7. Seek out those who have an experience you do not understand, experiences that do not fit in your model of understanding.
8. Experiment. Try out little ideas all the while and see how they work.

This post is inspired by an article by Ellen Gottensteiner. Is an “Agile Business Analyst” an oxymoron. Before we answer this question, we first need to understand what “Agile” and “Business Analyst” mean.

“What is Agile?”

Anyone involved in Agile will know that no two people have the same understanding of Agile. Some feel it is defined by the Agile Manifesto. Others feel the Agile Manifesto was simply a “Call to Arms”. Some feel Agile should be solely focused on software development. Others feel it’s principles and practices extend beyond software into business, the home and even apply to law. You can read the manifesto at www.agilemanifesto.com. My personal view is that the first line is the manifesto. “We continue to learn how to do software by DOING it, and helping others do it”. It goes on to give a status report… So far, we have come to value the items on the left more than those on the right. The principle that seems to indicate “The Agile Business Analyst is an Oxymoron” is the “Working Software over Extensive Documentation”. After all, writing extensive documentation is all that a business analyst does. Right?

“What is a business analyst?”

The IIBA defines a business analyst as someone who practices business analysis techniques. The business analyst may have the job title “Project Manager”, “Developer”, “Tea Boy” or even “Business Analyst”. So what are the skills of a business analyst? I’ve interviewed about two hundred business analysts over the past few years. At the start of each interview I tell the candidate my view on the role of a business analyst… “Someone who knows the business well enough to argue with them. Someone who understands technology well enough to know what the developers need, and finally someone will need to be skilled in the business analysis tools to take the ‘vague and fluffy’ statements of the business, and turn them into the precision needed by the developer.” This is not a simple role. You need to be an SME, have a strong knowledge of technology, and have business analysis skills. Some business domains are less demanding and it is possible to learn the domain “on the job”. Other domains demand you know your business knowledge before you start.
When I think of business analysis tools, I mean business modelling (Entity Relationship Modelling, Object Modelling), Use Cases, Storyboards (Screen and Report Mock Ups), and State Transition Diagrams… And the rest.

The value of a Business Analyst.

Originally I was going to write “A good business analyst…”. But that is wrong. Its confusing the job title with the skill set. Its like saying a “good John Smith” or a “bad John Smith”. A business analyst is someone who uses business analysis tools. So, second attempt. A good business analyst adds value in a number of ways.
• Ensure that the project is developing those items of most value to the business.
• Asks the business detailed questions so that they have time to find an answer. These questions will naturally occur during the development. However, waiting for the answer can block development or result in incorrect assumptions. This will allow development “Flow”.
• Help the development team articulate a business case for paying down technical debt.

“What is an Agile Business Analyst – Whence The Business Coach?”

Agile changed the rules. In 2003, Andy Pols (a developer and many other things) and I (a business analyst and a couple of other things) re-evaluated the business analyst role in light of Agile. We started from the assumption that we did not need a business analyst. From there we identified the value they added that we needed to put back into the project. After many cups of coffee, and a few pints of beer, we came up with the “Business Coach” role.
We identified the following significant differences in Agile compared to traditional approaches.
• People no longer operate in silos with clearly defined responsibilities. The project took collective responsibility rather than individuals. The business analyst needed to extract knowledge from the whole project rather than be the “Truth” or an SME.
• Traditional analysis tools like UML produce models which are of little value to the Agile developers. Agile developers wanted to work with tests/examples rather than models.
• Agile developers want to work more closely with the business. It became obvious that the business analyst could no longer act as a gate keeper to the business. The developers needed to speak directly to the business, and to do that they needed detailed business knowledge. The business needed a better understanding on how to work with the development team.
• Knowledge needs to be in the heads of project members rather than in documents. (If you think it’s painful to read thirty nine versions of a forty page functional specification, how painful do you think it is for the person writing it? Ditching extensive documentation to focus on more valuable activities is one of the most liberating experiences in my career as a business analyst.)
In order to address these issues, the Agile Business Analyst needs skills to facilitate collaboration (Collaborative Requirements by Ellen Gottensteiner). They need to know how to generate examples rather than models (Feature Injection by Chris Matts <- Me ). They need knowledge transfer skills so that they can help the business and developers learn the skills they require. (Accelerated Learning by David Meier, Situated Learning by Lave & Wenger, David A. Kolb’s Circle of Learning, Visual-Audio-Kinestetics, Neuro Linguistic Programming).
Given the shift to a more facilitative role focused on team learning, we decided to name the role “Business Coach”.

The Agile Business Analyst is an Oxymoron!

If your view of the Agile Business Analyst is an “order taker”. Someone who simply writes down what the business sponsor/user wants. If you see the business analyst as someone who creates extensive documentation, then an “Agile Business Analyst” is an oxymoron. After all, Agile values “working software over extensive documentation”.

The Agile Business Analyst is NOT an Oxymoron!

I believe the Agile Manifesto is out of date. Many people agree with me. I believe in the principle “Delivering business value OVER Working Software OVER Extensive Documentation”. The Agile Business Analysts can add value so it is not an oxymoron.
The Agile Business Analyst role is evolving. It is responding to the challenges of Agile. Pioneers in Agile Business Analysis like Kent McDonald, Greg Goodman, Ellen Gottensteiner, Joe Little and Ryan Shriver have been developing practices for many years. Agile Business Analysts are adding value on many projects. David Morris is currently leading an initiative to write an Agile extension to the IIBA Business Analysis Body of Knowledge. If you have experience as an Agile Business Analyst, please add your story to the Body of Knowledge.

In the end, it’s all about our definitions. As we cannot agree on a definition of Agile, it’s hard to determine whether the business analyst has a place in it or not. That said, many projects find business analysts to be very valuable. Perhaps practice shows us the theory is flawed?

Sadly there are those involved in the Agile movement whose view of the business analyst has not moved on. They are selling a view that is many years old. They talk about “Bad Business Analysts” not realising that a “Bad Business Analyst” IS an Oxymoron.

This week Pollyanna Pixton said that she finally got that “Agile is Learning”. Personally I think Agile WAS a “Love of Learning.”. Now it appears to be a “Love of selling”. We need to get back to the learning but that is a subject for another post.

The first line of the manifesto is…

“We are uncovering better ways of developing software by doing it and helping others do it.”

It is a manifesto to create a software learning community. In fact, its more than the first line of the Agile Manifesto. IT IS THE AGILE MANIFESTO. A personal commitment to continually strive for better ways to do software development. But not theory, stuff that works on the ground. Stuff that works out in the wild rather than ivory towers or theoretical landscapes.

The rest of the Agile Manifesto is actually a status report…

Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Pragmatists and experiential learners would never assume perfection or a complete solution that would never evolve. The implicit and missing words are “so far”

So far,through this work we have come to value…

As Alistair Cockburn said to me “The Manifesto is a historical document that should remain unchanged”. And I agree.

However, we can issue new status reports without rewriting the manifesto.

I have one small tweak I would make to the original manifesto. “We are uncovering better ways of developing software by doing it and then helping others do it.” After all, it would be nice if the people who taught this stuff could actually do it.

Chris Matts (Easter 2010)

This post is respectfully dedicated to Luke Hohmann’s friend Martha.

As stated in the “community of thinkers” we believe individuals should never become the bottleneck to learning. Therefore we have created this list of people we have learned from. While we may not agree with every idea they have, each conversation we have had and each piece of information we have read, has led us to where we are now. When you want to learn about the backgrounds of our ideas we recommend engaging these people, either by reading their publications, books and blogs, following them on twitter and listening and talking with them.

Lean / Kanban

The book that started both our earlier interest in Lean was “The Goal” by Eli Goldratt. Later followed by the writings of Tom and Mary Poppendieck, James Womack and Jeffrey Liker. We enjoy Lean as many of the principles are related with the agile way of thinking. Even though we liked the ideas of Lean we had trouble implementing them in software development.

In 2007 when we were at the Agile 2007 conference we had the pleasure of attending the open space session where David Anderson presented his work with Kanban. This resonated with what Chris had already been doing in the UK as it was very similar. Similarities were caused by following the same influences (Poppendiecks, Eli Goldratt and David himself). It was during a discussion with David immediately after that session that the image of the rope looping through a hole came to Chris for explaining Feature Injection. We are now using that image in the comic book about feature injection.

After the conference, the yahoo group kanban_dev was started. On this list we met many people online that were actively experimenting with Kanban. On the list we met Corey Ladas, Jim Benson, Eric Willeke, Karl Scotland, Kenji Hiranabe and many others.

We have met, shared ideas with and/or learned from many others along the way. We list them in the table below. For your convenience we have listed the names, websites, twitter accounts and books of the people who’s shoulders we are standing on.

And when following the path of others, think for yourself and create your own opinion. With all that knowledge and your opinion comes a responsibility. A responsibility to enable others to do what you have done:
Share the shoulders you stand upon!

We are creating a series of posts on who influenced us along the way in many areas. We encourage you to do the same.

Episode 1: Kanban / Lean (published)
Episode 2: Finance / Economics (next week)
Episode 3: Other agile
Episode 4: Motivational / Inspirational
Episode 5: Great people / great conversations
Episode 6: Weird stuff

The following is not a theoretical thought experiment; it is based on our real world experiences tackling these problems. It has worked for us in our situations and so we offer our experiences that others may benefit from these too.

We would like to suggest that the Lean Software Development community consider real options as an upgrade of the tools in the Lean Software Toolkit, a Lean v1.01, rather than a new approach.

In this article we’ll discuss three of the principles of Lean: “Defer commitments”, “Last responsible moment”, “Pull” and explain how you could improved these by applying real options. But first a little history of real options.

History of real options

Real options first appear at the start of the agile journey. Kent Beck was working with Hakan Erdogmus and John Favaro on real options and published this in “Extreme Programming Explained”. Also “Lean Software Development” by Tom and Mary Poppendieck mentions real options. These two very influential books are two of three books I still recommend to anyone new to Agile (the third one being Alistair Cockburn’s “Agile Software Development”). Real options have been part of Agile and Lean from the start.

Our interest in real options began when Kevin Tate displayed a slide on how a business investor looks at the risk involved in doing projects. He compared the risk profile of an Agile project with the risk profile of a Waterfall project. Being an investment banker  I realised Agile was less risky than Waterfall due to the options embedded within agile. I tried to value those options and failed miserably. Valuing the options within an agile project using financial maths is impossible.

What we did discover was a simple model that allows us to exploit the embedded options better than before. The three rules in the real options model are:

Options have value.

Options expire.

Never commit early unless you know why.

And thus was born the real options model.

Lean Software Development

Last month I was fortunate to be invited to spend a day with Ola Olnestamm and a couple of colleagues at Agical in Stockholm, Sweden. It was the first time I had had the opportunity to sit down and really discuss real options for a while. Although the model is simple, it’s implications are big. An hour presentation or five minute chat does not cut it for this subject.

One of the interesting outcomes was a comparison with Lean Software Development. Lean Software Development has a number of principles, three of which are:

Defer Commitments

The Last Responsible Moment

Pull

When applied to real world projects all three of these turn out to be guidance rather than solid principles. Whilst they are generally true, Lean Software Development offers little or no explanation how to apply these. In effect, none of these terms are defined, and as such they become axioms or underlying assumptions of Lean Software Development. Once you hit these terms, you have to choose whether to accept or reject Lean.

It is our believe that by applying real options thinking to Lean the results improve. Let’s compare the Lean Principles to the real option rules.

Defer Commitments

“Defer Commitments” is a directive that commitments should be deferred to the “Last Responsible Moment”.  Real options says something similar (“Never commit early unless you know why”) except that you can make a commitment earlier if you have the information you need to make that commitment. Although not significant, it is an improvement over “Defer Commitment” because it directs us to find information that allows us to make commitments early. Making commitments early can make things much simpler as we do not have to carry unnecessary options and provide us with much needed information.

Last Responsible Moment (LRM)

One of the more significant differences between Lean Software Development and real options is that Lean talks about the “Last Responsible Moment” whereas real options talk about “Options expire”.  The “LRM” would seem to be self evident. Lean proponents will talk about the “Optimal Point” to make a commitment. “Options expire” means that after a certain point, a way of achieving a goal ( or option ) is no longer available, it expires, or dies. It is determined by a clearly defined process.

The problem with “LRM” is that when asking someone to defer a commitment, asking them to simply “defer the commitment” to the “Last responsible moment” leaves them with a lot of uncertainty and very little control.

To be able to properly use the option expiry, start with the goal and work back to determine the point at which commitments must be made. Any later than that you no longer need to bother because that option is gone. In addition, the real option process will normally identify the “Option Expiry” for a number of ways of achieving the goal. As such it determines the last responsible momentSSSSSSS (plural).

In real options, we specify the conditions at which the commitment should be made. This reduces the uncertainty and allows the decision maker more control over the commitment process.

Pull

One of the fundamental principles of Lean is “Pull” is better than “Push”.  Real options by comparison say “Never commit early unless you know why.” This means do not commit unless you have the information you need to commit. This is similar to “Pull” but this more relaxed form is more useful for understanding and informing the information arrival processes such as analysis and design.

Business analysis actually involves injecting or “pushing” information into a system. To smooth the flow. It is a shared responsibility of the business analysts and architects to reduce the number of options available in the system.

Pull in manufacturing

Consider a car plant that has no work in progress. It is silent, with the operators ready to react to a request or “Kanban” token. A customer walks to the “Out” door of the factory and requests a car of a certain specification ( A Red, Five Door A360 with a 1800cc engine and Alloy Wheels ) from a limited and defined set of choices.

This request generates requests for a body, an engine and 5 wheels. Each of 5 wheel requests generates requests for a wheel rim  and a tyre. Similar the request for a body and an engine  generate further requests until the requests hit the “In” doors of the factory where they generate requests to upstream members of the value stream.
It is as if the customer by pulling his token is able to pull all the raw materials from the ground through steel foundries and mills, through the component manufacturers and finally the car factory until he receives an assembled car.

Yes, the car is “pulled” from the value stream, but in order to do this, the information or requests need to be “pushed” or injected first. The choice when and how you pull a car is limited. The available options are chosen during the design phase. The manufacturing process is designed up front and then gradually optimised using continuous and dis-continuous process improvement.

Pull in software development

We all know that software development is different.

If we extend the car factory metaphor to software development. The customer walks to “Out” door of our factory and asks for a “Door Handle”. From there, someone in the factory has to help them discover what they really want. The customer says they want to get to work quickly. Sometimes we send them away to buy a bus ticket/travel card, other times they need something more. They want a car to travel across a muddy plane very fast being able to carry their entire inventory without ruining the environment and it should be easy to park in a city. We design a tractor with the performance of a Ferrari and capacity of a 124 wheeler lorry and fuel consumption of family car that fits in a parking space just large enough for a smart car.

Once we know what is required, we need to design it. We have to design a new kind of engine and a new kind of body. Now that we have injected all these features, we can design the process to deliver them, break the work down into manageable tasks. We may defer some features. From that, we can pull those features into a final product like they would to manufacture a car.

This is the part of the process where information needs to be pushed onto the system. A manufacturing system already has these constraints (physical dimensions, regulations, etc). Software development is about creating new things and are almost boundless. In order to be able to produce anything limits have to be placed on the system. The limits have to custom fit the current assignment. These limits is the push of information.

Everybody agrees software development is more akin to product design that product manufacturing. The main part of manufacturing is creating a product where “pull” dominates. The product design element of manufacturing is initially “push” based. Hence the need to upgrade Lean from “Pull” to “Never commit early unless you know why.”

Conclusion

Lean is about creating learning organizations. Having applied Lean principles to the field of software development we have experienced that these principles apply to software development differently than they do in manufacturing or new product design.

In search of better ways to do things we applied real options to what lean had already created and believed to have achieved more success.  What we offer here is a possible upgrade of Lean for practitioners which may work in your environment too. Use it and learn from it.

The conclusions we have drawn from our experiences may be wrong, we believe they are valid as they are based on real world experience. We share them so we and others can learn from them.

In closing we’d like to freely quote Adam Savage, host of Mythbusters: “We do not stand by our conclusions, we stand by our methods.”

I have two small children who live in a party rich area where the preference is to have a party at a venue rather than risk having your house trashed. This means I have had the opportunity to observe parties run by people who do so on a very regular basis.

Rather than a chaotic, ordered or complex system, the parties I’ve observed are a managed mixture of all three.

There is a four part pattern to most parties.

1. Constrained Chaos.
2. Ordered System.
3. Ordered food and ritual.
4. “Unconstrained” Chaos.

Constrained Chaos

Most parties start with constrained chaos. The children are allowed to play chaotically in a constrained environment. Behaviour like hurting others are reactively managed but the environment tends to provide the limits. In the early days this will be a soft play area and in later years an enclosed field for football or a swimming pool. The key to these constrained areas are easily controlled access points as the perceived risk to the system is unauthorised persons gaining access to the children. Within the constraints, the children can play as they chose, it is constrained chaos. This allows the children to arrive at staggered times without affecting play and also expend as much amount of energy as they chose. There are no rules. Attractors (footballs, water pistol) cause flocking (complex) behaviour.

These would be the boundaries that Dave mentions except that they are hard boundaries.

Ordered System

After a period of time a play coordinator will engage the group of children in a structured activity. This activity will generally take the children from a high energy state to a calm state. This could be “pass the parcel”, “pin the tail on the banker”, “stroke a farm animal”, “play with a parachute”, “painting” or “creative making”. What is common to these activities is that they are coordinated requiring all participants to act collaboratively (parachute) or in sequence (“Pass the parcel”, “Pin the tail”, “Stroke the animal”) or in a fixed place (“painting”, “creative making”). The system of children is effectively ordered during this stage.

Ordered Food and Ritual

The play coordinator leads to the children to an eating space where the children eat a party meal. The children are fairly calm at this point following the activity. After the meal, there is the ritual of the birthday cake and the party bags. By now most parents have started to turn up to collect their children.

Constrained/Unconstrained Chaos

At this point, the play coordinators release the children into the constrained soft play area or to run around a space. After the children have eaten food, it is in interest of the parent to arrive on time to prevent the child running around too much so that they do not up-chuck on the back seat of the new Chelsea Tractor. This means most parents turn up just before the end of the party and make sure energy levels do not rise too high.

I think the parties I observed are different to the Parties Dave mentions in the video.  I think Dave is referring to house parties that a parent organises themselves rather than a Party venue. The difference between the two is that Party Venues have a lot of (Tacit) knowledge about how to structure parties whereas a parent runs a few one-shot experiments. The first few Party Venue parties run were probably experimental, but it is likely the owner studied other venues first. After a while, a pattern for successful parties emerges. Party venues start by creating complex systems using constraints and attractors. They then create ordered systems using strict rules and rituals. Finally, they train parents to turn up on time. Parties are ordered chaos or chaordic systems.

Limits, Boundaries and Constraints

I am unfamiliar with the precise definition of the technical term Boundaries that Dave uses. His use indicates to me that soft boundaries are what I call limits and hard boundaries are what I call constraints.

After Agile 2009 I was lucky enough to spend a morning with Mike Sutton and Lasse Koskela on a Segway Tour of Chicago. The first few minutes of the tour involve training which included for me finding out the limits of the system. I got to feel what the limits felt like and how the Segway behaved if I pushed past the limits. The behaviour of the system changed but in a predictable way. The behaviour on both sides of the limits was different. Not only that, there was a gradual change. As another example, consider a speed limit. Stay below the limit and you’ll never see much of the speed limit system. Go above the limit and the system sends you fines (if you are caught). However the you are not prevented from going above the limit which may be necessary in certain situations.

I went to visit Ola Ellnestam in Stockholm. My bank balance had dropped below my limit and LloydsTSB refused to allow me access to any cash. It was a constraint rather than a limit. There was a hard transition between the two states.

Limits are things we can chose to ignore although the behaviour of the system changes. Constraints are imposed upon us and we have no choice.

Party venues use a mixture of limits (soft boundaries) and constraints (hard boundaries).

I tend to think of limits as rules which may be abided by and constraints as imposed regardless. I am aware that my thinking is not too clear in this space.

An interesting area of thought is the affect of time on limits and constraints. Not just time, but also learning which is what we really mean by time.

Happy Noo Yar

Chris

I (Chris)  do not often write blog posts these days. I see them as announcements rather than an invitation to a conversation. I prefer the interactive discussion of e:mail groups, or internet magazines like infoq or agile journal which act as on-line conferences.

That said, I feel compelled to announce a new initiative that Eric Willike, Liz Keogh and Jean Tabeka have started called “A Community of Thinkers.”  They first posted their blogs a couple of days ago which can be found here, here and here.

The text is included here with a small adaptation:

I am a member of a community of thinkers.

I believe that communities exist as homes for professionals to learn, teach, and reflect on their work.

I challenge each community in the software industry to:

• reflect and honor the practitioners who make its existence possible;
• provide an excellent experience for its members;
• support the excellent experience its members provide for their clients and colleagues in all aspects of their professional interactions;
• exemplify, as a body, the professional and humane behavior of its members;
• engage and collaborate within and across communities through respectful exploration of diverse and divergent insights;
• embrace newcomers to the community openly and to celebrate ongoing journeys; and thrive on the sustained health of the community and its members through continual reflection and improvement.
• ensure members promote who has influenced them and their perception of the current leaders to prevent any single member becoming a bottleneck to learning.

I believe that leaders in each community have a responsibility to
exhibit these behaviors, and that people who exhibit these behaviors will become leaders.

I am a member of a community of thinkers. If I should happen to be a catalyst more than others, I consider that a tribute to those who have inspired me.

Based upon ”A community of thinkers” by Liz Keogh, Jean Tabaka and Eric Willeke is licensed under a Creative Commons Attribution-Share Alike 3.0 License.

When Liz made me aware of its existence I added an extra behaviour of my own.

“Ensure members promote who has influenced them and their perception of the current leaders to prevent any single member them becoming a bottleneck to learning.”

Many of the professional bodies or communities in the software industry are meant to be learning communities. Often an individual or small group of individuals will come up with a new idea or way of doing things. This inspires a new community to form around the idea. The original group become the “leaders” of that community. New members of the community rapidly overtake the ”leaders” in understanding the material, they adapt or modify it to suit their needs. In effect, they become the new leaders of understanding. Being a “leader” in a learning community does not convey any authority or power over the members of that community. It simply means that people outside of the community are more likely to listen to your opinion over that of the true leaders of the community. This has significant commercial implications…. It also causes the resentment of the true leaders of the community, especially if the leader no longer represents the views of the community. The “leaders” continue to present their own material, ignoring the advancements of the community. Others adopt the orthodoxy of the “leadership” for their personal reasons denouncing those most likely to steal their commercial success,  this inevitably leads “The peoples front of Judea” and “The Judean people’s front”. Only the Romans benefit. The “leaders” of the new community often fall victim to the same thinking of their predecessors.

This is why I think “A community of Thinkers” is so important.

Like many in Agile I studied David Anderson’s work on Theory of Constraints, And Mary Poppendieck’s Lean Software Development, and Kent Beck’s Extreme Programming. I still had problems. I looked for other sources of inspiration and tripped over Real Options (which are mentioned in both Kent and Mary’s books). I was motivated to continue my investigation of Real Options by a casual encouragement by Alistair Cockburn (said the Scottish way). When David Anderson presented Kanban at Agile 2007 I saw I worked in a very similar way. Unlike those who inspired me, I am a practitioner. Agile/Lean/Kanban is secondary to me. My job is to delivery business value and these communities provided tools that helped me do it. As a practitioner I discovered problem that I need to solve. I feed these solutions back to the communities. I AM NOT A LEADER AND I RESIST THE NOTION OF BEING ONE.  I would like to think I am a member of ”a community of thinkers”. AND I would like to be respected for the contribution I make to those communities. I would like that community to respect me enough to keep giving me new ideas rather than insist I subscribe to an orthodoxy. I would like the “leaders” of those communities to work with all members of the community. To work with practitioners who are looking to move the community forward as well as newbies who want to pay them money for entry. I like the Kanban community because I feel they are doing a good job of doing that. They exhibit leadership with an absence of leaders.

So what is the difference between Leaders and Leadership?

A leader feels like a commitment (something we only like if we have to):
“Do it this way if you want to be part of my club.”,
“My way or the highway”,
“You’re either with us or against us”

Leadership feels like an option (this is what we like as it allows freedom of choice):
“Here is a way you can do it, it worked for me in a certain context.”,
“You might want to check out X it seems related to what you’re doing.”

Practitioners are always going to gravitate toward leadership. Salesmen will gravitate toward Leaders. I feel the best way I can help others learn is make them aware of my influences.

I used to call this “Followship”. I was very fortunate to encounter Steve “Doc” List who pointed out that what I described was actually “Leadership”. Thank you Steve.

Under creative commons license. blah, blah, See Eric’s post for details.

By Chris Matts and Olav Maassen

No permission is needed to copy, distribute, or modify the content of this site.

Terms and Conditions for Copying, Distribution and Modification

0. Do whatever you like.

Credit and payment

While you are under no obligation to do so, we would appreciate it if you give us credit for any work of us that you use, and ideally, link back to the original. If you feel like spreading a copy of this content you may do so without payment.

Inspired by Leo Babauta of zenhabits.