Snehamayee Archives - Snehamayee's World Of Agile

GROW Coaching Model

GROW is a proven coaching model to structure coaching experience .

beauty of this coaching model is that it leads to a clearly defined end result through four phases. The coachee is personally active in identifying problems and generating ideas for solutions. As the coachee is actively engaged, the outcome is more likely to succeed

The GROW coaching model encourages learning through experience: reflection, insight, making choices and pursuing them. The success of a coaching trajectory with the GROW coaching model also depends on the time and energy invested into the process by the coachee.

The best part about working with the GROW coaching model is that you don’t need to be an expert in a specific situation to be able to coach the team. This model offers a framework with general questions to elicit objectives , obstacles, options and more without ever needing to offer advice or force any particular direction.

The steps in the GROW coaching model

The GROW coaching model consists of four steps. The word GROW is actually an acronym for Goal – Reality – Options – Will. This GROW coaching model enables you to to plan a journey. You start with the map: where are you going (Goal) and where are you starting from (Reality)? It then charts the different routes and modes of transportation (Options). At last, it helps you pick the option that suits you best while still considering the obstacles on the way.

GROW coaching model – Step 1: Goal

The first step in the GROW coaching model is defining the goal of the coaching initiative at hand. You will need long term (the central theme ) and short term (the goal for every session)goals.

Goals need to be SMART: Specific, Measurable, Acceptable, Realistic and Timely.

Example questions to identify the goal:

What Will help us achieve defect free code?
Why a defect free delivery will benefit the team?
What it means to be defect free? How do you define it?

GROW coaching model – Step 2: Reality

Step two of the GROW coaching model is making coachee aware of the actual situation on the ground . The coache’s role here is to stimulate thought with the coachee, and to identify the obstacles that have been holding the client back.

It’s important to stay out of the equation in this phase; people have patterns and stories they can repeat and expand on endlessly. Keep on summarising and repeating what you understand from the coachee. Often, this phase of the GROW coaching model reveals underlying fears and convictions that can be worked on during or in between coaching sessions.

Example questions to discover the reality of one’s client:

Hows the code quality now?
How do you know the current code quality is poor?
Why is the code quality poor?
Why it is problem to have a poor code quality?
What are concrete examples of this problem?
What’s been going wrong so far?
Is this always a problem or are there situations in which it isn’t?
What have you done so far?

GROW coaching model – Step 3: Options

Step three of the GROW coaching model is to generate ideas that can contribute to the solution of the problem. Try to start a creative brainstorming process without censure or conditionality. Generate solutions, then structure it to evaluate every option. If needed, you can also offer some suggestions.

Example questions to generate options:

What else could you do to improve code quality?
What would you do if you did not have a hard time pressure ?
What else do you need to reach your goal? Where can you get it?
Which criteria will you use to evaluate this option?
What are the pros and cons of this option?

GROW coaching model – Step 4: Will

The fourth and last step of the GROW coaching model is the choice of one option. This is converted into a concrete plan of action. Then the coachee’s motivation to follow this plan is maximised.

Example questions to maximise the will:

What exactly will you do to improve the code quality and when?
Which of these options will you take?
What concrete step can you take NOW to improve the quality?
What steps come after?

Power Questions – A really powerful technique

An agile coach is an influencer and not an enforcer. This means he does not get to dictate what approach a team will choose. In agile, development team decides what and how of their actions! In such a situations, asking leading or probing questions is one of the most powerful tools in the coaches arsenal

What Are Power Questions?

If you ask the wrong questions, even incomplete questions, you’ll probably get a wrong answer, or at least not quite what you’re hoping for.

Asking the right question is at the heart of effective communications and information exchange. By using the right questions in a particular situation, you can often make the recipient reach the conclusion you want them to. . Rights questions will help you gather better information and learn more, build better relationships and help others to learn too.

Following are some type of questions and also some guidance on when to use and when NOT to use them.

Some Important Power Questions?

Open and Closed Questions

A closed question usually receives a single word or crisp , Boolean answer. For example, “Was the sprint on time?” The answer can only be “Yes” or “No”; “How many defects did we have?” The answer is generally a number.

Open questions encourage more in depth answers. They usually inquire about elements of what, why, how. An open question asks the recipient for his or her knowledge, opinion or feelings. This engages the recipient in more constructive manner “Tell me” and “describe” can also be used in the same way as open questions. Here are some examples:

What did you observe in sprint planning?
Describe how your typical daily scrum goes…
Tell me about your feeling about this issue
Why do you think the sprint had so many quality issues?
How did he react to that?

Open questions are good for:

