Random comments on interesting posts within the agile software development community...

Thursday, November 5, 2009

The "decline" of Agile is our own fault...

I've been thinking about this for weeks. I'm still struggling to verbalize it. I could probably white-board it easily face to face; but I'm forcing myself to blog about it to see if anyone in the community reacts.

I'll start with the triggering thoughts first...

Martin Fowler gave me a new term at Agile East 2009 last week. The term is "Semantic Diffusion". He described this as the current trend of terminology diversity, dilution, and mis-use as agile has grown. He implied that it is the cost of growth and success of the movement.

I had a great conversation with J.B. Rainsberger while he was in Philly that same week. We discussed my thoughts and they intrigued him enough for me to continue pondering.

In the last year, I've had many a peer either complain about random factions in our community, or express a "loss of faith" in the movement at large. Frequently this is triggered by some new certification group or consulting firm charging high rates to "help" a group go agile with the wrong intentions.

I've come to the conclusion that Agile has NOT outlived its worth, its terms, or its time as seem people have started to imply (I refuse to allow Agile to be a dirty word)... instead, we are doing a bad job in the community at sustaining its applied success.

Now to the core of my point... I summarize it all right now!

By raising the issue of Semantic Diffusion, are we calling out an issue that needs to be guided more pro-actively? Or are we using this as an excuse to accept "the inevitable"? Are we doing anything to cause this problem to grow?

I'm going to state right now that I think we are. We need to stop looking outward for the cause and instead reflect inward.

When I started in the agile community, I worked with several great coaches. These were individuals who had proven experience in Scrum, XP, and other practices. They were "journeymen" with an interest in showing others how to do it. They insured that I learned how to do it correctly. I wasn't on the internet reading and learning about it, I had hands on coaching. Thus, I came up to speed quickly and I had a very positive, thorough, successful experience.

When I think of anyone entering our community, I hope they might learn through this same type of experience. Unfortunately, I believe the opposite is happening more often than not. Why?

Well, where are those agile innovators and early adopters now? Many of those folks have worked in agile for so long that it is easy for them to take these practices for granted. Their Ri level experiences have allowed them to forget the Shu level needs. They've moved on to much bigger problems like Enterprise, Off-Shore, and whole system optimization. These are good problems to solve, but you have to teach several coaches to replace you!

I also hypothesize that every new "generation" in the community learns at a quicker rate. There are more resources available, more lessons documented, more case studies published. If you take the right path, it is easier to get up to speed than in the early days. With this, people more quickly become successful (or not) and the gap between the Shu and Ri level groups becomes wider. When I entered the community, I could work with the Ha level group; but this group is a smaller percentage of the whole now.

When I went to the Agile 2007 conference in Washington D.C. (my first), I quickly learned that I was a Ha level user. As many people were asking me for insight into my experiences as I could find people to ask about theirs. It seemed that there were a small group of people that were innovating, and the rest were split evenly between learning and using. Now I feel as though (based on the community at large), the Shu level group greatly outnumbers the Ri level group due to market hype. The Ri level group is looking forward to innovate and there is not enough Ha level people to support the Shu group. I commonly find myself talking to a Shu level person asking about agile that doesn't know about the manifesto and haven't heard of the many important names or bodies of work in our community. Whoever planted Agile in this person's head didn't do a very good job in my mind.

And here is where the bottom feeders step in! Want to know about agile? Let me re-purpose my old pitches with these new buzzwords and charge you money to learn about something the wrong way. Everybody is talking about it, and you can't find anyone to help... so I'm the best you've got. Slap a few acronyms on your resume and hand you a certificate on the way out and you'll be dying to hand me $1500 to keep up with your peers.

So... if you've been doing agile for over 3 years and you've been successful at it, what are you doing to help the community? Are you bringing your experiences to folks and sharing them? Do you venture into communities where there are people at a different level than you? Do you explain what worked for you, or do you tell them how their approach is wrong? Do you throw the book at people and shake your head, or do you wrap your arm around them and bring them into the circle? Are you too focused on innovating to see who we are leaving behind? Do you focus on everything a person is doing wrong, or do you help them find something to do right? Do they see the benefits after they've tried it, or do they just follow this new set of procedures you've described?

Why does this matter? Because unless you are going to spend the rest of your career working with the same people, you may someday be working with one of these poor lost souls who has been taught everything wrong. You may take a job with a great agile company to only find out that the leadership has it all wrong and make your life one living hell. If you don't want to argue about what agile really means in five years, or have to invent a whole new set of words for the same things that we lost to "semantic diffusion"... then we have to start working on that now. I'm not talking about holding down our turf and fighting every idiot that says stupid things. I'm talking about leading by example, sharing information, proving success, and helping others. These are the same ideals that started the agile movement in the first place.

If everyone is learning faster and the gap between Shu and Ri is getting larger, then we can't expect the people behind us to train everyone that is entering the community. We have to still spend some small amount of time continuing to mentor the people catching up to us. Somewhere in that talent pool is the next Gordon Pask Award winner.

And this is why I started blogging; I wanted to pass along the knowledge that people have passed me. I have now spent a year learning by blogging and sharing by tweeting. I continue to share through Twitter and LinkedIn conversations, but I've been forced to cut back on the blogging due to the recent addition in my family. I'm asking all of you to consider these points and not forget that not long ago, you were also new to agile. People need guidance on how to start with agile, and we shouldn't allow them to be led astray by the snake charmers and other bottom feeders latching on to our community. It is in our best interest to reach back and pull people up with us as we continue to grow. That's my challenge to you!

Semantic Diffusion is a disease that should be fought during the normal lifecycle of a movement. It is a rallying cry for continued guidance and debate with the newest members of our community to insure the tribe moves in a common direction. Do not try to control the community and define it, just get involved enough to make sure you provide opportunities for people to learn from your experiences.

Note: just to be clear, I am not stating that certain people have left their posts. Everyone still hears the voices Fowler, Martin, Poppendieck, etc. I'm saying that as the numbers grow, many more voices need to be added to this core set.

10 comments:

Great post Kevin. I'm fortunate to be one of the lucky that get to help companies adopt agile at the very basic levels, help them find out what works for them, and then transition in someone new to keep the momentum going.

As you point out, there are a lot of Shu level folks out there that need help, and there are a lot of materials they use for a DIY approach. Ultimately though I find they still need someone to come in and help them at the most basic levels. Unfortunately a lot of consultants do charge a huge amount of money to help, and that's a problem. However that is one way of doing things.

We are fortunate in the agile community to have people like Mike Cohn writing books on their experiences of what can help/hinder agile, and companies like Rally are doing a good amount of blogging and I see some video. And while books, blogs, videos, and other digital medium are great for getting the information, it's the hands-on that works best to pass on the lessons.

Good comments. I am very supportive of people making money off of agile (I hope I didn't imply otherwise). I have a full time job applying agile concepts within my organization. In the past, I've talked to companies about being an agile coach for them, and sometimes they need consultants to jumpstart them more than a full-time person like me (after all, that's how I learned from ObjectMentor!).

Hands on coaching and practice sharing (paid or not) is a necessary component to finding true solutions. When people talk about "Semantic Diffusion" or "agile as a buzzword"... I'm starting to believe that this is caused by people who seem to be less focused on the outcome and more focused on their own profitability.

Hey Kevin, I didn't think you were disparaging people that make a living off of Agile consulting. I fully agree with you though that hands-on coaching is what is needed. I would add to that that hands-on coaching needs to take more than a day or even a week. What Agile typically does is change the way people work and how they approach projects from every facet. Implementing that change takes time.

Great post Kevin! As a Federal employee coaching folks along in Agile (which restricts me to helping one group - where ever iam working, which happens to be EPA), I find that we need to multiply the numbers out there providing assistance. The levels you are talking about is akin to the loss of the middle class in a society. If there are only rich and poor, society is in trouble. We need that middle level to make for a stable Agile community. As more people enter the community at the bottom (akin to the poor), we need more middle class folks helping to pull them up. There are lot of ways ot be active; join in!

Kevin, you make some excellent points. I also think you produced some unintentional irony: I believe that using terms like "Shu," "Ha," and "Ri" is a good way to turn off people who want to understand the basics. I, at least, tend to see those as a kind of elitist terminology, which separates "us" (the experts) from "them" (the beginners).

I don't think you are being elitist at all, but I often do get the sense of elitism from the writings of many Scrum experts. Sometimes I have the urge to grab them (metaphorically) and say, "It's not about mastering a Japanese martial art! It's about practical and efficient ways to conduct software development.

I'd much rather focus on why Scrum works, and show people how to do it, than talk philosophy. Philosophy has its place, but it's easy to overdo.

I understand your point, and it is good feedback. But, keep in mind that this post was specifically targeted at those who are past the basics.

Metaphors are tools by which we explain concepts. The Shu/Ha/Ri concept is not intended to create elitism (I know that was not Alistair's intention since I've heard him speak on it firsthand)... instead is it about helping one person understand the best way to convey new ideas to another.

For example, I can show my child how to ride a bike... but I'm probably going to put training wheels on it before he gets on. I don't see this as elitist, I see this as the best way to gain trust and build courage (a necessary part of agile teams).

We have been working at agile for over 6 years. I mention "working at" because it is evolving constantly and for many people, is not a 'common sense' way of thinking. Evolving also involves having the infrastructure in place to support and agile world - unit tests, quality code (FindBugs, etc). Furthermore, fostering and growing the intangible items like team spirit, cohesiveness, morale, focus and encouraged participation can be an involving chore on its own.

Now, In a world of "Immediate Gratification", it is difficult to ask a stakeholder for time to grow these areas without producing direct revenue-generating pieces of functionality.

Then asking management to not be as heavy handed in their practices and to step back can intimidate them and their feeling of worth. Some will fight it instead of seizing the time to really bring value by looking forward.

Additionally, I've seen the groups where leadership wants to implement an agile evironment because they hear good things about increased productivity.However, when they dont have the perfect results in 3 months, they abandon ship after they have pushed for agile to perform in an unnatural way. The scars have been left and will be spread around.

The training I totally agree with as well - the quality seems to be incomplete. I hear of another group 'working agile' but have absolutlely no structure. It is not longer "controlled chaos" but complete chaos with varying teams, varying iteration lengths, planning that is always superceded by 'emergency requests', etc.Training is just the beginning. Teams will need constant coaching as they evolve. If teams do a retrospectives each sprint (or some recurring time frame), you'll see that agile is an EXPERIENCE, not just training.

Taking those above scenarios (and i'm sure many others) and mixing in the insufficient training that seems to be popping up everywhere, and you have many elements working in concert against agile's TRUE adaptation and appreciation.