Does Meeting Overhead Scale In Scrum?

Is a baby just a scaled down adult?

One of the most common complaints about using Scrum is the amount of meeting time.  In How Much Meeting Time, we used the meeting length recommendations from the Scrum Guide for a one month sprint to calculate the meeting burden rate. The number was 22.5%, assuming everyone is involved in each meeting and the meetings toe the line in terms of the guidance provided. One of the common recommendations to mute the meeting overhead problem is to use shorter sprints or iterations. 

 

How Much Meeting Time?

 

Meeting Time Is Not Always The High Point Of The Day

If you have ever performed as a Scrum Master or agile coach you have been asked about the overhead in Scrum. Overhead is almost always a codeword for meetings where “stuff” happens but nothing is built, coded, or tested, which in a software-centric scenario will drive a coder or tester up a wall. If we exclude (for the time being) some really bad practices that have been promoted and adopted, the amount of time in Scrum specific meetings is generally predictable.

 

SPaMCAST 606 – Seriously Good Software, A Discussion With Marco Faella

Play Now!

Listen and Subscribe on Apple Podcast
https://bit.ly/3fmn1IAListen and Subscribe on Google Podcasts

The Software Process and Measurement Cast 606 features our interview with Marco Faella, author of Seriously Good Software: Code that Works, Survives, and Wins. Marco and I discussed quality, craftsmanship, and how being a passionate coder and academic mix. 

Marco Faella teaches advanced programming at a major Italian university. His published work includes peer-reviewed research articles, a Java certification manual, and a video course on Java streams.  

 

Announcements

Announcements

Happy Saturday!  In the United States, today is the 4th of July, which is Independence Day. Personally, more importantly, it is my wife’s birthday.  This is the long way around telling you that we will not have an entry of Re-read Saturday. We will be back next week with Chapter 4 of Tame your Work Flow. Catch up on previous entries 

Week 1: Logistics and Front Matter – https://bit.ly/2LWJ3EY

Week 2: Prologue (The Story of Herbie) – https://bit.ly/3h4zmTi

Week 3: Explicit Mental Models – https://bit.ly/2UJUZyN 

Week 4: Flow Efficiency, Little’s Law and Economic Impact – https://bit.ly/2VrIhoL 

Remember to buy a copy of Tame your Work Flow to support the authors and blog!  

More announcements!

Patterns Podcast: The first full episode of the Patterns Podcast has been posted on YouTube. In the first full episode, Ben Wozniki and I tackle the concept of User Stories. User Stories are a ubiquitous feature of Agile implementations.  We have posted the video on our YouTube channel.

https://youtu.be/h_fId4D6NFA

We would love to have your feedback. I will not throw a 200 mg file in the audio podcast feed again (we might create another feed). 

Tom Cagley and Associates Website: We are days away from a website that brings everything together, my company, the blog, and the podcast. We will also be kicking off a newsletter in later July. We are still in the design process so I would really like your input on what makes a great newsletter. One of my favorites is Tim Ferris’s 5 Bullet Friday.   Email me at tcagley@tomcagley.com.  Feel free to send a sample. 

Software Process and Measurement Cast: The Software Process and Measurement Cast 606 posts tomorrow (listen to SPaMCAST 605) and features our interview with Marco Faella, author of Seriously Good Software: Code that Works, Survives, and Wins. Marco and I discussed quality, craftsmanship, and how being a passionate coder and academic mix.

 

An Agile Team In A Waterfall Company – Organizing Around The Product Flow

Focus On Flow

Helping an individual agile team interface with a waterfall organization is only a stopgap measure.  At some point, the level of noise and frustration generated between the team and the organization will wear everyone down. This will end up in a lose-lose outcome. Taking the three-steps outlined before today will reduce the conflict and pave the way for change. The steps suggested are:

1. Prioritizing Work Entry (discussed in An Agile Team In A Waterfall World)
2. Postponing Commitment (discussed in An Agile Team In A Waterfall Company – Postponing Commitment)
3. Addressing Values, Principles, And Behaviors (discussed in Values, Principles, And Behaviors

To affect the direction of change and to deliver maximum value requires organizing people and teams around the flow of value in your organization. Modifying Steve Tendon and Daniel Doiron’s definition of flow a bit (from their new book Tame Your Work Flow which is being discussed on Re-read Saturday, “the amount of work or value delivered per unit of time while speed is how fast work moves through the value chain.” The definition provides a framework to consider throughput using a systems thinking perspective (think big picture).  Steve and Daniel define 4 types of flow:

 

An Agile Team In A Waterfall Company – Values, Principles, And Behaviors

 

Much has been written on the distinction of being agile versus doing agile. The crux of being agile is embracing the values and principles that underpin agile. Those values and principles are compiled in the Agile Manifesto and have been tweaked and restated many times, but they boil down to the same basic ideas. Organizations that cherry-pick or decide that culture that is inferred by the values and principles are only for parts of the organization will not get the value they are looking for. That is a failure in adoption not a failure of agile culture. Helping an agile team interface with a waterfall organization is the same as asking can we be agile when everyone around us is doing something different. The answer is sort of.  So far in this theme, we have explored two potential changes within the team’s span of control that can “help.”

 

SPaMCAST 605 – Product Owners and Retrospectives, A Conversation With Jodie Kane

Play Now!
Listen and Subscribe on Apple Podcast
https://bit.ly/3fmn1IAListen and Subscribe on Google Podcasts

The Software Process and Measurement Cast 605 features our interview with Jodie Kane.  Jodie and I discussed involving product owners in retrospectives. Jodie suggests the answer should not be cut and dry but rather context-driven.

Jodie is a passionate, value-driven servant leader with a unique, energetic style that brings out the best in people and opens space for teams to be self-organizing high performers focused on delivering customer value and getting things done.

She has spent a lifetime honing her servant leadership skills, inviting people to work together, and creating space for human engagement to develop innovative, self-organizing, value-driven teams. 

Contact Jodie on LinkedIn at https://www.linkedin.com/in/jodieenglekane/

 

Re-read Saturday, Tame you Work Flow Week 4: Chapter 3 – Flow Efficiency, Little’s Law and Economic Impact

Tame your Work Flow

Self-knowledge is valuable to keep yourself reigned in, I really think Little’s Law is important. This week I needed to make sure I did not go overboard in discussing the ramifications of the theorem (I will include links at the end of this week’s re-read for those who want to go into depth). Chapter 3 of Tame your Work Flow is incredibly important for understanding the overall book. In your re-read spend the time needed understanding how the themes noted in the chapter title Flow Efficiency, Little’s Law and Economic Impact inter-relate.

 

An Agile Team In A Waterfall Company – Postponing Commitment

A waterfall precedes and follows rapids

Agile teams living in a waterfall organization can have a tough road to travel. The degree of difficulty is often a reflection of the team’s sphere of control.  As noted in An Agile Team In A Waterfall World,  there are four areas that need to be addressed if an Agile team is going to thrive in a waterfall environment.  They are:

1. Prioritizing Work Entry (discussed in An Agile Team In A Waterfall World)
2. Postponing Commitment
3. Engaging Executives On Agile Values
4. Value Chain Analysis

 

An Agile Team In A Waterfall Company

Falls or rapids?

I was recently asked about interfacing an agile team with the rest of a “waterfall” company. This is not an uncommon theme in the questions that I receive.  A synopsis of the scenario I was given at the start of the conversation follows: