Rod Claar

I am asked this question quite often.  What is Agile Coaching and what does and Agile Coach actually do?  When I started thinking about how to answer the question, I found it difficult to put the answer into words because there is no real formula for an Agile Coach to help the team be more effective in product development.  However when I started thinking about some of the coaching situations I have encountered a pattern did start to emerge.

Agility in software development is about identifying the roadblocks to effectiveness for the team as well as the individuals that are on the team.  Many of these are very common, yet each instance has it’s own form and smell.

Discovering these roadblocks is like the optimization of a program or module in software.  There is always the worst problem and each one has a cost in effort and risk to resolve the issue.  And just when you get that one solved, you discover another #1 issue.

The first step is observation.   What is the team doing?  How are the team members interacting?  Can I tell what is being worked on from the outside and can I see progress day to day in the project?

Sometimes I observe problems with understanding exactly what each  goal means in terms of the actual work to be done.  This probably means the team needs help breaking the work down into smaller chunks.  Smaller, more understandable chunks of work leads to better estimation and better predictability.   Ultimately the better understanding leads to better software because the team builds what is needed instead of a guess formed from cloudy understanding of the requirements.

Sometimes I observe the team not knowing what to do next or getting in each other’s way because the work dependencies are not clear.  This can be due to a lack of project task visibility.  Visibility is a difficult issue, especially with a distributed team.  Lack of good iteration visibility can lead teams to spend too much time on tracking and reporting and other teams to doing too little.  I work with the team to find the right level and detail for project and task reporting and work with them to make the publication of the reports as automatic as possible.

Sometimes I sense that the team is not comfortable with the process they are using.  The struggle against some of the practices and ignore others.  Most of the time this is due to the fact that certain members of the team do not recognize the underlying principles that the practices are intended to follow.  Sometimes there is an unstated fear of change or loss of status, influence or control that is causing them to not follow the agreed upon process.  In this case I start (or continue) individual coaching where the goal is to uncover the lack of understanding of the principles that make teams more agile or the fear that can paralyze an individual and a team.

I could cite many more examples, but let’s get back to the answer for the original question.

Agile Coaching is a process where an experienced coach observes the team to understand what attitudes, practices and communication problems are keeping them from being more effective.  This is done over a course of several days to a couple of weeks or more.  The coach will identify issues that are disrupting the flow of work, causing rework or causing redundant work or other wasted effort.  The coach will identify patterns of behavior that are not improving the team and the product.

The Agile Coach will then work with the team to help them see the issues and work with the team and management to facilitate improvement in the issues.  This is often a very subtle and Socratic in nature.  The coach does not often tell people what do differently or that they are wrong in what they are doing, but rather helps the team and the individuals discover a better path for themselves.

Just as the agile process itself the changes are incremental and are often only seen when looking back to recognize the improvement over time.

The Agile Coach is not a team member in the traditional sense of the word. Rather they are a trusted adviser who can identify the patterns of attitude and behavior that are often not seen by the team or not understood as roadblocks to a more efficient, happy and productive team.

The successful Agile Coach will work himself out of a job. Not because the team achieved true agility, but rather learned how to chart the path to agility for themselves.

I’ve been helping a pretty large team for a few months now.  Today I attended a user group meeting today on SecondLife delivered by Brian Harry of VSTS/TFS.  It is very clear that there are some issues that get exacerbated when you have a very large project.  

The first one that comes to mind for me is the formation of teams.  It seems that while some organizations are moving to cross-functional teams to some degree, the silos of discipline management still exist and tend to get in the way.   Brian Harry talked about the “Feature Crew” at Visual Studio.  These teams are cross functional but are created for specific feature sets.  These teams have specific goals and tend to be disbanded when the set of features are complete.  The team members often have multiple assignments simultaneously.  I’ll have to say that this is a step in the right direction in that the system and business capabilities are grouped with a team to deliver them.  This tends to help with the coordination of work between teams.  However the fact that they do not let the teams work together over an extended period means there is a lot of forming and learning about the team that is overhead.  

