Magic Words, Jargon, and Gibberish

Does your Daily Scrum feel a bit like the movie Groundhog Day?

The idea for this post was sparked by a text this morning from one of my former students who I have anonymized below as Development Team Member (DTM):


Despite the subtext of humor, DTM is clearly frustrated. She has just endured an hour’s long ordeal of (mostly) gibberish. That much is clear. What is not so clear is whether the team has a plan for working together over the next 24 hours. Nor is it clear as to how the team is progressing in relation to their Sprint Goal and their forecasted increment.

Where was their Scrum Master? How did this happen?

Words lose their meaning

Agile, Scrum, Lean, Daily Scrum… these are just words. Good ideas lose their positive impact when the words we use to describe them and their underlying practices are not understood in the same way by all stakeholders. For example, while we may understand what we mean by “Daily Scrum”, it is unreasonable to expect someone unpracticed in the correct enactment of the Scrum framework to share this same understanding. Jargon is not a substitute for an effective conversation!

Unfortunately, there are probably more examples like the one above of “bad” Daily Scrums than there are of good ones. Attempts to become agile through “magic” meetings with “magic” incantations such as “What did you do yesterday…?” are ineffective without a keen understanding of the why behind the question and the expected outcome of the meeting. If we can’t get a Daily Scrum right, what hope do we have to change the way we engage with our customers?

On a positive note

In the text exchange above, DTM has an idea as to how to improve the meeting. The “ball” she suggests bringing next time will serve as a talking stick to support her team’s agreed upon “one speaker” team norm at the Daily Scrum. Another idea DTM’s team might consider is a visible timer to serve as a reminder that the Daily Scrum is only part of the day’s “work”. (Scrum reinforces this idea through its rule limiting the Daily Scrum to a 15 minute time-box).

Most important, DTM’s insight for a way to improve the team’s way of working together is in the spirit of Agile. The authors of the “Manifesto for Agile Software Development” had in mind a sense of adaptability grounded in learning. DTM’s frustrating experience in today’s Daily Scrum is learning that will lead to the type of adaptation that the authors intended — and that is an outcome that transcends magic words, jargon, and gibberish.

Lift Off: Start and Sustain Successful Agile Teams

The newly released second edition of Liftoff is bigger and better than ever! With a larger format and improved layout, Diana Larsen and Ainsley Nies' acclaimed book is chock full of great ideas on how to start your agile team on the road to success and how to sustain them on their journey. I may be biased as contributor to the book, but if you're looking to get a team going or need to get an existing team out of the ditch, this book is the one to read!

The Agile Habit — How 2 minutes a day can make a big difference

Success with Agile depends on the right mindset... plus practice, practice, practice. I’ve written before about the importance of choosing a goal before selecting specific Agile practices, that is Begin with the End in Mind. However, for a moment, let’s consider the potential impact of focus on a single Agile practice:  the Daily Scrum.

In Scrum , the Scrum Team meets every day for a brief meeting (less than 15 minutes) to inspect where they are on their Scrum goal and plan out their activities for the day. During this Daily Scrum , each team member answers 3 questions:

  • What did I do yesterday?
  • What will I do today?
  • What is in my way?
2 minutes.png

Since Scrum teams are small (typically 4-9 people), that means that each team member likely has 2 minutes or less to communicate what they are doing and what they intend to do to optimize the teams’ chances of completing the Scrum goal. In addition, the team needs to consider this information to optimize their work as a team for the day. For the Daily Scrum to work, each individual team member must arrive prepared to tell the team what it needs to know in less than 2 minutes.

How do you know if the Daily Scrum is working? One thing to look for: "Is the team learning?" In other words, does the team’s plan for the day reflect the current reality of where they are relative to the Sprint goal? The answer to this question is an early indicator of practice effectiveness. A lagging indicator is the Sprint Review, where you can measure the team’s actual delivery against the Sprint goal. For example, are there any late surprises? A late surprise could be an indicator that the Daily Scrum practice isn’t working as well as it might.

The purpose of the Daily Scrum is for the team to adapt their work plan based on what is actually happening. Each individual team member’s input to this meeting is essential to the inspection that makes the team’s adaptation possible. What goes into that 2 minute contribution to the Daily Scrum? Let's consider each of the questions in turn.

What did I do yesterday? — First, a team member must have done something the previous day that is worth communicating. Connecting work done to the Sprint Goal and why that is important to the rest of the team informs this answer.

What will I do today? — The answer to this question is a bit like an improv act. Three inputs set up the scene:

  • the Sprint goal,
  • where the team is against the Sprint goal, and
  • the possibilities of the day.

Each team member must consider these inputs and the answers from their fellow team members. The intent is to enable collaboration to optimize the team's work. Individual team members must listen to each other and be willing to adapt the plan for the day based on what is learned from each others' answers to this question.

Robert Burns by Alexander Nasmyth, 1787 Scottish National Portrait Gallery

Robert Burns by Alexander Nasmyth, 1787 Scottish National Portrait Gallery

What is in my way? —  with apologies to Robert Burns, "The best laid schemes o' mice an' men Gang aft a-gley." Rare is the Sprint in which all goes according to plan. The true test of agility is to make the best of the situation, be it bad or good. The answer to the third question makes clear to everyone what is known to be in the way of successfully getting to "done" on the items in the Sprint. With this information, the team plans how to address the impediment. 

It's important to note that while the Daily Scrum is used as a synchronization and planning meeting, the actual resolution of problems does not happen in the meeting. Resolution of problems happens after the meeting. Honoring the 15 minute time box, the team wraps up the Daily Scrum and gets to work on the possibilities of the day.