Initiating an open dialog: “What was your experience with automating system test?”
Provoke thought : “What else do we need to do to make this a success?”
Finding out the other person’s opinion : “What do you think about those changes?”
Collect more details “Was there something else that we need to know?”

Closed questions are good for:

Testing understanding, yours or the recipient’s: “So, if I get this automation done, build wont break?”
Ensuring that everybody is on same page “Now we know the facts, are we all agreed this is the right course of action?”
Creating a background: “Are you happy with the code quality?”

A misplaced closed question, on the other hand, can kill the conversation and lead to awkward silences, so are best avoided when a conversation is in full flow.

Funnel Questions

This technique involves starting with general questions, and then funneling down to a more specific point in each. Usually, this will involve getting in more and more detail . Detectives often use this techniques while taking statements from witnesses

“How many people were involved in the fight?”

“About ten.”

“Were they kids or adults?”

“Mostly kids.”

“What sort of ages were they?”

“About fourteen or fifteen.”

“Were any of them wearing anything distinctive?”

“Yes, several of them had red baseball caps on.”

“Can you remember if there was a logo on any of the caps?”

“Now you come to mention it, yes, I remember seeing a big letter N.”

Using this technique, the detective has helped the witness to re-live the scene and to gradually focus in on a useful detail. Perhaps he’ll be able to identify young men wearing a hat like this from CCTV footage. It is unlikely he would have got this information if he’s simply asked an open question such as “Are there any details you can give me about what you saw?”

Tip:

When using funnel questioning, start with closed questions. As you progress through the tunnel, start using more open questions.

Funnel questions are good for:

Finding out more detail about a specific point: “Tell me more about Option Two.”
Gaining the interest or increasing the confidence of the person you’re speaking with: “Have you used the IT Helpdesk?,” “Did it solve your problem?,” “What was the attitude of the person who took your call?”

Probing Questions

Probing questions is another strategy to get to depth of an issue. Sometimes it’s as simple as asking your respondent to elaborate “I did not understand your point about automation , can you please expand?” At other times, you need additional information for clarification, “When do you need this report by ?” Or to ascertain facts about what has been said, “How do you know that the new database can’t be used by the sales force?”

An effective way of probing is to use the 5 Whys method, which can help you quickly get to the root of a problem.

Tip:

Use questions that include the word “exactly” to probe further: “What exactly do you mean by fast-track?” or “Who, exactly, wanted this report?”

Probing questions are good for:

Gaining clarification to ensure that you have the whole story and that you understand it thoroughly.
Drawing information out of people who are trying to avoid telling you something.

Leading Questions

Leading questions try to lead the respondent to your way of thinking. They can do this in several ways:

With an assumption – “How late do you think that the project will deliver?” Here you assume that the project will certainly be late !
By adding a personal appeal to agree at the end – “Lori’s very efficient, don’t you think?” or “Option Two is better, isn’t it?”
Phrasing the question so that the “easiest” response is “yes” – People naturally prefer to say “yes” rather than “no”. This psychology plays an important part in the phrasing of questions: “Shall we all approve Option Two?” is more likely to get a positive response than “Do you want to approve Option Two or not?” The “shall we” part of the questions brings you and respondent in one group while the “do you” puts the respondent in opposite camp.
Giving people a choice between two options – both of which you would be happy with, rather than the choice of one option or not doing anything at all. Strictly speaking, the choice of “neither” is still available when you ask “Which would you prefer… A or B?” but most people will be caught up in deciding between your two preferences.

Note that leading questions tend to be closed.

Leading questions are good for:

Getting the answer you want, but leaving the other person feeling that they haven’t got a choice.
Closing a sale: “If that answers all of your questions, shall we agree on a price?”

Tip:

Use leading questions with care. If you use them in a self-serving way or one that harms the interests of the other person, then they can, quite rightly, be seen as manipulative and dishonest.

Rhetorical Questions

Rhetorical questions aren’t really questions at all. They they don’t expect an answer. They’re really just statements phrased in question form: “Isn’t John’s design work so creative?”

People use rhetorical questions because they are engaging for the listener – as they are drawn into agreeing (“Yes it is and I like working with such a creative colleague”) – rather than feeling that they are being “told” something like “John is a very creative designer.” (To which they may answer “So What?”)

Tip:

Rhetorical questions are even more powerful if you use a string of them. “Isn’t that a great display? Don’t you love the way the text picks up the colors in the photographs? Doesn’t it use space really well? Wouldn’t you love to have a display like that for our products?”

Rhetorical questions are good for:

Engaging the listener.
Getting people to agree with your point of view.

Choosing right agile pilot

