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.