Try this for 30 days. Let me know how it turns out.

For further thought: How do these 3 simple questions and the 15 minute timebox influence behavior?

The Mailbox


Coaching takes many forms. Face-to-face tends to be the most effective (and often the most efficient); however, remote coaching can also work. Here's a glimpse into my mailbox showing an example coaching response to a followup question from a Product Owner with whom I have been working.

From: Rob
To: Jim
Subject: Scrum Question

Your email reminded me that I was going to ask you a question.

We have a project that has 3 teams now but will likely have 5 in the near future. Today we are using Excel for the Product Backlog.  But we are over 500 items and maintenance is very hard.

Are there any tools your recommend for large projects?


From: Jim
To: Rob
Subject: RE: Scrum Question

Regardless of the tool, 500+ items are going to be a bear to maintain. A key practice is to keep the queues short. Some questions back:

  • Why is the backlog so big?

  • Are all these items worth maintaining on the backlog?

  • Can the lower priority items be off-loaded to a separate list (i.e., parking lot) with promotion to the active list deferred until the item becomes timely and important?

  • If you have a parking lot list, is there actually value in maintaining this parking lot or will the items surface if needed?

  • Could the "project" be decoupled such that each team is handling a sub-system with its own (smaller) backlog and a scrum of scrums to manage interdependencies through "service contracts"?

Rather than change tools, you may want to consider:

  • How can we reduce batch size for each release?

  • How can we reduce batch size for each team?

Current research is showing that smaller batch sizes result in more frequent delivery and higher reliability. Is faster feedback and higher reliability worth the investment in figuring out smaller batch sizes?

Also, a smaller batch size may eliminate the need to migrate from your existing tool. Then again, if Excel is insufficient for other reasons, experimenting with other tools may be worthwhile.

BTW, moving to a new tool capable of maintaining a larger queue will likely result in a larger queue. Is that a desirable outcome?


Regardless of format, coaches ask a lot of questions. It can be easy to give a pat response or recommendation. It is much harder to figure out the right question. In Rob's situation, the better question is whether the queue is the right queue rather than which tool to use.

Is your coach asking the right questions?

Simple Rules!

"But, it's not on the list."

For years, I started a facilitation workshop by having the students come up with norms for the class. My intent was to both create ground rules for the session as well as have the students practice an activity that they would likely use themselves as facilitators in the future. The facilitation technique for this exercise varied from class to class, but the output of the exercise was usually a flip chart page with a list of do's and don'ts which we would then display prominently somewhere in the classroom.

Even with the ground rules for the class thus established, I found over time that it was not unusual for someone to do something during the class that, while not technically against the letter of norms, certainly violated the spirit... and further, it was not unusual for the someone, when called out for their behavior, to point at the poster the group had created and say, "But, it's not on the list!" From this individual's perspective, the fact that their behavior was not specifically prohibited by the norms captured on the flip chart page somehow made the behavior acceptable, no matter how disruptive the behavior might be.

On the positive side, the disruption gave the whole class an opportunity to practice their facilitation skills in another exercise, a retrospective, the intent of which was to improve the class norms — two birds with one stone, you might say. However, what also became clear over time was that no matter how valuable the activities of facilitating team norms creation and running retrospectives might be, no list, no matter how exhaustive, could possibly cover all undesirable behaviors of ingenious disrupters.

What to do?

For inspiration, I turned to something a wise man, Dee Hock, said:

"Complex rules and regulations give rise to simple and stupid behavior." 

Dee Hock's words put the class norms poster in a new light. Instead of growing the list of items on the poster, what if we considered a new approach? 

For this new approach, I drew on additional wisdom from Dee Hock:

"Simple clear purpose and principles give rise to complex and intelligent behavior."

What if instead of a long list of norms — rules and regulations, you might say — we came up with a simple set of principles that along with our class purpose statement would help guide us through the workshop?


The first attempt at simplifying the class norms was a bit extreme. In the next class, the students decided on one principle as their norm: Participate! This one principle could inform individual choices as varied as arrival and departure times and when to return from breaks to how to use technology such as cell phones and computers during the class. We also found that the Participate! principle affected how students experienced the class. In addition to being physically present, the students tended to be more intellectually and emotionally present, as well.

This change worked so well that I decided in the next class to replace the ground rules poster with a simple poster on which was written the one word "Participate!" The team norms facilitation exercise shifted to one in which we discussed the difference between principles and rules and how using a principles approach might impact the work we did in the class. Confident that we were on to something, I decided to adopt this new approach to the class norms exercise. The principles poster with it's one word "Participate!" became a standard going forward.

For a few classes all went well... until one class, in which we learned that not all participation is desirable.  During this class, a difference of opinion between two students resulted in some unpleasant things being said by both parties. A resulting uncomfortable moment of silence was broken by one student congenially remarking, "Well... I'm not sure that's what we meant by "Participate!" To their credit, our verbal combatants chuckled and one, with remarkable humility, asked that we try out "that retrospective thing" to improve the class norms.


With Dee Hock's advice in mind, the class engaged in a retrospective to decide what to do. After a few minutes of discussion in which having and expressing different opinions was upheld as desired, the group decided that the interactions in the class could be made more effective by adding the word "Respect" to our current one word principles list. Respect would then inform the act of participation. We made this change and the class was a great success. To this day, these two principles serve as simple rules for all my classes and workshops.

What are your "simple rules"?

Look around your team environment. How do existing rules and regulations impact your team's interactions? What principles are present? Are they explicit? How do these principles inform your team's interactions? Can "simple rules" make a positive impact on your team's effectiveness?