SPaMCAST 559 – Time To Reinvent Agile, A Conversation With Al Shalloway

http://www.spamcast.net

 

Listen Now!
Subscribe: Apple Podcast
Check out the podcast on Google Play Music
Listen on Spotify!

SPaMCAST 559 part one of our interview with Al Shalloway. I am breaking two guidelines this week.  First, rarely do I bring guests back so quickly. And secondly, I have not broken an interview into two parts for 7 years (ish). The conversation with Al was full of huge ideas, s, concepts, and calls to action cutting any of the content did not make sense. Al and I talked about about the troubles dogging classic agile, the Agile Industrial Complex, using a scientific approach to change, and FLEX.  Edited, the interview was 49 minutes (with about 20 minutes of chit chat ended up on the cutting room floor – figuratively). I have broken the interview into two parts of approximately 27 and 22 minutes.  Today we have part one and next week we will complete the interview. 

 

Agile Techniques: Making The Daily Scrum Work

The Scrum Guide states the Daily Scrum is an event which the Development Team plans work for the next 24 hours.  Far too often teams are working on a mixture of items that are not related to each other or are assigned to team members which locks in boundaries between people.  The day-to-day microplanning envisioned by the authors of the Scrum Guide slip through the team’s fingers and land directly on sharing status especially when driven by the classic three questions:

 

Agile Techniques: When Daily Scrums Don’t Work

Sometimes doing what book says is out of the question!

When a Daily Scrum or daily stand-up are not used for micro-planning and collaborating to achieve the team’s goal, they are occurring for a reason.  Those meetings are scratching some other itch than planning, an itch that however unagile is often defended. When the goal of a daily meeting is something other than group planning there are more efficient and less expensive approaches even for highly agile teams to address status and have a social event.

 

Agile Techniques: Why Daily Stand-Ups Are Not Always The Right Answer

Every Day?

 

Daily Scrums or stand-ups are a fixture of teams, agile or not, whether they are fulfilling goal identified in the Scrum Guide or not. The Scrum Guide identifies the Daily Scrum (often colloquially known as a stand-up) as one the key events in Scrum.  The purpose of the event is to plan work for the next 24 hours. The meeting are short, approximately 15 minutes, therefore don’t feel like a huge investment of time and money. Wrong!  An agile coaching colleague, Anthony Mersino points out that the Daily Scrum has a cost.  His estimate of $60,000 – 110,000 annually for a typical Scrum team is probably conservative if you factor in the impact of gathering time and getting coffee afterward. Done well there is an offset to the cost.  The value of the meeting comes from micro-planning and collaboration that occurs during the stand-up. The issue is that Daily Scrums or stand-ups don’t always make sense, at least the daily part. Don’t spend the money for a daily stand-up meeting when:

 

Agile Techniques: Why Do We Keep Screwing Up Stand-Up Meetings

Not a status meeting!

The stand-up meeting is a simple meeting that Agile teams hold on a daily basis to plan and synchronize activities. The Scrum Guide states:

“The Daily Scrum is a 15-minute time-boxed event for the Development Team. The Daily Scrum is held every day of the Sprint. At it, the Development Team plans work for the next 24 hours.” 

Conceptually the daily stand-up is a simple event and when done correctly provides microplanning adjustments that keep a team on track. This simple meeting can be a great tool; however, it often becomes a HORROR story.  Nothing has changed since the last time we addressed the stand-up meeting in 2016. 

 

When Do Story Points Make Sense?

Story Points: No Parking

Story points are a planning tool that has proponents and opponents. Like most tools, story points are not prima facie evil, it is only through misuse that they are problematic.  Problems tend to occur because leader, managers, and team members have a need (or at least a very strong desire) to know when a piece work will be done, what they are going to do next, whether they are meeting expectations, and in many cases what something will cost. Story points are a relative measure, a proxy of a proxy that makes answering any of these questions with precision very difficult. The best anyone can hope for is that the answers story points provide are accurate enough and provide a coherent feedback loop for teams. This could be considered damning with faint praise, however, in the right circumstances story points are a useful tool for a TEAM. I am a proponent of using story points in three scenarios.

 

Story Points – Leave Them, Don’t Love Them

Story Points Are A Reflection!

Last week Anthony Mersino published a blog entry titled Story Points – Love Them or Leave Them? He ended his blog entry with the question, “What do you think?” I know it will shock some of you, but I have an opinion. An opinion born from observation, research, and hands-on experience. Story points are specific to every team that uses them. I have used and still do use story points in some very specific scenarios. To answer Anthony’s question, over the years I have migrated into the “leave them” camp with a few caveats (we will tackle those later in the week). Story Points have a litany of problems including a myriad of definitions, they are a poor tool to compare performance, they are conflated with hours, and they institutionalize bias (see The Slow End Of Story Points for in-depth discussions on these points). In the last round of articles I wrote on story points, I did not address the basic conceit at the core of story points. Story points assume that teams need to size pieces of work in order to know whether the work is too big or too risky to accomplish in a specific period of time. That assumption is wrong for any team that has worked together for more than a sprint/iteration or two and breaks its work down, plans and commits to that work, and then use the results from that sprint or iteration to improve how they work. These steps are basic activities for an Agile team. The inspect and adapt feedback loop provides an experiential platform that negates the need to have a debate over Cohn’s Numbers or an entry on the Fibonacci scale. That time is better spent discussing what the work is that is being requested by the product owner and how that work is going to be delivered.