Many students ask me how to choose a pilot? To ensure success of your transformation, it is really important to choose a right pilot. Below I will give a few suggestions. These suggestions have worked for me in while choosing an Agile pilot.

Select a “Visible but not critical project”. It is important to choose a project that has visibility across organisation. This will make the next steps of spreading agile easier. When we select a visible project, it becomes difficult for detractors to dismiss the success. At the same time be wary of selecting mission critical projects. Too much is riding over success of such a project. In this case, the team will be less likely to experiment. The stakeholders will be even less likely to have the necessary patience.
Size Matters!! I usually suggest to select project which is not too large. A large project has additional scaling challenges. These become an overhead while trying to implement agile. Usually not more than 3 scrum teams is a nice rule of thumb to follow. I also caution against selecting a too small a team. Such project may also mean a success which is not as spectacular to be tooted across organisation. A really small project delivered by a small team is anyway likely to be succeeded and agile would not get the crredit for the success!
Where possible avoid added complicating factors. If at all possible, it is better to avoid a project with unnecessary complications.Some examples can be, technology which is too strange to the team , a team that is greatly distributed (more that 3 locations) or a team that is too new and still in “forming /storming” stage. Changing way of work to Scrum is anyway stressful, it is best to avoid further stress.
Select a project that intuitively needs agile It’s best to select a project that has need to evolve requirements – in other words it’s best to have a pilot for starting a brand new product. It will allow the inherent agile qualities to shine..At the same time, we would avoid added complications of a monolithic architecture or a legacy code base that no one fully understands.
On board the champions – Identify your supporters early and include them in your pilot. These people are any way convinced and they will work hard to prove the concept.
Avoid The detractors – In the same vein, it is usually prudent to avoid strong nay sayers. They usually will come on board when they see the pilot succeed. This will reduce the stress of having resistance along every step of pilot

Difference Between Agile Coaching Mentoring and Agile Training

A scrum master needs to be skilled in Coaching, Mentoring as well as Training. Each of these activities have a considerable overlap. Each involves helping people to improve their performance.

Training

Training involves an expert (trainer)imparting a certain knowledge or skill to other people (trainees). A trainer is not usually involved in day to day activity. Its a structured activity revolving around sharing the said knowledge or skill.

Mentoring

Mentoring on other hand, is a system of semi-structured guidance whereby one person shares their knowledge, skills and experience to assist others to progress . Mentors usually are SMEs or experts who have traveled the path before and possess answers that will help the mentee. Coaching

Coaching

Coaching is a form of development in which a coach supports a learner in achieving a specific personal or professional goal. In other words, coaching is about a Coach unlocking the potential of the coachee. Here the coach may or may not have the answers. His role does not include handing over the answers on a platter. The coach helps the coachee to discover the answer himself.

How Agile Coaching, Agile Mentoring and Agile Mentoring differ?

A skilled scrum master needs to understand the difference between the three activities. He needs to be able to use the right tool for right situation. I have tried to list the key differences below.

	What is It?	Duration & Relationship	Who Drives it?	Models	Goal
Agile Training	Imparting new skills Or knowledge to the trainees	Usually short term. Is a transnational activity . Training is normally one to many where each trainee participates in individual capacity	Training is driven by the trainer - He/She decides the methodology and the model of the training	Multiple models like classroom instruction , discussions , demonstrations , hands on exercises may be used	Increased Skill or Knowledge for the trainee(s)
Agile Mentoring	Helping the mentee to reach the answers and achieve towards a certain goal	Usually Long term. Its an ongoing hand holding till the mentee reaches the goal.	Mentor , who is SME drives the direction and model	More intimate one on one way extended via discussion or thought provoking questions. Mentor will help the mentee outline his options and choose one	Better clarity for mentee Clear plan of progress
Agile Coaching	Develop existing skills to enable the team reach a better state	Usually medium term - lasting a few months to couple of years Agile coaching is usually in a one to many form where the coachees participate as a team	Here the coachess are the ones in driving seat. Coach will subtly influence but he can not enforce the way a coaching goes	Coaching usually happens where coach helps the team to reach a stage where they them selves will find the answer	Better on the ground application on skills and knowledge

Agile Coaching

With so many organizations adopting agile, “agile coach” has become a very important and in demand role. In industry today we see a common confusion around this this role. What does an agile coach do? What do you actually mean by agile coaching? These are the questions with many scrum masters struggle.

In this section, I am planning to write about my perspectives about agile coaching , what skills are needed by a good agile coach. What are some effective techniques to use?

Stay tuned and read along

Agile Transformation :: A Secret Sauce

