Questions, like most tools, can be used correctly or incorrectly.  A hammer used on a nail or on a screw is still a hammer; however, in most circumstances, we would debate the effectiveness of the hammer when used to insert a screw.  Questions are no different than our proverbial hammer.  Used well they can generate information or shape behavior; used incorrectly they can generate misinformation and friction. When questions are used for coaching and mentoring there are a number of poor practices that should be avoided: (more…)

Horse Crossing Sign

What is the Question?  Horse Crossing

Questions are a powerful tool for eliciting information, helping people grow, or leading people.  However asking questions often requires more than just opening your mouth and uttering the first words that come to mind.  Asking the right questions at the right time is a combination of art, science, and preparation.

  1.     Have a Goal

Establish what your end game is for asking a question.  For example, are you trying to gather facts, an opinion, or change behavior?  Your goal will affect both how you phrase a question and timing of delivery. (more…)

CC Attribution-ShareAlike 3.0 Unported (CC BY-SA 3.0)

Questions are a critical tool that every coach, mentor or leader uses to help shape and improve the performance of those they interact with.  ‘Question’ represents a high-level category that describes many different types of questions.  This is similar to the screwdriver.  If you were to walk into a hardware store and ask for a screwdriver the clerk would ask what kind and/or what you were going to use it for in order to help you find the right kind.  There are different taxonomies of questions which are useful to help practitioners decide what type of question suits which purpose. (more…)

Asking Questions Imply Listening

As coaches, leaders, change agents and even parents, the act of asking questions can take on an almost magical power to guide and change behavior. As with any powerful tool, when the tool begins to take on magical attributes, the users of the tool begin to forget that a tool is just a tool.  At that point to quote, Ian Brown, “they just become a fool with a tool.” Questions are a useful tool for a coach because questions: (more…)

A pile of empty pizza boxes!

WIP limits are needed to stop waiting in queues.

Recently a long-time reader and listener came to me with a question about a team with two sub-teams that were not participating well together. In a previous entry we began describing how kanban or Scrumban could be leveraged to help teams identify issues with how they work and then to fix them.  We conclude with the last two steps in a simple approach to leveraging kanban or Scrumban: (more…)


Restroom Closed Sign

Sometimes a process change is required!

Coaching is a function of listening, asking questions and then listening some more.  All of this listening and talking has a goal: to help those being coached down a path of self-discovery and to help them to recognize the right choice for action or inaction.  Sometimes the right question is not a question at all, but rather an exercise of visualization.

Recently when a long-time reader and listener came to me with a question about a team with two sub-teams that were not participating well together, I saw several paths to suggest.  The first set of paths focused on how people behave during classic Scrum meetings and how the team could structure stories.  However, another path presented itself as I continued to consider options based on the question.   (more…)

How can this team really work together?

How can this team really work together?

I recently got a question from a long-time reader and listener.  I have removed the name to ensure confidentiality.


  • The person who asked the question is an experienced Agile leader.
  • The team is not all technically-equal full-stack developers, some developers work on UI stories and others work on backend stories.
  • The team has 8-10 people.

The Problem:

  • During story grooming/sizing, the entire team does not participate equally to offer up their points. UI developers participate on UI stories and are reluctant to chime in on backend work, and vice-versa.

The Question:

  • Scrum seeks to involve the entire team.  How can I get everyone involved (or should I)?