That’s NOT Agile Coaching

I was recently reading an article on “Maintaining a sustainable agile transformation” that listed what it referred to as the “biggest  challenges organizations face during an agile transformation”.

One of these challenges that I found interesting was described as “Coaching becoming and end in itself”.  While I agree with the intent of the challenge, it identifies a continuing misconception of what is coaching.  In my opinion what was being described as coaching sounded more like the work of a consultant and or methodologist.

In my experience during the course of a lean-agile transformation teams often need training on lean and agile values, principles and practices and if they see the value in them, then they can benefit from coaching.  Once they ask the question how can we get to an envisioned lean-agile target state? (one of many to be set), the environment is fertile for coaching.

Coaching is not training and not consulting.   In my experience a context in which coaching can occur effectively requires these key characteristics.

1. There is someone who wants help addressing a change they would like to make (includes teams).

2. The person or persons involved in the context of the change are actually open to learning and change (they have a “Growth Mindset“)

Then there is the person doing the coaching

• Do they believe that those they are coaching can solve the challenge they are being coached on?
• Are they good at asking relevant, probing open questions?  A coach helps those being coached to reframe their perceived challenge so that they may ask better questions to bring better understanding and the ability to identify a possible solution that can be tested.  (Sound like the Improvement Kata?  it is 🙂 )
• Is the person claiming to be a coach an outstanding listener. Coaching is 10% speaking and 90% listening

If the person you’re considering for coaching in your organization doesn’t demonstrate the characteristics I’ve mentioned above, you might want to look elsewhere or for an alternative role for them.  This doesn’t mean that someone who is capable of being a coach can’t also have consulting and training skills, but they do need to know the difference and when it is appropriate to apply each.

Telling someone how to solve their challenges is the realm of consulting, teaching or bad management and not that useful if you’re trying to build a learning organization.

Are you an effective Agile Executive?

You are an executive in your organization’s Product or Engineering function. Your Agile PMO or Agile Coaches have established a tailored agile planning approach modeled after proven practices and common sense around human behavior and change management.

The key ceremonies of the planning approach from high level to individual sprint team level are well established on the calendar ahead of time because of a common cadence.

Regardless of this you don’t show up to most of the higher level planning ceremonies, yet you desire there to be firm accountability of others to them and their outcome. Why?

In my experience as an executive in an Agile organization, if you continually can’t attend your team’s broader Agile planning ceremonies, investment theme planning, release planning (Agile Release Train) either you don’t feel it valuable enough to make a priority or you do and you’re just not delegating effectively to be able to show up.

If it’s the former than you should tell your organization’s Agile Coaches or Agile PMO why it isn’t valuable and provide input on how it should work so that you would find value in the process.

Do your people in your Agile Product Development system allocate adequate time to engage effectively in planning? Do they procrastinate on planning waiting until the last minute and then just do the absolute minimum to rubber stamp their participation,usually removing the collaborative aspect of Agile planning in the process. Why is that?

Is it the incompetence or irresponsibility of the people working in the system? Or is the behavior a result of what the ‘system’ values?

Who controls the constraints / policies of the system? Do they know that their choices and behaviors set the policies whether they are explicit or not? It’s worse if there are explicit policies but those that set them don’t practice or stay within the spirit of them.

Long ago I received a funny gift that, to this day, I remember the wisdom it conveyed. It was a wooden box with an inscription. “Inside lies the best answer for who’s accountable for the dysfunction in your organization”. Inside the box was a mirror at an angle were you saw yourself 🙂

Food for thought when you consider how you can truly be a leader to your Agile Organization and enable effective and efficient Agile planning at all levels.

“Don’t piss down my back and tell me it’s raining”

If you’re involved with a team as a coach or consultant, there is a great line from a Clint Eastwood film that you should remember.

“…don’t piss down my back and tell me it’s raining.”

Extra credit if you know the movie 🙂

