The team is too fast, what to do?

During a recent conversation in a LinkedIn group, the following question came up:

Assuming you are maintaining a high velocity but your customer isn't keeping the pace with the team in-terms of feedback and freezing the stories. what do you do? Do you decrease your velocity or keep the pace and develop things based on your assumptions?

My response:

Talk to your customer. If they are happy with the pace, then you could downsize the team to match the customer velocity and use those resources elsewhere.

If they would love to go faster, then work with them. Learn how to help them be a better customer, or immerse some of your team in the activities of the customer (slowing your team down and speeding them up).

View the customer as being part of the team, at least until you can solve the problem.

The goal is not to develop stuff fast... the goal is to deliver the right stuff fast. (therefore developing things based on assumptions won't help).

Another thing you can do with that "extra time" is reduce technical debt, train the team on new stuff, refactor code, and improve things like performance and installability.

Your thoughts?

Keep your stinkin' Maturity Model - prescriptive vs. adaptive

I keep seeing the same question appear in many forums lately- "How do we create a CMMi-like Maturity Model for Agile?" Sometimes this is a global question for the community, sometimes it is a question focused on a specific organization.

A couple of thoughts:

• Not all problems can be solved by the same solution
• Not all teams have the same problem
• Not all teams have the same dynamic and ability to change
• Thus, not all teams will succeed with the same set of instructions
  
• But, all teams can be aided by an experienced mentor/coach

Whenever I hear of Maturity Models, I foresee an environment where the desired process is documented and stable, and the steps to evolving to it are prescriptive, standardized, and audited.

The problem I have with this is that it will most likely constrain the teams ability to explore new ideas and solutions to their problems. Their continuous improvement will most likely be driven through a canal that is managed by lock keepers and limited to the waterway. Kanban has had a refreshing influence on the community, but it is not for everyone. Does an organization create a maturity model that takes in every new idea? Does it have the capability to create a choose-your-adventure pathway?

Yes, I think an agile transition maturity model is possible. But I also think it is improbable to have the right outcome. And, it might be less work to allow the teams to find their own way with a centralized coaching/mentoring staff. What do you all think?

From a recent LinkedIn conversation I was having:

I would suggest that a first step is to inspire the PMO group in your organization to get out and observe the teams. Start documenting patterns. When there is a catalog of "for this problem, here are solution patterns that have worked", you not only have teams learning and growing from each other, but teams of like need mature towards a converged point.

Personally, I'd prefer this over a CMMi approach because it is a mentoring/guidance solution instead of a prescriptive/directed solution. The minute you demand teams follow a certain path, you limit their ability to explore and uncover great ideas. I believe that creativity and exploration through retrospectives is a key part of continuous improvement.

Why use the term coach?

In my work, I've had many labels applied to me. On bad days, they may not be so pretty; but most days, they are terms of endearment for what I try to provide the people I work with.

Recently, I got in a discussion about these terms and why "Coach" was the best term (other terms included: shepherd, evangelist, guru).

Coach is a great term because a coach is a person that is invested in success/failure (winning/losing), but isn't normally on the field doing the work. Their job is to provide the mentoring and tools (and environment) for the team to be able to succeed. They rally the team when they are down, and they point out the obvious when the team won't face it. They uphold the team values, and drive them to continuously improve. Finally, the focus is never on the coach, but the team's performance.

This is true in sports, and is true in agile environments.

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)!