We discussed sometime back that each agile transformation is completely unique. We don’t have a blueprint or a template which tells us how the ideal transformation goes. In fact there is nothing like an ideal agile transformation. You only have your own transformation.

Even then, almpst all successful agile transformations show some common elements. Transformations that I was part of also validate these elements. In this article , I want to describe the secret sauce needed to make your transformation successful.

Acceptance that current way of work is not working. For any agile transformation to succeed , the teams need to accept that our current way project execution is not working. Unless teams have really accepted this fact, they are not likely to have the motivation needed to bring about such a humongous change
Willingness to adopt scrum. Scrum requires a lot of change in our current way of working. It is human nature to be wary of the change. and people are not really be ready to change their way of working so drastically. Therefore, it is not enough that the team acknowledges current way of working is not succeeding. They also need to be convinced that at scrum or agile are indeed the way to success. This conviction about success of scrum is essential for successful scrum transformation.
Agile/Scrum is not limited to IT only. I have met many business stakeholders who insist that their users cannot really adopt to this new way of working. These users are often used to having long requirement specification documents. They are now scared to work in a way where they have to give the requirements in a small vertical slices. They insist that for their organisation, it may be a better idea to become IT only agile where the development happens in sprints after the requirements are frozen!! According to me, this is not agile but actually mockery of what agile is really supposed to be. To get real benefits that agile can offer it is important that the entire life cycle is being done in agile and not just part of the life cycle.
Create the right support structure Scrum works when the team has right supportive ecosystem. Setting up this ecosystem requires the organisational structure altered to suit the scrum work way of working. This may mean adapting the contracts, legal , infrastructure ,HR policies…List is endless. The change truly is pervasive.
Set the teams for success with with seeding in capability. As I have said often, agile is a difficult change. As the scrum guide says it’s easy to understand but difficult to master. Many organizations believe that they can just to send a few of their people for scrum master training. They then imagine that these newly trained scrum masters can drive the transformation on their own. This approach usually does not work.Training is definitely necessary . It helps with knowledge acquisition. But its not enough by itself. The newly trained scrum masters will usually end up with multiple issues while implementing scrum. They struggle converting their knowledge into skill. This is where a good coach can help the team. This person brings in outside perspective and also a fresh outlook.

Challenges In An Agile Transformation

“Change is everywhere.” and “change is painful” are two statements that we keep on hearing again and again.Even then many companies enter the agile transformation thinking that this is going to be just a set of activities that they will do and boom!! They will be agile!!!!

Like always, the reality is quite different from what we expect.I have seen many companies struggling with agile transformation of for years together.In this article, I am going to explore why this specific change is painful. In other words, we are going to see the challenges we typically typically see in an agile transformation.

Agile transformation never really ends. By Definition, an agile team is always on lookout for next thing to improve. This means, agile is a journey and not a destination. So the transformation never really ends. It makes measuring your success difficult. Also, the team is likely to loose their moral when they realize they will never be done.
There are no templates available .While there is an abundance of material on Agile Scrum, agile looks different for each organisation. As a result, agile transformation is essentially unique in nature .There is no a proven path. More ever agility evolves over time . It is not really possible to plan your agile transformation right upfront. The plan is fluid and evolves as teams become agile. This creates a problem for organisations who are used to following the OCM way of gap analysis followed by road map creation and then the road map execution.
Agile is everywhere. Literally speaking, scrum is a pervasive entity. It impacts complete organisation structure as well as the operating model for projects.When any change is limited to a certain area it is possible to limit the blast radius. Agile other hand not only changes how a developer works but it also forces the team to continually learn new skills. More importantly,to be really successful ,Agile needs a complete change in mindset and a change in organisational structure . This impacts a lot more people than just the software development community of the organisation.
Agile expects more Agile means paradigm shift to our way of working. Over the years we believed that principles like specialization, ironclad role segregation as well as meticulous plan based execution were the cornerstones of successful project delivery. “Process over people” was our mantra. Stringent processes and defined control points were put in to compensate for human inefficiencies and imperfections. Agile on other hand, puts the responsibility back on people who are executing the project. It expects the teams to step up. It needs the management to trust the teams and have a mind set of supporting and not controlling. These changed mindset expectations are often the most difficult to implement.
Bottom up and top down, a single direction doesn’t work . Many organisations are inherently top down or bottom up .In some organizations things get done when boss says so. On the other end of the spectrum some organisations change only when the teams want to. For Agile to succeed, neither approach is enough by itself. It will need a combination of bottom up and top down change approach for Agile to succeed.

These challenges beg the question, if it is so difficult is agile worth it? I plan to write a post soon to explore why organisations are going agile