Point is, while language targeted to your audience can aid in the receipt of a change message it won’t make much difference if you are lessening people’s level of autonomy.

As Dan Pink outlines in his book “Drive”, there are four types of autonomy: Task, Time, Team and Technique.

The more your change proposal lessens these aspects of autonomy; the more resistance you’re likely to encounter and the higher the risk to the change effort.

Say you’re faced with a goal for improving performance, don’t assume there isn’t a way to achieve it  without lessening autonomy of teams.  Through coaching you can better engage a team to own the goal and to chart their path to its attainment.  IME, the outcomes of such an approach have the lowest risk of groups lapsing back to old behaviors that caused the perceived unacceptable levels of performance.

My experience over the last 3 decades has lead me to prefer coaching-dominate style in working toward change for improvement in a team or organization.  More times than not there is some blend of consultative style engagement with teams when one serves as a change agent in an organization.  The level seems to be in direct proportion to how much the leadership you’re dealing with are “driver” or “Red” type personalities and their awareness of realities of human systems.

A very ‘Red’ personality combined with a non-systems thinker often demand big change with quickly realized results.

You’ve probably seen this before, an agile transformation effort approved as an initiative and laid out on a project plan with explicit milestones for having reached specific change.  I once saw an agile transformation plan that detailed when the amount of performance increase in team throughput would be achieved. 😮  Definite red flag!  Let’s put it this way, the teams in this organization felt a warm stream down their backs. To no surprise this initiative was a failure and had to be rebooted.

Bottom line, always be aware of the human behavioral aspect of change, especially if your effort attacks one of the key components of intrinsic motivation in the modern knowledge based economy,  that being autonomy.

Move: “The Outlaw Josie Wales”

Being Comfortable In An Enabling Role

“By letting it go it all gets done.

The world is won by those who let it go.

But when you try and try.

The world is beyond the winniing.

– Lao Tzu

As project and program managers transition to Lean-Agile product development, it is common for them to grasp for the perceived ‘control’ they once had in traditional project and program management. This is understandable but there is an important mindset shift that needs to happen.

As uncomfortable as it might be, we (Agile Project Managers) are an enabling role in the system.  We don’t have power to set strategy, policy or allocated resources.  We don’t create the product, we don’t sell the product, we don’t support the product.  We are the immune system that works at keeping the work system healthy.  We play a vital role without control.  We are most effective when we are virtually invisible.

I find that adopting a coaching mindset is the most productive means for transitioning roles.

Is Lack of Role Clarity Affecting Your Organizations Predictability?

Recently I transitioned from being a Lean-Agile Coach / Consultant, working with many clients, to now being a Lead Agile Program Manager for one company.  It’s nice to be off the road after 4 years of travel.  I’m also enjoying the perspective that you only get being part of a team / company, once you begin to grasp the culture and the political / social model at play in the organization.

Currently I’m engaged with my team in Agile Program Management and an external Agile Coach to examine a hypothesis that there may be a lack of role clarity in the organization and that it may contribute to delivery predictability not being where we’d like it to be.  I plan on this effort resulting in series of blog entries chronicling  our exploration and experimentation around this topic.

Our initial exploration has begun with building a survey to assess the perception of who does / owns the common activities in the lean-agile software product  development work system.  In this case the system is for growing and maintaining a SaaS offering.  We’re also surveying what people actually do during a given iteration within the current work system.

Based on my past experience, and applying a bit of systems thinking, I would hypothesize that the lack of predictability in delivery is less related to role clarity and more to the lack of explicit policies that enforce some important, basic, lean-agile principles in the work system:

1. Make all work visible

2. Limiting work in process

In fact, the currently perceived risk of lack of role clarity risk may actually be teams engaging in self-organization.  Of course autonomy with out clear purpose to focus a team can be detrimental to minimizing waste on a team.

Lots of things to explore so this series should be interesting.

To Estimate or Not? To Track or Not? – Those Are The Questions!

