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.

We don't want you (yet)...

The Agile Community doesn't need more people who want to "go Agile"; it needs more people to successfully "be Agile".

I guess this is a follow-up point to my earlier post. We need to stop recruiting and start teaching.

Feed a man fish and he'll be hungry tomorrow. Show a man to fish, he'll feed himself.
Teach a man to teach others to fish, everyone will eventually feed themselves.

.... or something like that.

If you are an organization that makes money getting people to drool over agile and obtain certifications or take classes, but then your students can't successfully do agile... you are a parasite.

If you are an organization that makes money getting people to drool over agile and obtain certifications or take classes, and then your students successfully do agile... you are a teacher.

Subtle difference... are you a teacher or a parasite?
History speaks for itself. Go back and see what people have done in your wake!

The Thumbtack and Hole Metrics...

Sometimes metrics can just appear in front of you very simplistically without any effort. I've discovered two new ones which I call the Thumbtack Metric and the Hole Metric.

The back story is that we use a corkboard to track our work. This is a high level view of the biggest priorities in VersionOne, our legacy ticket system, and any other queues of work we have. Because our one team supports all company operations AND does new product development, we have a hybrid balance of many different approaches. The board is our central view.

I attempted to force WIP limits onto the board so that it was a true Kanban board, but this simply didn't work in our environment for multiple reasons (nature of our work along with company culture). BUT, it has been very interesting for the team to start realizing when they are attempting to do too much. As the coach, this was something I used to pro-actively point out, but I'm learning that it is better for me to be reactive so that the team themselves can learn from experience. (Unfortunately, a child understands "hot" much better after being burned.)

This maturity and growth has led to many great conversations on the team. They start as individual discussions of philosophy between me and someone on the team, and then they become team discussions where we improve something in our process.

Through all of this, I've noticed a few things that the team now sees after it has been pointed out:

1. A problem item typically has many thumbtack holes in it (The Hole Metric). The "holier" the item, the more of a problem it is. What is the causation behind this correlation? Well, every week we scrub the board. Every few days rows get re-aligned. If an item is picked up on one day and finished the next... it has one or two holes in it. But if the item gets pushed around for days and lost under other stickies... then it get punched A LOT! So... we now have a metric that can be used to identify areas of improvement. When a "holy" item reaches DONE, it is a good topic for a quick review/mini-retrospective.
2. Every item on the board needs a thumbtack. We thumbtack stickies so that they don't get blown off while moving the board around (our board sits in a central visible area of the company and is carried into our dedicated standup meeting room every morning). Sometimes we group things with one thumbtack, but in general, there is a correlation between the amount of work on the board and the number of thumbtacks used. I haven't been successful at imposing WIP, but I have been successful in showing that when we run out of thumbtacks, we are in for trouble. This is the Thumbtack Metric. If you need more thumbtacks to stick things onto the board, you have a problem coming (or are already knee deep in it). Conversely, the CEO notices that too many unused thumbtacks might be a sign of available capacity (so I take thumbtacks off the board at times if needed ).
   

See... all those documents, white papers, conference sessions, etc you've read about metrics... they were overkill. There are simple metrics right in front of your team every day. AND, they are much easier to sell, explain, and use as an indicator moving forward.

So... what's your thumbtack metric?

Agile vs. Traditional Projects... which costs more?

Another great debate in the LinkedIn Agile Alliance forum... quite a few responses and viewpoints!

The original poster asked the following:

Should Agile Projects cost more/less than waterfall projects?

and the answers varied greatly!

The following focused on whether this was a valid question:

Proving an Agile project is less costly is not easy because your attempting to compare an alternative history -- Clay Nelson

...if we ever start to sell Agile as a way to lower costs then we just invite a a backlash against Agile -- David Nessl

And others attempted to answer it:

Agile does not aim to be a low-cost alternative. Some seem to believe so, but the aim is agility: Speed and flexibility. We become agile to shorten time to market, to increase adaptability and reap greater ROI over the lifetime of a product, to name a few reasons. -- Marcus Widerberg

Agile should cost less for several reasons, among which are: Your mistakes cost less... Earlier opportunities to start getting ROI... Failing early vs Failing late... -- Chuck van der Linden

And of course... my answer:

Most companies do a horrible job of measuring the quality and defect costs that start during the integration/testing/stabilization phases running all the way through support. All companies do a horrible job of measuring technical debt.

If agile reduces these up front, then overall Agile is cheaper from an end-to-end perspective.

But since nobody knows or tracks the cost of these things, Agile (which takes more effort/work to be successful at) will look more expensive on paper.

Tech Example: I can write code without automated tests in half the time, but what will it cost later?

