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

SPaMCAST 497 features our essay on micromanagement.  Micromanagement is a bane to employees that fall under a micromanager’s control. If you ask any manager if they think micromanagement is useful they will tell you no.  The problem is that many managers still do it and then rationalize the behavior.

We also welcome back Dr. Susan Parente, with her “Not a Scrumdamentalist” column.  In this installment, Susan discusses using hybrid agile methods to deliver value. The message is that the development approach needs to meld with the organization’s culture.

Gene Hughson brings the cast home with another entry from his Form Follows Function blog.  In this installment Gene discusses his essay, Getting a handle on IT costs by eliminating chargebacks?  IT costs are a chronic problem. Ideas for getting a handle on costs are always useful.

Re-Read Saturday News

In week twelve of the re-read of L. David Marquet’s Turn the Ship Around!  (Buy your copy now).  This week we tackle Underway for San Diego and All Present and Accounted For.  Two more tools that are immediately useful.

Current Installment:

Week 12: Underway for San Diego and All Present and Accounted For (more…)


A Simple Life!

The Definition of Done is an important Agile technique to help teams plan and execute work.   The simplest definition of the Definition of Done is the criteria that a work product must meet to be considered to be complete. While the concept is simple, the implementation of the technique in the real world is rarely simple. Both context and interpretations make things just a bit gray! (more…)

Danger - Keep Off Track High Voltage

I was recently asked if a story was done if when implemented it would break production. The suggestion is that since the specific code meets the requirements identified in the user story and was unit tested the team should be able to celebrate success and put another story on the backlog to fix the problem that would lead to a production failure. This, not a rare or silly question. Before we look at the reason why someone might ask this question let’s deal with a black and white answer. The most succinct answer to the question is always, “no, the story is not done”. The reason is that the story is not implementable and unless the goal of the story is blow up production and anger customers it can’t be considered done. There are four common scenarios that generate the is a story done if it breaks production question. (more…)

User stories tend to follow a hierarchy that follows the decomposition of a business need or idea into granular pieces of functionality.  That decomposition follows a basic workflow that starts when the story is voiced and ends when it is built. Along the way, each user story passes through different states that hopefully end with functionality being delivered and the story marked as done!

All three concepts are important in order to use the concept of user stories in a dynamic environment where agile and lean work is pursued.  An example is helpful to see how a user story hierarchy, flow, and states fit together.    In the following example, we will follow an automotive example to highlight the user story hierarchy, how the item impacts the user story flow, and which user story states apply to the hierarchy.  (more…)

Some states are entrances!

User stories are a way of stating requirements.  Ron Jefferies coined the meme, the Three Cs to describe a user story.  The 3 Cs are:

  1. card,
  2. conversation, and
  3. confirmation.

The idea of a card was to keep the user story short to avoid making the requirement overly complex and to avoid analysis paralysis. Because the card was a short statement of the user story, conversations are required to expose the nuances of the user story (note: nowhere does it say NOT to document your conversations. If someone tells you not to document your conversations, forget them!).  Finally, the third C, confirmation equates to testable statements that allow the team to know when the user story is satisfied. User stories might begin as nebulous statements, however, when groomed, a well-formed story provides strong guidance on the business need to be addressed.

User stories pass through four basic states. (more…)

Scrum of Scrums are about the conversation!

The purpose and composition of a Scrum of Scrums (SoS) have been discussed in detail in earlier blog entries.As a means to scale, SoS has been leveraged as a structure for teams to coordinate and plan activities between each other.  The SoS is a platform for conversations such as negotiating access to a capacity from a team with specific skills or reminding everyone that you are refreshing the test environment in a few hours. The pattern of getting people together to coordinate with a structured approach in a time box is a powerful tool. That is why the base pattern has been tweaked and leveraged for many other purposes, some of which stray away from a few basics prerequisites:

  1. You have to have more than one team. It is difficult to coordinate if no one else is involved.   Just because you are doing Agile or Scrum does not mean that you need to leverage a Scrum of Scrums. Don’t think this has not happened.
  2. Participant teams need to interact with application or capability level.  Holding a Scrum of Scrums that have no functional or capability connection will devolve into a status meeting or worse.
  3. Participants need to have a valid reason to plan and coordinate together.  Even if participants share an application, project, technology or capability, they still need a reason to plan, coordinate and negotiate together or the SoS will be a status meeting.
  4. Participants must trust each other.  Without trust no real communication is possible.

A Scrum of Scrums is not a status meeting — the world does not need more status meetings. (more…)

Preparation is key to reaching your goals.

Successful and efficient planning of any sort represents the confluence of preparing the work to be planned and proper logistics. Earlier in this series on planning, we reviewed the basic logistics needed for a planning event and defined a simple checklist.  While both are important, preparing the work to be planned requires more effort.  Preparing the work for planning requires knowing the capacity of the team and grooming the work items (stories, requirements, support tickets and/or defects). (more…)

Next Page »