I continue to see discussions on Agile and Lean forums about whether it is good to track this or estimate that.  The answers are like most things with Agile and Lean, they are contextual, but consider the following.

In Lean-Agile there are really 3 types of costs; value add, transactional and coordination. Value-add costs create value for the customer, the other two do not.

Estimation and tracking are a mix of transactional and coordination costs. They add no value to the customer hence they should be minimized. That said, the data collected through these two non-value add costs can be important for planning, communicating and driving an understanding of impediments and hypothesizing improvements.

Data is valuable for making pragmatic improvement decisions. If not, we wouldn’t have 5 senses collecting it. Eric Ries’ term ‘validated learning’ is appropriate here. I’m a big fan of right brain, intuitive reasoning but many in management are not…they need the data.

Knowing how much unplanned work (value demand and failure demand) a team has can be seen on a board just by using different color cards or different shaped cards. We are visual creatures and visual stimuli have the most impact with us.

We know that the enemy of predictability is variability in all its forms. Scrum was originally predicated on no interruptions. This isn’t a reality in many businesses for a variety of reasons. The planning ceremonies for Scrum for even a 2 week Sprint can become themselves wasteful if applied in the wrong context. For example, I recently visited a company that had mandated the use of Scrum, even in their support group.  They would hold a Sprint planning meeting on the first day of their Sprint  and 2 days later 30+% of their Sprint Backlog had changed so they would have to engage in regular re-planning to adjust their forecast. It was by estimating and tracking the particulars of their work that the team was able to convince management that Kanban was a better alternative.  After that the level of estimation and tracking reduced.

If you were to insist on practicing Scrum in such an environment, be sure you can explain why velocity is where it is. This will require understanding the nature of the work being undertaken by the team, which means having data, which will mean some rudimentary form of data capture and tracking. In Scrum, this is an area of service to the team that the Scrum Master can undertake to improve transparency and the type and quality of the data being radiated from the team. This aids the team and wider organization in making better plans and better decisions.

Passively watching velocity, lead time or cycle time change as you change practice or policy in a system through retrospection, hoping the changes improves things doesn’t cut it. Validated learning requires knowing what you expect to change from your experiment and what you will measure to know if your change hypothesis was correct. Such contextual needs for data should drive the amount of estimation and tracking a team undertakes in its efforts

One of my favorite Agile sayings is “we adapt the plan to fit reality and not reality to fit the plan”. Don’t forget this when choosing an approach to execute your organization’s work in its particular context.

Preparing the soil for the seeds of Lean-Agile Transformation

I recently attended a workshop in Washington D.C. to get licensed to teach the “Drive Workshop” based on Dan Pink’s book “Drive”.  I had already been a big fan of Dan’s ability to synthesize meaningful patterns and actionable steps out of the research and application of what social, behavioral and brain scientists have been uncovering over the last 40 years.  Having the chance to share experiences with practioners from many different contexts, it cemented in my mind how important this work really is to successful Lean-Agile Transformations.

Organizations that desire to be successful with lean and agile transformations have to prepare the soil if you will before you plant the seeds of change.   One of the fundamental changes that needs to be considered by leadership as part of that ‘soil preparation’ is to look at moving out of the industrial age carrot and stick motivation mentality, what Daniel Pink calls Motivation 2.0 to what he calls Motivation 3.0 in his book entitled “Drive”.

Motivation 3.0 works on the assumption that is most common in modern social and behavioral sciences, that human beings have a third drive beyond survival, procreation and material reward drives.  This is referred to as intrinsic motivation and is framed by Pink as “Autonomy, Mastery and Purpose”

Managers that fear loss of control in a Lean-Agile Transformation are almost certainly in the ‘carrot and stick’, motivation 2.0 camp.  They view humans as generally unmotivated without the presence of rewards and punishments, hence need to be controlled.  This is not what science has known for over the four decades yet management in what they do; businesses in what they value and educational institutions in what they teach still ignore the findings in their efforts.