Business Example: I can plan and design everything now, but what will be the cost of unknowns and market changes later when I can't handle it?

Oh, by the way, Forrester Research did a partner study with Thoughtworks... "Forrester TEI concluded our Agile delivery is 40% less expensive overall". - from a Ross Pettit presentation @ Agile East 2009

What if Congress used Agile?

Eric Camulli posted this interesting question in the Agile Alliance LinkedIn group:

Could Agile help Congress with healthcare reform? I'd like to see someone take a stab at applying scrum principles to the "great development project" of our day...

Our country's healthcare "project" could end up looking like many Waterfall projects...not on time, over budget and not meeting customer's needs in the end.

Unfortunately the conversation quickly started to veer off into moral, ethical, and political opinions/viewpoints/jokes unrelated to agile...

But I thought about this a little bit and I did find some comparisons between our legislative system and large companies that aren't agile. Here is what I ended up writing:

I think the real problem with anything going through Congress is that they don't "go to the gemba". They rely too much on research and lobbyists to translate the needs of the "customer" for them.

Congressman act as if they are Product Owners, but they don't have the domain knowledge or "end user" interaction to truly own that role.

So... I guess my solution is that we need to find a way to decrease the feedback loop distance between those affected by policy and those creating it.

Does anyone else have any ideas or insight into this one?

Individual Recognition on a Scrum team

Hmmm... another conversation in the Agile Alliance LinkedIn group. Here was the question:

Should we have an individual recognition award in a SCRUM team? Lots of people says that individual award is against an Agile methodology. Award should be given to a team not to a individual team member.

I tried to play a passive role and stated the following:

I have seen these conversations occur many times in many forums and the end of the conversation always results in a "NO" with a very good list of reasons. The risks outweigh the rewards no matter how you set it up.

There is a gray area of disagreement on whether the team can spontaneously award a peer or not. But the minute you make it a regular event, it wanders back into the problem area.

The best reward is taking a respected peer out for coffee/beer and telling them you appreciate their contributions, or saying in front of the team what good they've done. This doesn't need to be organized.

And the first few responses before mine were in line with this:

If you want to have a well jelled team - absolutely not.
The only exception I can think of is if the team requests it.
But that sets up a conflict of interest. - Jay Conne

The only time an individual award is appropriate is if the team wants to acknowledge an individual who has made a significant contribution that made a big difference TO and FOR THE TEAM. - Shane Hastie

But then we got the extremist viewpoint thrown in:

The Communists tried the concept of Co-Operative farming. Under that framework, no individual was supposed to be better than the rest. Needless to say, the concept didn't work out.

So I found myself having to take a stance and state the following:

Here's the best way to summarize what I'm insinuating/feel:

If an award is financially valuable... and it is regular (creating a sense of expectation), then it has a higher probability of creating individual behaviors over team behaviors unless your team remains constantly aligned to itself (resources typically fluctuate too much for this to be assumed).

If a reward is simply a show of appreciation and a call to what behaviors or achievements the team should continue to grow and repeat, then this has a higher probability of creating a collective and positive team behavior, especially if it is unexpected (not scheduled), and driven by the team.

Feel free to include your own thoughts in the comments, but I have to say that I'm not very open to debate on this one.

What is Iteration Zero?

Someone asked a very interesting question in the Agile Alliance LinkedIn group. Discussions about iteration zero have come up before, but this one was specifically focused on the situation where the architecture was not well understood.

In case you are new to Agile or Scrum, iteration zero is the term for that first sprint where you know you won't be delivering software that is adding value for the customer. It's the "let's-get-our-ducks-in-a-row-so-we-don't-bomb-the-first-sprint" sprint.

Many people use sprint zero when they transition to agile for converting their project plan into a backlog and seting up the environments needed for CI and other XP practices. Some use it to kick off a project and understand the underlying system being built on top of.

In this discussion though, it got me to thinking about a past project where we were starting from scratch. We had nothing, and we had never developed in this technology before. So, what to do?

Remember, a sprint should always have an outcome or goal. And, it should always be demonstrable! The original poster asked about unknown architecture, common impediments, and differences to non-agile projects. Here's what I contributed to the forum:

Iteration 0 should result in a compiled installable "Hello World!" system (example: user shall be able to login and logout). Common impediments are purchase, license, hardware, network, and system related.

In an ad hoc PM practice (or traditional), there would be a huge "balloon payment" (to borrow from technical debt metaphors) at the end of the project to take this built system and install it in the real world. Iteration 0 is a way of beating this problem up front and then refactoring along the way as you learn instead of having to rebuild based on the mistakes uncovered at the end during "stabilization".

What do you think?