Evangelizing Scrum, or Anything, is Hard

Ever since I discovered lean/agile, I've been very perplexed about something. Why do so many people feel passionate, and sometimes offended, when I introduce it? Seriously, offended. Like I just called their baby ugly. I was taken-aback at first, now I'm used to it. I think I've learned to dodge most of the stones that people throw over the years.

Lean/agile begins with principles, with practices emerging from these principles (see previous blog post about agile principles).

I think a lot of blame (yes, I'm pointing fingers) comes from people who don't understand agile, then implement it...POORLY. I've heard so many horror stories about failed Scrum or Extreme Programming implementations. I've taught quite a few classes about agile/lean methods, and in every course, I ask the students if they've been involved in some kind of agile implementation. For everyone that said they had been involved, they said that it sucked...100% of the time. As they expanded on the sucky-ness, I just cringed. The leaders of the implementation just didn't get it. They didn't understand that it's about principles, not about index cards and stand-ups.

Now, let me relate this religion. I've been a Christian for close to 20 years. Every time I get into any kind of conversation (which I rarely start), people immediately become offended. Why? Because like the poorly executed agile implementations, there are many poorly executed "Christian" implementations.

As humans, it is so much easier to just follow rules than to rely on our own judgement. That's why empowerment is rejected so many times at the lowest level. If someone is empowered, then they are also accountable. Who wants THAT??

Christianity is not about rules. If anyone tells you that, then they need to go to Christianity 101 class. Christianity is about a relationship, and principles. If you follow the principles, the "practices" will follow.

Let's look at the greatest principles (commandments) given by Jesus "Love God with all your heart, soul, and mind", then "Love your neighbor as yourself".

What's interesting, is that if you take these to heart, then the 10 commandments (don't lie, murder, steal, etc.) will follow...right? The greatest principles will naturally manifest themselves in the 10 commandments.

If a Christian truly loved their neighbors as themselves, I think you would see a lot more philanthropy and a welcoming attitude towards others.

Here's the intro into the song "What if I Stumble" by DC Talk that summarizes my point beautifully:

The greatest single cause of atheism in the world today is Christians who acknowledge Jesus with their lips then walk out the door and deny him by their lifestyle. That is what an unbelieving world simply finds unbelievable.

Since in general, the "implementation" of Christianity has ignored the primary principles, the understanding from the non-Christian population is that Christians are ignorant, stupid, hypocritical, judgmental, and hateful. Are Christians doing anything to change this image? Not really.

So, when "evangelizing" given this climate, people become hostile and have a desire to throw (verbal) stones.

Now, back to agile/lean. Generally speaking, many folks believe agile is nothing but cowboy coding, no documentation, speed not quality, and screw "the business". When "evangelizing" given this climate, people become hostile and have a desire to throw (verbal) stones.

Evangelizing anything that is based on principles stirs emotion and is fraught with mis-understandings. Typically our first instinct is to run from the conflict that arises and just become complacent and accepting of dysfunction and misunderstanding. We need to be brave, and stand by our principles. In doing so, we need to continue to come up with ways to communicate the truth.

Talent is More Important than Tenure

Honestly...these are two different things.  They are unrelated.  First, I suppose definitions are in order.  I'm "tweaking" the standard dictionary definitions, by the way.

Tenure - Status gained by someone in a particular profession or discipline purely by practicing that profession or discipline for an extended period of time.

Talent - The ability to consistently deliver high quality results, continuously improve, lead, and maintain strong, healthy relationships through open and honest communication.

Whew, that was tough!

Let me first start with my own experience.

In the mid 90's, I decided to go back to college for computer science. I was 30 and knew nothing about computers. My wife actually had to teach me how to use a mouse. Ahhh, I can still hear her dear, sweet words ... "Double Click!!  NO!! NOT THAT FAST!!!!!".

So here I am, in the computer science graduate program (I had an undergraduate psychology degree) with a bunch of fresh-out-of-high-school computer geeks...and I just learned how to double click. I remember my first computer lab where we were learning C++, and the instructor told us to "open this file on the desktop, select all, copy, and paste in the IDE". Yeah, I had no idea what the hell he was talking about...copy? paste? huh? Someone took pity on me and helped me out. Whew.

Fast forward two years. During those two years, I rarely slept, read everything I could get my hands on, took on web programming side jobs that I was in no way qualified to handle, and ultimately caught up to (and surpassed some of) the fresh-out-of-high-school computer geeks. I loved this stuff. I actually ended up administering those same computer labs where I originally had to have help copying and pasting. I LOVED Linux. I LOVED open source. Heck, I even kinda liked windows stuff back then :-)

Here we are, at the height of the dot-com boom. I saw so many people graduate that I felt had average (at best) software engineering skills getting high paying jobs. I, on the other hand, was still attending classes, living in a two bedroom apartment with my three small kids, and riding my bicycle to campus. I was really, really tired of living on student loans and not being able to afford ANYTHING. So, I decided to see what I could find, even though I didn't have my Master's degree yet. I was a much better programmer and engineer than most people that I knew that graduated after all...this should be EASY!

My resume displayed about one and a half years of "real" work...which was actually a bit exaggerated...but dangit...I KNEW I could take on any programming job!

