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.

A further experiment in ScrumBan…

I’ve recently evolved my company process to include WIP limits, but before I share this story, I must first provide the following background.

When I started at this company 2.5 years ago, there was a large divide. I was trained in PMI, was a CSM, and I was a staunch advocate of XP/Scrum by the book. On the other side of the divide, the company had little process, little documentation, no source control, and made minimal attempts to plan work a day or two in advance. One could say this was a recipe for disaster, but this is a startup… and the point of hiring me was to improve as they doubled the size of the company.

Several things have happened since then:

• retrospectives and weekly iterations were quickly adopted
• source control is now in place
• we put tools in place to manage our work (VersionOne)
• standups have become common for both teams and projects
• we’ve modified the 3 questions
• we now use a ScrumBan inspired board
• most importantly, I’ve learned that there is more to Agile than Scrum/XP… I’ve become an interested follower/borrower of Lean and Kanban practices. This is an important step for me as a coach since not all environments fit the Scrum/XP model. A mixed bag of tricks helps win the debate, especially when it is gamed against you!

So, what is the new problem of the day? I’ll call it the plan-to-budget problem. I’ve struggled for 2.5 years to find a way to get the company to plan work based on the available capacity. We’ve always had “BUT-we-need-to-do-ALL-of-it”-itis.

I’ve explained velocity and scrum, but this was viewed as too expensive to pursue. “Why should we estimate everything when we only care about certain parts of it meeting a specific deadline?” This is a good point. If only a small portion of our work is deadline driven, and the rest is “do as you can in this order”… then putting time into estimating and projecting everything might lead to waste. (Although this is contradictory to “I-want-all-of-it-by-next-month”-itis.)

Thus, I reduced focus and tried a top5 concept. Hey CEO, pick only 5 things that are important for this week, we’ll do our best with that set before touching other stuff. This worked well for a while since it forced us to admit we can’t get everything done and focused on fewer items. It reduced our “in flight” work… for a while. Two things derailed this approach.

1. The CEO found ways to assign work to people outside the top5 set (most people can’t say no to the CEO/founder when approached).
2. Not all items were the same size (scream together now: ESTIMATE!) so 1 large top5 item could clog the whole pipe.

We let go of this concept and evolved our breakdown further. I was happy to push for smaller stories and quicker closure. Appropriate sizing is a great stress reducer for the team, especially when you involve them in that process. But we slowly returned to our problem of demanding more work than we have capacity for.

This is where I started thinking about Kanban’s WIP limits. After all, this would fit our model well, and we already have the board in place. Unfortunately I knew that this would be bypassed just like the top5 limit. Our problem was a cultural problem, and I had to tackle it at the source.

So, we’ve started a new trial change in our process. After 3 hours of debate, I was able to convince management of the following (meaning they agree with these):

• Giving one person too many things at once will slow down throughput
• Swarming is a good way to get things done faster
• Saying we have to do everything doesn’t mean it will get done
• Not deciding on priority means it will get decided by the people doing the work
• Our biggest issue might be over-committing (actually, over-requesting since nobody was necessarily committing)

The solution? Headshots! I made little headshots of each team member. We plan the queue of work and then prioritize it. Then the CEO points at a card on the board and says “I want that first”. We put 1-N heads on it based on availability, capability, and size of work. The CEO keeps pointing at items until we run out of headshots. If he points at big things, he picks less stuff; if he points to small things, he can pick more (Budgeting to capacity!) When a person frees up, they move to something else on the board. Everyone on the team might have a few things assigned to them in VersionOne, but they KNOW which item is most important (the one with their head on it on the board). Everyone on the team focuses on helping each other finish these items before starting new things. All of this is clearly transparent on the board! It's not rigid like scrum velocity or Kanban column limits, but it is a place to start and a way to prove value (a door to further improvement).