One of the other problems is the tracking and processing of bugs.  Because of the integration issues and the use of branching techniques to give the teams a relatively stable platform to work on, there are lots of bugs created and significant effort has to be put into managing and tracking them.  If you have a project with thousands of active bugs, you have a very big problem. 

However the biggest issue I’m seeing is the lack of visibility of the delivery of business value.  Huge projects are generally managed by feature delivery and bug rates and counts.  Most of this comes from the coordination of the work on the teams and the poor communication of vision down to the scrum team level.  This results in the scrum or feature teams doing massive amounts of interpretation on the requirements and the result is a bloated codebase with excessive complexity and enormous testing and integration issues.  Without a clear top-down expression of the vision for the product and the release the feature teams are virtually free to dump on the product.

All of these problems lead to release plan accuracy issues.  The traditional way this happens is slipping the ship date.  However the more dangerous risk is not delivering what the user needs.  How do we reduce the impact of these issues?

Firstly we should NEVER slip a ship date.  Our customers, users, clients need what we are building, otherwise they would not be paying for it.  They get no value out of software that they can’t use.

Secondly we MUST adopt a business value driven approach to managing the work and the teams.  This means that product and project management have to change.  Traditionally either the specifications/requirements are either so massive as to not be understandable or so limited they are little more than hand waving. 

To accomplish these two goals we have to prioritize the business value and constantly react to what the team is delivering.   The scope of the release WILL change, but if we have prioritized based on relative cost and relative business value we can deliver the important features on time.

This takes metrics and project status reporting. Brian Harry said that metrics should be about making you ask questions.  I could not agree more.  However the most important question should be about the progress toward delivering high priority business value.  If the teams were organized around business value items and the bugs were categorized by business value area then we could stop working on bugs that don’t impact the release plan.  We could also concentrate more on the quality of the code with the basic principles of cohesion, low coupling, testability and clarity.

It does not matter what tools you are using, the focus should be on the delivery of business value.  Track stories, bugs and scenarios in an appropriate way for your team, but concentrate, reward and deliver business value early in a way that will allow you to deliver business value quickly in the future.

Old friends are a wonderful thing.  You may not see them often, but when you do get the chance to slow down and share, it can be magic.  Because you are old friends there are so many things that you just don’t have to say, it is just understood.  And when there is a new area of conversation the barrier to real communication is low.

I had an opportunity yesterday to get together with some old friends.  We are not talking life-long buddies but rather three guys that I used to work with, have not worked with for a while, but now it looks like we will be working together again.

We have shared experiences.  We have unique perspectives.  We have a lot to share.

However new friends are also a wonderful thing.  New friends add spice to life.  There are new things to discover sometimes walking familiar paths with new perspectives.  I’ve gained a couple of new friends recently.  They are broadening my horizons. They are helping me learn new ways to look at things.  I think I am impacting them too.

Software development teams are a lot like a group of friends.  The old friends are good.  The team members you have worked with for a while are predictable and you have figured out how to communicate with them.  You may not always get what you want, but you know what to expect.

However the new friends are good to.  They offer new perspectives and possibly new skills.  However they don’t know your domain and it takes a while to understand how to communicate with them.

Developing good, valuable software is a tough and complex undertaking.  Customers and technology are always changing.   Old friends give you velocity and good predictability.  But new friends can help your team keep up with technology.  New friends can keep your perspective realistic.

I’m very much in favor of stable teams.  However recently I have seen several teams and organizations that have stagnated.  To maintain productivity over extended periods of time, teams have to inject fresh perspectives, knowledge and energy.  What is the rate of change that we need, I don’t have any statistical evidence, but my gut is telling me that on the normal Scrum / Agile team of 8 +/- 2,  that adding a new person every 6-12 months would be a good thing.

What do you think? Let me know!