Book Review: Agile Coaching (Davies/Sedley)

Due to the second part of the Snowpocalypse here in the Northeast (3-4 feet in less than 7 days!), I had the opportunity to work from home and catch up on some reading.

The first selection was "Agile Coaching" by Rachel Davies and Liz Sedley. This book is part of the Pragmatic Programmers publishing series.

This is a great book with lots of modern concepts included. I was surprised to find notes on Kanban and Pomodoro included in sidebars since these concepts just became common/mainstream knowledge in the community in the last year. As a whole, the flow of the book and the ideas contained were well-organized and easy to absorb.

My only disappointment with the book is that I was hoping for a whole book on improving as a coach, but this was limited to the last chapter. The majority of the book was focused on various slices of agile and how to facilitate them. Because I was lucky with my entry into agile (I was mentored by great coaches from ObjectMentor), many of these thoughts had been planted in my head years ago. It was good to refresh them in a simple condensed fashion though.

Summary- I'm glad I have this book in my library. It may not have provided new information for me, but it is a great reference in times of stress when teams slip back into old habits. It provides a great reminder for me of things that I sometimes forget. More importantly, the book can be read in slices which makes it a great tool to hand to others to learn a specific concept. I think target reader should be anyone new to agile that is in a leadership role (note I didn't say management). I have a strong feeling that I may use this book heavily as a tool to provide insight for others.

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?