Summary: We aren’t doing true scrum, but some of the pieces. We aren’t doing true Kanban or Lean, but some of the pieces. We aren’t truly self-empowered, self-managed… but somewhat. I would be the first to declare we aren’t “agile” as defined by most in the community. BUT, I’m getting to the point where I believe we have a system that works for us (2.5 years ago, we were a demand-and-control company led by the CEO). It’s a hybrid of many agile approaches, driven by my teaching of agile philosophies, allowing this company of ~70 work better together. Hopefully this new change will help us overcome our capacity/planning issues, only time will tell.

A kindergartener's Kanban board...

Literally, a Kanban board in a kindergarten room. David Anderson pulls through once again with yet another insight into Lean and Kanban.

I've been shifting my "work study" towards Kanban and Lean more and more recently. I'm really starting to like it more than Scrum. This example is amazing since it points out the simplicity of managing resources, availability, needs, etc. It does ignore the flow/process/sequence aspect of managing "real" work, but it is really interesting.

Agile or Lean, which is the bastard child?

I'm kind of tired of these debates since they don't really do more than the Mac vs. PC debates. Who cares which came first? Does coming first confirm value? superiority? inferiority?

Anyway... Mike Alber posted to the Agile Alliance LinkedIn group the following question:

Agile and Lean Software Development - an Oxymoron?
What do you believe - is Agile is an instance of Lean, or together are they are an oxymoron?

My response:

They are both journeys towards the same end goal with slightly different paths. To me it is like asking if driving from Florida to Maine on I-95 vs. Rt 1 is the same or different.

Yes they are different. But they are both going in parallel and towards the same ultimate goal. They even cross and overlap each other quite a bit. It also seems their start was about the same also.

I really like what Matthew Chave had to say:

1 of 2 ways to go here.....

1. Agile - throw your processes away and start again....take Scrum and XP and implement them....

2. Lean - use lean techniques to remove the waste from your process......

What happens if you do 1......well you probably fail as its too much to do in 1 go......

What happens if you do 2.....you gradually improve your process and in the pursuit of "perfection" gradually refine your heavy-wright process to become something that looks a lot like Agile......

Moral of the story (and to quote Martin Fowler on the topic):

"You can't really talk about them being alternatives, if you are doing agile you are doing lean and vice-versa. Agile was always meant as a very broad concept, a core set of values and principles that was shared by processes that look superficially different. You don't do agile or lean you do agile and lean. The only question is how explicitly you use ideas that draw directly from lean manufacturing."

Great stories...

If you haven't seen these great blog posts you should check them out:

Lean Team Software Process by Corey Ladas

snippet: An alternate metaphor for software value is a refined substance, like gasoline or ice cream. The raw material is customer requirements, domain knowledge, time, and energy; and this is transformed into manifest behavior of a computing system. This view suggests that software has no more customer value than the sum of the scenarios that it supports. Then there is no bright line that defines “complete”, there is only relatively more or less value delivered. When I fill up at the gas station, I need more than one gallon and less than 100 gallons, and when the pump tells me I have enough, I expect to pay the exact value of the utility I expect to receive from the product. Software can be delivered in this way: keep giving me more until I have enough, then stop and charge me for what I have consumed.

Metrics, Schmetrics II by Matthew @ Creative Chaos

snippet: All of those examples are fungible - a gallon of gas can be traded for any other gallon of gas. A penny saved is a penny earned. They are all the same.

Yet test cases, lines of code, these things are not the same. You can have a test case that takes two hours to set up, or a half-dozen similar ones you can run in thirty seconds.

Scrum vs. Kanban by Mike Cottmeyer (ignore the Idol intro and title at the beginning)

snippet: I think that in some ways Scrum is hitting a wall because some of us think that Scrum is the answer to everything. Is Kanban the new answer to everything? Is it going to replace Scrum and XP or DSDM or AUP or Crystal? I can't even imagine how we can have these conversations without understanding where and when is the best context to apply these principles. I feel like a broken record but there is a time and place for all these techniques.