Agile


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.  (more…)

 

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. (more…)

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: (more…)

 

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.” (more…)

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/

(more…)

Blackwater Falls

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

(more…)

Blackwater Falls in WV

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: (more…)

 

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. (more…)

 

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 of goals and goal setting, and this essay, in turn, is based on the presentation. This is Part 2 of a rough transcription of the webinar (note — I have moved several slides around as I have created this essay).

Read Part 1       Read Part 3

Whether we are considering goals for groups of testers or teams that include testers, there is a natural tendency to set goals that are specific to a process. Examples of areas covered by specific process level goals include code coverage, test case automation, or (god forbid) the number of defects found or defect removal efficiency. While two of the four might be valuable focus areas, none of the examples are based on systems thinking view of the output delivered from a value chain therefore rarely impact the bottom line significantly. Other than a few specific scenarios, testing, is not the output of a value chain. In a software development organization, software products that people spent money on are an output. In an automobile manufacturer, cars are the output. Every team needs to have goals based on their contribution to the value stream. Four basic metric categories that need to be considered are: (more…)

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

The Software Process and Measurement Cast 603 features my interview with Austin Chadwick. Austin and I talked mobbing, but perhaps more importantly to me, Austin talked about the impact of finding joy in everything you do. The latter was one of those serendipitous discoveries that makes the interviews for the podcast so much fun. I hope you enjoy the conversation as much as I did.  (more…)

Next Page »