If leadership and dare I say management desire a successful (read valuable) transformation, they need to plant the seeds of Motivation 3.0 early, from the top down.  This will help to start the conversation about aligning the reward / merit system to encourage ideas, policy and behaviors that promote team based execution and more purpose driven commitment.

It will also provide an easier transition for management to a more Servant-Leader approach to leadership.  A Servant-Leader will serve their teams by providing a crystal clear purpose so that their folks can feel part of something larger than themselves through their work. They will provide and protect an environment that enables the appropriate level of autonomy given the team’s level of mastery in their craft and as a team.

With a little forethought the leadership of an organization looking at undergoing a Lean-Agile transformation can greatly increase their chances of successful change, especially at scale, if they take some time to till in a little Motivation 3.0 before they plant the seeds of change.,

Distributed Teams are OK Because We Have Great Collaboration Technology…Right?

Not in my experience if it is how a company is rationalizing having distributed teams (a single team with members in multiple geographical locations).  Don’t get me wrong, it’s great if your company has great communication solutions that aid collaboration but they just shouldn’t define process or organizational and team design. The people’s needs and the problem domain should do that.

Fighting evolutionary biology is never a good idea.  Humans communicate and collaborate better in most cases face to face. Period.  Note, I’m not saying that complete open environments are the most conducive for productive for and satisfying work, but that’s another topic.

Having a single team distributed in multiple locations is just bad risk management.  You introduce the chances for more defects to creep in during requirements, increase the batch size of communication which delays response time (delay is waste) and also compromise the quality of life of folks because of the utilization of overlap hours for meetings. People resent this eventually if not immediately. That resentment has a cost.

It’s amazing to me how the financial folks that rationalize the cost savings never really are held to account of the true cost of these decisions.  Short run, sure, you can see savings, but because of dysfunction, frequent lack of transparency, and added waste, the costs savings can quickly evaporate.  I’ve actually had a finance person tell me “but we could redo it 2 or 3 times and still not have spent as much money.”  Really?

Having distributed TEAMS working in parallel to implement a big project is fine, as long as they are a complete (say Scrum) teams in each location.  This maximizes the opportunity for autonomy, the primary motivator in a knowledge based economy.  The need for cross time zone communication is limited more to Product Owners and Scrum Masters for issue and dependency management.

Having complete teams at each site can also help to minimize cultural and perceived fairness issues.  Frequently I have run into the situation where off-shore teams, away from the ‘Mother Ship’, feel like ‘second-class’ citizens.  They want to have their own identity, purpose and ability to succeed.  Often when another site is steering the ship, that is lost and it breeds distrust and a lack of openness.

My experience with devising a distributed teams strategy has always began with first understanding the organizational culture in terms of openness, safe to fail and the type of leadership.  Then take some time to understand the perspectives of the folks at different sites have about working in the culture.  Too often organizations make decisions based on what looks best in terms of money or management convenience.  This would suggest strongly that part of the organization making such decisions know nothing of Servant-Leadership, which, IMO, is a key for successful lean-agile execution because people are the key ingredient to building successful technology solutions.

Bottom line, make distributed team decisions wisely and don’t use technology as a rationalizing crutch when doing so.

How Long Should a Retrospective be for a Sprint?

The short-short answer is it depends on the length of the sprint.  For discussion purposes I’m going to frame the topic to a one to two week sprint.

Generally, for one week cadence teams, I find it is more effective to have the ceremonious retrospective every other week just so that the sample size of relevant outcomes from changes put in place from previous retrospectives can be more effectively evaluated. Of course if there is a glaring issue, a retrospective can be called JIT and not just at the end of the sprint time box.  Inspect and adapt applies all along the process 🙂

A retrospective scheduled for less than an hour, IME, runs the risk of becoming a ‘check list event’, meaning that it is done because it’s on a list of things to do.  Unfortunately this is often when folks no longer see the value of the ceremony because nothing useful seems to come from it other than having a gripe session.

Even very mature lean-agile teams that only invest 30 minutes in retrospection for 1-2 week sprint (that just might be a contradiction in terms) are likely to only focus on simple team policy issues and never get to any of the meatier sources of waste in their value chain.

As a Scrum Master or just an invited facilitator, an hour is the minimum amount of time I generally recommend for a retrospective for a two week Sprint.  And once again, this is even true for very high functioning teams that have working agreements, good listening skills and are aligned to continuous improvement.  To get through the core retrospective phases of discovery, generating insights and then deciding what to do, with an actionable and owned outcome, takes a modicum of time 🙂

To help ensure that the hour invested in a retrospective for a two week Sprint is perceived to have a good ROTI by the team it behooves the Scrum Master to be prepared for it.  This includes actively planning the retrospective during the Sprint by collecting topics brought up at the Scrum ceremonies, interviewing team members and stakeholders as well as assessing performance on past retrospective improvement stories.

With this data a good facilitator (which should describe a good Scrum Master) can effectively plan for the retrospective by selecting a theme which can focus discovery and insight generation phases.  Having a theme also enables the facilitator to have the needed data on hand, in a shareable format to support the process.  With one hour there is no time for folks to spend on running reports.

Bottom line is that the amount of time needed for a specific team to execute an effective retrospective is context specific.  But in this post I’ve identified the lower limit of time required, based on my experience, for executing an effective retrospective for a 1-2 week sprint as 1 hour assuming adequate prep.

Of course preparation for a group meeting should be common sense and it is supported by some of the most referenced literature on the topic of retrospectives for agile teams (‘Agile Retrospectives’ by Esther Derby and Diana Larsen and of course the works of the grand father of retrospection, Norm Kerth.

I’d love to hear others experiences and feedback on this topic.

Got Agile Success? – Got Teams That Trust?

I was reading some posts on the Scrum Alliance LinkedIn group as I usually do and I read another thread on a person asking for help with trying to figure out the right balance between stories and more detailed specifications in their Scrum software development efforts.  The advice given ranged from zealots bashing the person for doing too much documentation to suggestions for the right people being involved and the analysis techniques that are used by the Business Analyst’s role.

The one thing I’m always fascinated by when I hear about the challenges teams have through such posts, talks I attend or just speaking with teams, it’s nearly always a look at the process, techniques and tools they use for answers to their problems.  You just don’t see the discussion of the dynamic of the people doing the work, how high functioning they are as an overall product development team and the culture of the organization in which they operate.

Process takes shape as a by-product of these forces.  The team’s ability to establish continuous improvement is most impacted by these forces.  If there is low or no trust on a team, people will want to write more things down, and they will be much less likely to share the information. When you have a retrospective, you don’t get to the root cause of issues.

The same goes for the culture of an organization.  If agile teams live under ‘illusion of control’ metrics and artifacts, often characterized in the governance systems of command-and-control organizations, the challenge of building trust between management and teams is often very difficult.  Regardless of this challenge, many will just change process and techniques and ignore this root cause of problems — and then wonder why they aren’t successful when others are enjoying success with the same processes / frameworks. 

Let’s face it, Agile processes are fairly simple and lightweight, so even if you start with an ill-conceived process or technique for analysis or whatever, it could improve if you had a high functioning team and an organization open to change, both of which are enabled when trust exists. Frequently, where there is low trust amongst a group of people you end up with a group of individual contributors and not a team. Agile doesn’t work well in this environment because it is misaligned with supporting Agile values and principles.

I know, this is all touchy-feely that folks don’t like to discuss, but if it is addressed it is the thing that, in my experience, can lead to the greatest gain in capability for a team and it truly engages people to commit as a team to the delivery of value. 

If you can truly achieve trust within your team and with the organization, watch how fast things improve.