To my surprise, I couldn't even get my foot in the door. If I did get an interview, it always ended up with "yeah, you just don't have enough experience". ARGHH. I didn't have the tenure, but I knew I had the talent!!

Months went by, and I finally landed a cold fusion programming gig...my first introduction to Dilbert-land. It was a great experience.

Now, fast forward another year. The dot-com bust. I was laid off with about 50 others.

Back to the job hunt. Well, evidently that one additional year of "experience", i.e. "tenure" didn't mean anything. Again, I got the "yeah, you just don't have enough experience".

Finally, I interviewed with someone that for some reason, trusted me. He was looking for talent, and didn't care so much about tenure.

That was an amazing experience. He gave me a chance. It proved to be mutually beneficial for me personally and professionally, and for the company. We were eventually acquired by Intuit, which was another great experience. The funny thing is that Intuit would have NEVER hired me directly since I didn't have the tenure!

Fast forward to present day. I'm currently a manager, responsible for a project management group. One thing that I've found out is that hiring for talent is HARD. Hiring for tenure is EASY. I find myself looking over resumes thinking "wow, they have a bagillion years of experience, they must have talent!".

So, I understand now why those hiring appear to prefer tenure over talent. It's because it's so hard to determine if someone HAS talent before you hire them.

I'm not saying that tenure means "nothing". It does. With NO tenure, success is unlikely. However, focus on talent. A truly talented person will of course have some tenure.

Hiring for talent is hard. Take your time, be creative. Don't assume that just because someone has years and years of "experience" that they are automatically talented...you will regret it if you do.

Agile - It's All About the Principles

I've been talking with a lot of folks lately that claim to have been working with Agile for a long time.  When I talk with them, they boil agile down to a few things such as; delivering faster, iterations, and stand-ups.

What troubles me is that very few people talk about the principles.  I like focus on the principles first, and look at the practices (retrospectives, stand-ups, iterations, etc.) as "how" to bring those principles to the forefront of everyone's mind.

You aren't "doing agile" because you put index cards on a wall, or because you stand up for 15 minutes a day in a meeting, or even if you have iterations.  Practices without focus on the principles will get you nowhere.

As teams inspect and adapt, new practices will emerge.  As these new practices emerge, we need to do our best to make sure they don't impede the agile principles, which are honestly good principles no matter what approach is used.

Just in Time or Just in Case?

A huge form of waste that many people don't talk about are those things that are built "just in case" we might need them some day.

I think that those involved in building a product often times forget that everything that is built costs something.  Nothing is free.  Who's paying for it?  The customer is.  Everything we do must deliver some kind of business value, either by reducing risk, meeting compliance, cutting costs, increasing revenue, etc.

There are certain phrases that I listen for like "it would be cool if...", "someday we  might want to...", etc.  Some tend to want to build to accommodate edge cases that are (many times) so ridiculous that they would never happen.  Now what gets really tricky is when there is only one SME in the product group, and no one else really knows that domain.  In those cases, God help you!  That SME has the power to make you do things that you look back on and say "WHAT HAVE WE DONE?!?!?".  The only way to get around this is to fearlessly and relentlessly ask "why?".  In these situations, there is typically a touch of fear that compels the team to bow down and say "yes master, whatever you wish" instead of asking probing questions.

There are some Scrum Masters (and Project Managers) that typically stay out of those kinds of details.  Yes, the team is self-organizing.  Yes, the team has to learn by making mistakes.  However, the Scrum Master has to be involved enough to not allow the "just in case" methodology from taking hold.  If it's allowed to go on too long, you will have found out that what you have delivered in the end is not what is  valuable now.

Bringing Agile to the Organization

Almost all of the literature out there recommends the first step being finding a "pilot" project where you can use an agile methodology.  The project can't be too complex, too simple, too large, too small, too critical, or too unimportant. 

I'm starting to wonder if we're over-thinking this.  Why don't we decide what to use depending on the project?  If RUP fits REALLY well, then why don't we use that?  If Scrum fits REALLY well, then we should have the option of using that...right? 

In reality, the only thing that will ever hold back a true agile adoption on a project or an organization is the culture.  And, the other reality is that most organizations have a culture that does not support an agile framework.

But, how do we change the culture?  Do we change the process first and hope the culture changes with it?  Or, do we try to change the culture ahead of a process change?

At my current place of employment, agile methodologies are accepted, along with any methodology that makes sense.  There isn't a "corporate" methodology.  I really like that.  Imagine if a company was by-the-book Scrum.  No other options.  Imagine having to beg for permission to "pilot" Kanban...ugh.

My point is this...maybe we should stop the notion of "piloting" Scrum, or Extreme Programming with the intention of rolling it out and making it the "approved" delivery methodology.  Maybe we should instead focus on sound principles that we know are true, universal, and also happen to be highly valued in agile and lean.  Principles such as:

• The primary measure of progress is working software
• Business and IT working together daily
• Face to face communication
• Reducing waste
• Building quality in
• Delivering as fast as possible
• Delivering working software frequently
• Self-organizing teams
• Welcome change
• Sustainable development
• Technical excellence
• Keeping it simple
• Continuously improving the process

 As long as we let these principles drive our process, and people are empowered and allowed to make mistakes which will in turn promote learning, the process will work.