My Overview of Agile Presentation (to a local PMI Chapter)

I was invited to give a talk about Agile to the Delaware Valley PMI Chapter on January 7th. The audience was going to be filled with local PMP's, some of which would be skeptics, and some of which would have been burned by bad agile implementations. I was worried about how to normalize their knowledge, and I had to do it in less than 45 minutes so there was room for Q&A.

Once I realized that I couldn't cram Scrum, XP, Lean training in along with a proven case study... I decided to go for the overview and provide them what they needed to find out more. I wanted the group to understand the Scrum is Agile, but Agile is more than Scrum.

As far as I can tell, the session was a success. I got positive feedback at the end, and I felt I made the most of our time.

If you want to get a copy of the slide deck, you can download it here. Since I'm not that popular of a guy yet, hopefully this won't overwhelm the daily bandwidth limits of my personal website traffic restrictions. If you get nothing, email me or put a comment on this post and try again tomorrow (and I'll have to move it to another host).

Having been through this experience, if there is anyone in the Philadelphia region that is interested in having me come talk about Agile or some specific piece of it... feel free to contact me. You can find many ways to reach me on my personal site.

Before agile came along, life was easier for me...

The problem with Agile is that it helps us realize early that there might be problems. Granted, this gives us time to solve the problems and get the project on track, and it allows us to have a higher success rate.

But I miss the good old days where we happily worked for months until the death march started. It allowed us to stay blissfully happy and then blame management for the last 3 weeks when things went wrong. Some of us would get good at finding long projects where we could work for months on lines of code and then bail on the work and jump to another job or company right before it went into the crapper. Becoming an expert in our skillset was simply about perfecting our selection of projects and timing them well.

Now we actually have to be on top of our game every day! That's a little bit more challenging than I expected. I went and got this computer science degree so that I could sit in a cube and write code and get paid lots of money for it. What's going on here?

Yeah... unless this is the first time you've read my blog, you know how I truly feel!

Read the Cutter Consortium's version of this viewpoint.

Early Kills are an Improvement...

It's been a few days since I read it (so I apologize for the missing reference), but it came up in my mind again today. There was a recent discussion about the definition of 'success' in relation to Forrester's or Gartner's research published about projects. It seems that software projects became more successful as agile adoption hit the mainstream market; but project success metrics have decreased in the last few years with widespread enterprise agile adoption. One side of the debate says it is because Agile doesn't work in complex environments (that's ignorance since I learned about agile in one of the largest most complex global 500 companies). The other side of the debate is focusing on the definition of 'success'.

For example, if you were going to work on your project for 3 years in your old model and then it failed... wouldn't it be an improvement if you realized this way in advance? That's a lot of cost savings. It gets those people on something that they can be excited about sooner. It's less "stuff" to throw in the trash. It's less wasted time.

My point is that I agree with the side of the debate that says Agile can help you be successful by shortening feedback loops and creating transparency ESPECIALLY WHEN it leads to the project failing sooner!

Now, I want to take this a step further. Mike Cottmeyer wrote a great post yesterday about Real Option Theory and how to think about risk management. He reviewed an example where he chose to put a deposit on something to extend the window of time where he could gather more information to make the right decision between 3 options. His points surrounded risk management and how every choice (or non-choice) we make affects the economics of the project.

I took this a step further in my comment:

I think there is another piece to this. Some people make the mistake of looking at the deposit as part of your future decision. For example, option 2 and 3 are even choices, but because we paid the deposit... we should not waste it and choose #2 over #3.

The deposit was a payment to extend time (as you described). Some people forget this and see it as a partial payment of the total cost and can't let go of it.

This is how companies keep projects going that should be killed because "they already spent 12 million dollars on it". My response is, "and you want to waste another million?". Instead they see it as "so close to completed, they can't throw it away."

I was once told that the main rule of an MBA education is you decide what to do moving forward based on costs/profit moving forward, not money already spent.

I encourage you to read Mike's post (he's a much better writer than I) and if anyone knows the reference I mentioned above, place it in a comment and I'll add it to this post for future readers!

Failure condition...

People have beat this topic around for awhile now, and I have seen some interesting content about what will force an agile approach to fail... but I've never seen such a simple boil-down of this topic for both agile and waterfall side-by-side.

Thanks to Udayan for posting this simple chart.

Summary: unstable requirements + unstable team = FAIL!

Joke of the day (not)...

Disclaimer: if you follow the Agile Software Development Blog, then there is nothing new to read in this post. Move along, nothing to see here. If you don't, then read on. (Sometimes my blog posts are to help me find something later.)

I encourage anyone to read the following article and try to convince me that it is a joke. It claims that the #1 best way to get a project back on schedule is to work overtime. Amongst the list of 10 includes "crashing the schedule" and "prevent all scope change". I've read it 3 times across 3 months now and I still think this guy was intending to provide serious advice.

Peter Stevens is also clearly convinced that it is not a joke and made his own list of 10 things to do to get an project back on track using agile patterns. (I'm right there with you Peter!)

But the interesting data point to take away is Jeff Sutherland's mention of the Maxwell curve. It is showing that working less equals more. It implies that once you go agile, you work more intensely, and overtime as an option is out the window.

How's that for work/life balance?

The Agile Salesman...

Many of us find ourselves explaining Agile to others. What's good about it? Why to do it? How it helps?

The problem is that many of us have been burned by waterfall so badly that we take a "waterfall sucks and agile doesn't" approach. Unfortunately this approach doesn't work because it just leaves a bad taste in people's mouths and we then justify it with the concept that you have to experience agile to truly get it.

I've been following Seth Godin lately since he is a master marketing guru and his viewpoint provides insight into how to sell a new idea. Today he wrote a great post about how to pitch a concept. He uses the metaphors of gravity vs. evolution and how quickly these concepts were "sold". Here's a snippet:

Tactic 1: Try to tell a story that complements an existing story rather than calling it out as false.
Tactic 2: Try to make the 'proof' as vivid and immediate as possible. Like an apple falling on your head.

This is why I like Mike Cottmeyer's recent work around bridging the traditional PM's point of view with Agile's (he has a bunch of posts, so keep looking past this recent one if you are interested). Instead of saying waterfall stinks, he explains how agile enhances.

Waterfall is NOT dead...

SmoothProjectManager put up a short post about his disbelief on whether waterfall is dead or dying. You can hear his disgust between the lines about how strongly people are stating that waterfall is dead when, in fact, it is not.

I totally agree. Waterfall is not dead. BUT, those who have experienced successful Agile/Lean approaches have decided that they aren't turning back to waterfall because of their new level of job satisfaction.

Waterfall works well in projects where scope and deadline issues are minimal. The military uses PMI very well to build things like aircraft carriers. But, you also don't see them changing the length of the ship hull by 40 feet in the middle of the project like people change requirements on software projects. Change can't be tolerated in that type of project so the PMI/waterfall approach is very relevant.

A fundamental difference between the two is "fight change" vs. "embrace change".

Agile is growing much quicker than waterfall for many reasons including:
- when done properly... it works, and well
- it handles change much better than waterfall
- it reduces finger pointing which increases morale and job happiness

And unfortunately, it is a well-misunderstood buzzword that is being overused and misapplied (which shouldn't count as growth).

So, neither has won... and neither will conquer the other. As members of the agile community, we have to be careful about what we say to people in the non-agile world about our beliefs. If we come across as evangelists, we may turn people off from even listening to something that they might greatly benefit from.

Anyway, their are still people clinging to OS/2 warp machines somewhere out there... nothing ever dies in the tech community.