Coaching Models – FUEL and GROW

Coaching models – FUEL and GROW

 

The concept of coaching originated in sport – though historically the evolution of coaching has been influenced by many other fields of study including those of personal development, adult education, psychology (sports, clinical, developmental, organizational, social and industrial) and other organizational or leadership theories and practices.

John Whitmore defines Coaching “as unlocking people’s potential to maximise their own performance.  It is helping them learn rather than teaching them.”  The underlying intent of every coaching interaction is to build awareness, responsibility and self belief in the mind of the coachee.

Coaching models:

A coaching model is a framework, it does not tell you how to coach but rather it’s the underlying structure that you can use for when you’re coaching someone. It’s like having a high level strategy that allows you to “see the battlefield,” therefore increasing your ability to respond adequately to whatever situation you’re faced with.

 

Two of the popular coaching models are the FUEL model and the GROW model.  The FUEL model finds mention in the book “Extraordinary Coach – How the best leaders help others grow” by John H Zenger and Kathleen Stinnett.  John Whitmore popularised the GROW model in “Coaching for Performance – GROWing Human Potential and Purpose – The Principles and Practice of Coaching and Leadership”.

Let’s take a brief look at both these models

  1. FUEL model – The four steps in the FUEL model are
    1. Frame the conversation  –  Set the context for conversation by agreeing on purpose, process and desired outcomes of the discussion
    2. Understand the current state  –  Explore the current state from the coachee’s point of view,  expand his awareness of the situation to determine the real coaching issue
    3. Explore the desired state  –  Articulate the vision of success and explore multiple alternative paths before prioritizing methods of achieving this vision
    4. Layout a Success Plan  –  Identify the specific, time bound action steps to be taken to achieve the desired results and determine milestones for follow up and accountability

 

  1. A.     Frame the conversation`

 Framing the conversation ensures that the coach and the coachee agree to be in the same conversation and makes explicit what the conversation is about.  It is important to remember that the coach owns the PROCESS where as the coachee owns the CONTENT of the conversation. 

 

  1. Identify the behaviour or issue to discuss
  • I’d like to talk about…[the issue] if the coach initiates the conversation or
  • What is the most important thing for us to focus on (if the coachee initiates the conversation)
  1. Determine the purpose or outcomes of the conversation
  • By the end of conversation, I would like to accomplish…
  • What else would you like to make sure that we address? 
  1. Agree on the process for the conversation
  • Here’s how I thought we could proceed .
  • How does that sound
  1. B.      Understand the current state

As the coach begins to understand the current state, he needs to maintain a curious mindset.   As a coach, you play two key roles during this stage of the conversation – acting as a mirror and being a great exploration guide.   Asking open ended, non leading questions allows greater insight and clarity to both the coach and the coachee.  It is important to understand that people will not change until they feel a need to change.   The coach needs to offer his perspective only when it adds to the conversation and creates greater awareness for the coachee.

  1. Understand the coachee’s point of view
  • How do you see this situation?
  • What is happening?
  • What is working well?
  • What makes this challenging?
  • How might you have contributed to this situation?
  • How might others see this situation?
  1. Determine the consequences of continuing on the current path
  • What impact is this having on you?  On others?
  • What are the consequences if the situation does not change?
  • How does this influence your goals and what you are trying to accomplish?
  • What are the long term implications?
  1. Offer your perspective
  • Could I share some observations I made?
  • Could I offer some other consequences to consider?
  1. C.      Explore the desired state

It is of utmost importance that the coach does not rush the coachee into problem solving – it needs to be slow and deliberate to create the ideal vision and generate alternatives for achieving the vision.  The coach must negotiate and influence as to what would form part of the minimum measures of success.  If the coachee gets stuck, the coach should step to his side and become a brainstorming partner.

  1.  Understand the vision for success
  • What would you like to see happen here?
  • What would your ideal state look like
  1. Set goals and performance expectations
  • What are your goals?  What would you like to accomplish?
  • Here’s how I see it
  1. Explore alternative path of action
  • What might be some approaches you can take ?
  • What else might work?
  • Could I offer a couple of thoughts?  You might want to consider ….
  1. Explore possible barriers of resistance
  • What are the major barriers preventing this change from happening?
  • Where would the biggest resitance to this change come from?
  1. D.     Layout a success plan

In the last step, the coachee needs to articulate specific action steps to gain clarity as to what needs to happen next.  This will provide the coachee with a clear vision on the goal to be achieved.  The coach assigns timelines to the action points for follow up and accountability.   The coach finds creative ways to support the coachee achieve his goals.

  1. Develop and agree on an action plan and timeliness
  • What specific actions will help you achieve your goal?
  • What will your first step be?
  • Who can help hold you accountable?
  • How long will you stay focused on your goals and plans?
  1. Enlist support from others
  • Who can support you in moving forward?
  • How can I support you?
  1. Set milestones for follow up and accountability
  • Let’s review the plan
  • When should we touch base on this again?

 

  1. 2.      GROW model

The GROW Model is a simple yet powerful framework for structuring your coaching or mentoring sessions.  GROW stands for Goal, Current Reality, Options and Will or way forward.   A good analogy about the GROW model is to think how you would plan a journey.  You initially decide where you are going (goal), understand where you currently are (current reality), then explore various routes to your destination (options) and finally proceed on the journey (will) successfully overcoming any obstacles, you may have, along the way. 

Like most coaching models, the GROW model assumes that the coach is not an expert in the client’s situation.   He only acts as a facilitator, offering advice, and helping the client choose the best option on his own volition.    

  1. A.     Establish the Goal

First, the Coach and the Coachee need to look at the behaviour that you want to change  and then structure this change as a goal that he wants to achieve.

With respect to setting goals, it is important to distinguish between end goals and performance goals.  An end goal is the final objective – become the market leader, be appointed a sales director, win the gold medal etc – which are seldom within your control.    A performance goal identifies the performance level that will provide a good chance of achieving the end goal.  It is largely within one’s control and generally provides a means of measuring progress.   Examples such as 95% of production to pass quality control the first time, reduce weight by 10 pounds by December 2013 etc.  An end goal should wherever possible be supported by a performance goal.  The end goal may provide the inspiration, but the performance goal defines the specification. 

Besides supporting an end goal with a performance goal, goals needs not only be SMART,

  • Specific
  • Measurable
  • Actionable
  • Realistic
  • Time bound

but PURE

  • Positively stated
  • Understood
  • Relevant
  • Ethical

 and CLEAR

  • Challenging
  • Legal
  • Environmentally sound
  • Appropriate
  • Recorded

When doing this, it’s useful to ask questions like:

  • How will you know that you have achieved the goal? How will you know that the problem or issue is solved?
  • Does this goal fit with your overall career objectives? And does it fit with the team’s objectives?

 

  1. B.      Examine the Current Reality

The Coachee is asked to describe his current reality. Too often, people try to solve a problem or reach a goal without fully considering their starting point, and often they are missing some information that they need in order to reach their goal effectively. It is in the reality phase that the questions should most often be initiated by the interrogatives, what, when, where, who and how muchHow and why should be used only sparingly or when no other phrase will suffice.  The reality answers should be descriptive not judgemental to ensure honesty and accuracy. The answers must be of sufficient quality and frequency to provide the coach with a feedback loop.

Questions include 

  • What is happening now (what, who, when, and how often)? What is the effect or result of this?
  • Have you already taken any steps towards your goal?
  • Does this goal conflict with any other goals or objectives?

 

  1. C.      Explore the Options

The purpose of this stage is not to find the “right” answer but to create and list as many alternative courses of action as possible.  The quantity of options is more important at this stage than the quality or feasibility of the options.  It is from this broad range of creative possibilities that specific action steps will be selected.  The coach would need to create an environment where the participants will feel safe enough to express their thoughts and ideas without inhibition or fear of judgement from the coach or others.  Once a comprehensive list is prepared, the Will phase of coaching may be simple in terms of selecting the best from the list.  However, in certain complex cases, it may be necessary to re-examine the list by noting the costs and benefits of each course of action.

Typical questions include 

  • What else could you do?
  • What if this or that constraint were removed? Would that change things?
  • What are the advantages and disadvantages of each option?
  • What factors or considerations will you use to weigh the options?
  • What do you need to stop doing in order to achieve this goal?
  • What obstacles stand in your way?

 

  1. D.      Establish the Will

The purpose of the final phase of the coaching sequence is to convert the discussion into a decision. 

Useful questions to ask here include:

  • So, what will you do now, and when? What else will you do?
  • Will this action meet your goal?
  • What could stop you moving forward? How will you overcome this?
  • How can you keep yourself motivated?
  • What support do you need?
  • On a scale of 1-10, the degree of certainty you have that you will carry out the actions agreed.
  • When do you need to review progress? Daily, weekly, monthly?
  • Finally, decide on a date when you’ll both review his progress. This will provide some accountability, and allow him to change his approach if the original plan isn’t working.

Conclusion:

There are many coaching models available such as SUCCESS, CREATE, STEPPA, WHAT etc.  However, most coaching models have a few characteristics in common:

  • The establishment of a relationship that’s built on trust, open communication and confidentiality.
  • The formulation of client-based, agreed upon goals and expectations.
  • A deep questioning and learning dynamic in relation to people’s goals.

 

One’s approach to coaching finally boils down to a process, a model of how you do things and get results.  One need not be an expert in all coaching approaches, but as long as the model helps your clients achieve their goals, the Coach has achieved his objectives.  

 

References:

  1. Coaching for Performance – GROWing human potential and purpose by John Whitmore – http://www.amazon.com/Coaching-Performance-Potential-Principles-Leadership/dp/185788535X/
  2. The Extraordinary Coach – How the best leaders help others grow  by John Zenger and Kathleen Stinnett –  http://www.amazon.com/Extraordinary-Coach-Best-Leaders-Others/dp/0071703403/
  3. http://www.what-is-coaching.com/coaching-models2.html#.UkJdioZ83F8
  4. http://www.performancecoachtraining.com/resources/docs/pdfs2/Facts_about_Feedback.pdf

Managing Technical Debt

Managing Technical Debt

 

Technical debt is a term coined by Ward Cunningham to describe the cumulative consequences of corners being cut throughout a software project’s design and development. According to James Shore, it is the cumulative total of less than perfect design and implementations in your project.  Tom Poppendick defines technical debt as everything that makes your code harder to change.

During the course of a project, the development team cuts corners due to a variety of reasons such as lack of skill, pressure of meeting deadlines or sheer laziness.  Over time, these result in accumulating a large backlog of technical inefficiencies that needs to be serviced in future.  These issues could be related to code base, the development environment, platform, libraries, design, test coverage, test automation etc – resulting in high defect rates, reduced velocity,  poor code maintenance and low productivity.  The key to managing technical debt is to be constantly vigilant, avoid using shortcuts, use of simple design and re-factor relentlessly.  Unchecked technical debt makes the software more expensive to modify than to re-implement. 

Classifying Technical Debt

 

Martin Fowler’s Technical debt quadrant gives us a clear picture of what Technical debt is.

 

 Image

 

Figure 1 :   Technical Debt Grid Quadrant

http://martinfowler.com/bliki/TechnicalDebtQuadrant.html

 

This could be used in organizations to decide which sources of debt are acceptable and which are not,  and use the information to establish tactics for preventing unacceptable behaviour…

  1. 1.     Prudent & Deliberate

This quadrant is reserved for business drivers that have a compelling ROI for why a product has to ship immediately – i.e. responding to a threat to the business bottom line, or exploiting an opportunity that positively affects the bottom line. Examples where this could be justified could be :

  • Entry into new market – first to market may mean that less quality or features with more work-arounds might be acceptable
  • Regulatory or Legal Requirement   –  compliance projects where not meeting dates could have severe financial and operational impact to business   
  • Peak-period opportunity – within retail, the Christmas period is increasingly becoming the most critical part of the annual cycle and failure to launch prior to Christmas could have a significant negative impact on the company’s performance.
  1. 2.     Reckless & Deliberate

This quadrant reflects poor management where usually corners are being cut in order to hit a deadline that is related to perceived operational needs rather than an underlying clear business case.  This is a very common cause of Technical Debt.

 Examples :

  • Rushing the project to completion because there’s lots more projects to deliver in the pipeline.
  • Pushing the project through because the client wants it on a set date, no one has built a relationship with the client to discuss the details, nor has the client been informed of the affect on quality if the delivery is rushed
  • Cutting corners because teams have been incentivized to deliver projects into production by a specified date.
  1. 3.     Reckless & Inadvertent

This happens to typically  programmers who are incompetent and unaware of the implications of adding / removing a piece of code – thus incurring a huge technical debt.   Technical debt in this   quadrant needs to be carefully managed by using processes and tools – through pair programming, code reviews, continuous integration, automated testing etc.

  1. 4.     Prudent & Inadvertent

This is a natural occurrence. Teams  would like to improve upon whatever has been done after gaining experience and relevant knowledge.  

Short Term and Long Term Debt

Technical debt can also be short term and long term debt.  A short term debt is reactive and a tactical measure (pushing a release with known Severity 3 bugs) where as a long term one is a proactive and strategic one (not providing support for a platform which may not exist after 2-3 years).  The implication is that short-term debt should be paid off quickly, preferably as part of the next release cycle, whereas long-term debt can be carried on for a few years or longer.

Technical debt in legacy projects

According to James Shore,  one of the biggest problems facing legacy projects is excessive technical debt due to which velocity takes a huge hit.      Typically in  a legacy system,  so much work goes into keeping a production system running (i.e., “servicing the debt”) that there is little time left over to add new capabilities to the system.  The “bleeding” has to be stopped to prevent more technical debt from occurring.      

Besides the use of practices sucgh as Test Driven Development and Continuous Integration, it would be preferable to set apart a certain amount of time as “slack”  during each iteration to service technical debt.    Though these measures may not be fruitful for the first few iterations,  one would be able to see improvements in quality and productivity over a period of time.    

Attitudes Toward Technical Debt

Like financial debt, different companies have different philosophies about the usefulness of debt. Some companies want to avoid taking on any debt at all, others see debt as a useful tool and just want to know how to use debt wisely.

Few companies  track debt vs. team velocity. Once a team’s velocity begins to drop as a result of servicing  its technical debt, the team focuses on reducing its debt until its velocity recovers. Other approaches include   tracking rework, and use that as a measure of how much debt a team is accumulating.

 Servicing the Technical Debt

The first step in servicing the debt is to identify any such issues and register them – making it visible for the team.  These could be made part of the Product backlog or even have a separate Technical Debt backlog for purposes of tracking.   The team can then evaluate and prioritize taking into account the effort required    and the “pain” caused by the technical debt and its frequency.   The Product owner would need to take a conscious decision whether the  “economics” justifies the cost of the technical debt   It has to be kept in mind that not all technical debt need not be repaid.  E,g.  one can live with issues relating to a Product nearing its end of its life.   However it is important during this time that technical debt is not accumulated since that would only cripple the system

Similar to payment of financial debt,  it is prudent to repay the “high interest” technical debt first.  It is preferable that technical debt is repaid incrementally – like making a monthly mortage payment,  through use of practises such as peer reviews, TDD, refactoring, continuous integration and automated testing.   

Steve Garnett in his blog on Strategies for Technical Debt prioritization has an interesting take on Technical Debt Portfolio Prioritization.  Based on the degree of business value which the application currently provides against the degree of business value which the application fulfils the future needs of business, he  has come out with Technical Debt prioritization quadrant. The remedial action for each of these four situations summarizes how technical debt is to be managed.

Image

It is important that organizations take cognizance of technical debt and find ways and means to manage them efficiently to prevent a system collapse.

 References :

 

  1. Art of Agile Development – James Shore
  2. Succeeding with Agile – Mike Cohn
  3. http://www.martinfowler.com/bliki/TechnicalDebtQuadrant.html
  4. http://martinfowler.com/bliki/TechnicalDebt.html
  5. http://www.construx.com/10x_Software_Development/Technical_Debt/
  6. http://blogs.ripple-rock.com/SteveGarnett/2013/03/05/TechnicalDebtStrategiesTacticsForAvoidingRemovingIt.aspx
  7. http://www.scrumalliance.org/articles/14-technical-debt-and-design-death
  8. Managing Technical Debt – Presentation by Kenny Rubin at Mile High Agile 2013, Denver, Colorado  – http://www.innolution.com/resources/presentations/managing-technical-debt
  9. http://www.construx.com/10x_Software_Development/Technical_Debt/
  10.  http://www.ontechnicaldebt.com/slideshare/technical-debt-the-silent-application-killer-graham-brooks/
  11. http://www.ontechnicaldebt.com/slideshare/credit-crunch-code-paying-back-the-technical-debt-gary-short/