Scrum is the "only sane, rational way to manage dynamic processes"

So... let me start with the setup. It was asked in the Agile Alliance LinkedIn Group whether the agile community is mature enough to coherently discuss a "maturity model". I was one of the first two to respond that answered down similar lines-

Mature enough, yes. Coherent, no.

Agile is a philosophy and culture. It is an umbrella term for a set of best practices... Scrum & XP being only two. I believe that getting everyone to agree on an AMM will either destroy the continuing evolution of the movement or marginalize non-core movements that are adding to it (think of Kanban/Lean in the last year).

The discussion continued on an interesting path including CMMi and other maturity models, the pro's and con's and various gut reactions to what this would mean. All good stuff.

But in the middle of this, Melvyn Pullen and I got on a tangent that started with him proposing an agile maturity model that was focused solely on Scrum for the first few steps. I questioned this since agile has many flavors, and enforcing Scrum as the first step seems limiting.

The problem I have with a maturity model defined this way is that it implies to all newcomers that it is the ONLY way. The manifesto was signed by 17 people of 7 methodologies/practices. They didn't identify Scrum as step 1 down that journey.

He responded with,

I believe that Scrum is the only sane, rational way to manage dynamic processes.

and

It is my opinion that Scrum is the only management technique that comes from the agile camp that could be used to introduce other agile processes.

Comments?

Agile books to read...

A post was put up in the Agile Alliance requesting books to read to learn about agile. This was a pretty wide scope, and it resulted in a pretty broad list that continues to grow:

• Agile Coaching
• Agile Estimating and Planning
  
• Agile & Iterative Development by Craig Larman
  
• Agile Principles, Patterns, and Practices in C#
  
• Agile Project Management with Scrum by Ken Schwaber
  
• Agile Retrospectives
• Agile Testing: A Practical Guide for Testers and Agile Teams
  
• Clean Code
  
• The Art of Agile Development by James Shore
• Lean Software Development by Mary Poppendieck
• Making things happen
  
• Tale of Two Systems
  
• The Passionate Programmer
• Practices of an Agile Developer
  
• Scrum and XP from the trenches by Henrik Kniberg
• Suceeding with Agile by Mike Cohn
• User Stories Applied for Agile Software Development

Authors and topics-

• Kent Beck (XP, patterns)
• Mike Beedle (Agile, scrum)
• Arie van Bennekum (Agile, DSDM)
• Alistair Cockburn (use cases, crystal, etc.)
• Mike Cohn (agile, scrum, planning poker, etc.)
• Ward Cunningham (XP, patterns)
• Martin Fowler (enterprise design patterns, refactoring, uml, xp, etc.)
• James Grenning (planning poker, etc.)
• Jim Highsmith (time-boxing, agile development)
• Andrew Hunt (pragmatic, incremental development)
• Ron Jeffries (XP, etc)
• Jon Kern (agile development and PM)
• Craig Larman (Craig's been writing about IID/Agile for a long time)
• Brian Marick (I think agile testing - but I'm not familiar with his work)
• Robert C. Martin (Agile Principles, Practices and Patterns, etc.)
• Steve Mellor (not familiar)
• Mary Poppendieck (lean)
• Ken Schwaber (co-founder of scrum, buy all of his books)
• Alan Shalloway (design patterns, agile, lean+scrum, etc)
• Jeff Sutherland (co-founder of scrum)
• Dave Thomas (agile OOA/D)

Credit for this list goes to everyone that helped build it on the forum.

Is Agile a more humane way of working?

This was the question asked in the Agile Alliance LinkedIn group, and the question was focused on agile vs. other methods. It questioned whether the manifesto itself was written with the human element in mind, or whether it was focused on efficiency and outcome only (the human element being a byproduct). Additional points mentioned the 40 hr work week (as opposed to more) and sustainability.

The first three responses dissappointed me since they were non-answers.

1. I wasn't there, we can only guess (as if we've never heard the authors speak since then!)
2. I'm not sure, but it is at least more natural
3. Self direction creates a perception control and therefore happiness

Not being one to sit idly when there is an obvious answer, I had to state the following:

Yes!

The 8th principle of the Manifesto - "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."

BTW, many mature XP teams will peak around 35 hours, not 40. Pairing and TDD is very intense. You get the most around 35 hours, and productivity can start decreasing between 35-40. But this productivity is higher than the prior 45-50 hr weeks. I've both seen this and heard about it from others.

Cesario Ramos chimed in also:

The lean and agile thoughts explicitly make human values to be the center. It promotes an environment where every individual can use its potential for developing itself and its company. An environment where people can be part of a team and can contribute to a higher objective.

So in my opinion, YES, it is a more humane way of working. Even if the intentions of the agile approach are just to make more money.

There is that caveat that every idea can be destroyed and that there are plenty of companies that use Agile to get more hours out of their people. But, when I see this, I tell those that are suffering that their pain is inflicted by people, not by trying agile (and they aren't doing agile)!

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