Myth about Scrum Master being a renamed Project Manager role

A commom question often asked – Can we treat the Scrum Master as “The Project Manager in Scrum World?” – Let us understand how the world differs

Common Misconceptions and negative implications

  • Organizations implement Scrum Master role by renaming all their Project Managers as Scrum Masters just because they want to do Scrum or try Scrum. Scrum Master is the most mis-understood role in the industry.
  • Scrum Master remains the same “Command and Control” role
  • Scrum Master is made accountable for Product Scope, Product Delivery, Product Quality, Product Budgets and Project Timelines. Management holds one neck and that is Scrum Master’s neck
  • Scrum Master becomes a coordinator as the Project Manager used to be

Recommendations

  • Scrum Roles are designed in such a way that the right role takes the right accountability. The Project Management was a centralized accountability model where Project Manger was made accountable for everything. Scrum is a distributed accountability model. The Product is owned by the Product Owner. So, the accountability of Scope, Cost and Time is given to the PO. The Developers is made accountable for the delivery. So, Quality is the accountability of the Developers. Scrum Master is the guardian of Scrum. He/she is a coach and facilitator who makes things happen by making the right role take up the right accountability.
  • As a Coach, Scrum Master is a leadership role who guides the PO and Developers into following the Scrum Framework. Scrum Master makes the PO, Development Team and the Organization aware of the self-organized model, cross-functional teams, product accountability, complexity handling, importance of timeboxing, tools, techniques – in general Scrum framework as a whole.
  • As a Facilitator, Scrum Master makes sure that focus on getting decisions done and progressing towards goal. Scrum facilitates meetings, communications and helps the PO and Developers to come to conclusions. Many a times, the delay in decision making is the major cause of productivity issues. People don’t come to conclusions. Scrum Master’s job is to get the people to conclusions.
  • As an Impediment Solver, Scrum Master reaches to the right entities of the organization and gets right help at the right time so that team can proceed.
  • Scrum Master is a Servant Leader whose job is “to serve”. The accountability of doing the product work is given to  the Product Owner and Developers. Since Project Manager is responsible for Scope, Cost, Time, naturally it becomes a “Command and Control” role. The leadership styles are completely different.
  • Scrum is based on the “Fail-Fast ” model vs the Project Management which is based on “Don’t Fail” model. Scrum encourages the team to fail and let the team learn from mistakes. Project Manager makes sure that as much risk mitigation is done so that mistakes don’t happen. Scrum Master’s job is to allow mistakes and let the team learn from mistakes. Project Manager’s job is to prevent mistakes. They are diametrically opposite in the thought processes.

With so many drastic differences, if the Project Managers are renamed as Scrum Masters, the way people think is no different than what used to happen in waterfalls. Naturally done, we are setting up things for failure if Project Managers are renamed as Scrum Master. Lot of training and mentoring of Project Managers is to be done so that the Project Managers think differently to what they used to do while they were project managers.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-scrum-master-being-a-renamed-project-manager-role/

Agile Metrics – Friend or Foe

how to create a Metric framework for for your Program – How to choose Agile metrics , How to derive value from your Agile metrics

Agile Metrics is an area that causes quite a heartburn for many agile practitioners. There are strong advocates on both sides of debate. Some people will insist that everything you can measure -you should measure. They will say “only what gets measured, gets improved” .. These people will insist that measuring our progress, helps us to keep on track , to see if we are working up to our potential. They also argue that Metrics help baseline and allow us to have cer

On the the other hand we have people who will have objection to this very “base lining” as they believe the comparison leads to people focusing on Metrics rather than value …They argue that metrics add overheads and often can be manipulated to paint a picture you want to depict. A heavy metrics framework goes against the idea of simplicity.

Both sides have got merit in their point of view. But fact of matter is Metrics are very much here to stay. Its up to us to set up metrics that are lean and still deliver insights. In this section I am going write a series of articles that describe how to set up such a framework. Some of the topic I am considering are:

  • Why Metrics Need To Be Different For Agile Projects? Do we really need metrics for our agile projects?
  • What Metrics are seen to help agile projects?
  • Some Pointers to keep in mind while defining metrics for your projects

Of Course Metrics can never be defined in isolation – they need to be thought in context with your contracts as well as your own scrum implementation.

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.

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 & RelationshipWho Drives it?ModelsGoal
Agile TrainingImparting 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 capacityTraining is driven by the trainer - He/She decides the methodology and the model of the trainingMultiple models like classroom instruction , discussions , demonstrations , hands on exercises may be usedIncreased Skill or Knowledge for the trainee(s)
Agile MentoringHelping the mentee to reach the answers and achieve towards a certain goalUsually Long term. Its an ongoing hand holding till the mentee reaches the goal.Mentor , who is SME drives the direction and modelMore intimate one on one way extended via discussion or thought provoking questions. Mentor will help the mentee outline his options and choose oneBetter clarity for mentee
Clear plan of progress
Agile CoachingDevelop existing skills to enable the team reach a better stateUsually 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 goesCoaching usually happens where coach helps the team to reach a stage where they them selves will find the answerBetter 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