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.

 

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/

 

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:

 

How To Set Smart(ish) Goals For Testers Part 3

 

Last week I appeared as part of the QA Touch Virtual Series. I spoke on the topic of goals and setting goals. I used the presentation to bring together a number of ideas about goals and goal setting, and this essay, in turn, is based on the presentation. This is Part 3, please read parts 1 and 2 before reading this section.

Read Part 1                  Read Part 2

Part 3: 

Setting goals is important for deciding and communicating what you want to achieve in a specific period. Goal setting provides value by forcing a degree of introspection, acting as a filter to separate the important from the irrelevant, and as a guide to channel behavior. Like many things in life the journey is often as important as the destination; however, setting goals is complex because there several systematic problems that affect setting goals.

 

SPaMCAST 602 – Reactive Application Development, An Interview with Duncan DeVore

Play Now!
Listen and Subscribe on Apple Podcast
Listen and Subscribe on Google Podcasts

The Software Process and Measurement Cast 602 features my interview with Duncan DeVore, the co-author of Reactive Application Development. Duncan and I talked about reactive design patterns, adopting a reactive architecture, and how writing a book changes your outlook on life.  It was a really cool discussion that covered technical and non-technical topics.

 

Software Development Organizations: Preparing for Life After COVID-19 (Part 2)

There is still time to register!

This is part 2 of an essay based on a presentation I am doing Friday, June 5th at 9 EDT (sign-up: https://bit.ly/3gH0Uy5). I am presenting as part of IFPUG’s Knowledge Cafe Webinar Series. The presentation is titled Software Development: Preparing For Life After COVID-19.

Management guru Peter Drucker said, “There is nothing so useless as doing efficiently that which should not be done at all.” Benchmarking is a tool to identify work that should not be done or done better while continuous improvement provides a structure for improving the opportunities found in the benchmark. There are many approaches to benchmarking and I suggest combining qualitative and quantitative assessments.  The combination is critical for identifying how to improve effectiveness and efficiency. In a post-COVID-19 environment, all of us will need to answer whether how we are working is delivering tangible value in a financially sound manner. If you don’t know the answer to the effectiveness and efficiency questions leaders will be reluctant to spend money on you, let alone large scale improvement exercises. Once you know where you stand then begin to make changes using a feedback loop to know whether or not your experiments are working.