Skip to content

Instantly share code, notes, and snippets.

@bforrest
Last active January 24, 2023 21:41
Show Gist options
  • Save bforrest/20f628f7a51693c43560efb7eb3ca749 to your computer and use it in GitHub Desktop.
Save bforrest/20f628f7a51693c43560efb7eb3ca749 to your computer and use it in GitHub Desktop.
An experimental way of working

An experimental new way of working

At the heart of agile software development is the first enumerated principle from the Manifesto for Agile Software Development:

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

We have fallen into a pattern of not having demonstrable software when an increment concludes. There are heavy sighs when the question arises of what is there to show at product review.

I propose remedying this unvirtuous cycle by trying an experiment. This radical idea is to focus on The Most Important Thing. We spend time bandying about number of developers and weeks. We don't spend much attention to what is Important. If something is important we should attack it with virgor and defer new work until completing Important Thing.

This approach ensures that things get completed. Time spent 'in-progress' for the Epic is minimal. We've all see the task/story that sits at 80% done for 99% of an iteration. When three of four tasks are complete we are still left with an in-progress item of importance and value. Not until completed delivery does the work benefit our customers, and patients.

Swarming (or Ensembling) the Important Thing may also improve the sense of belonging and comradery. There is potential for deeper understanding of our code base. We may even have code dreams like David ;-). Pull request code reviews are nice, but don't always provide full context for the performed work.

Reduced context switching is great benefit of focusing on the Important Thing. Visible progress towards quarterly objectives is another benefit. According to The DevOps Handbook, “the improvement of daily work is more important than daily work itself.” Dedicating time, resources, and manpower to reduce context switching and enable the fast flow of work sets a strong foundation for organizational success. I've described this to Tony as starting a jigsaw puzzle, getting all of the border pieces assembled and then sweeping it onto the floor because the next work item is in a different box with a completely different scene.

When and how are we refining work for those epics?

One of my favorite agile principles and something to pay particular attention to:

Simplicity--the art of maximizing the amount of work not done--is essential.

One way to maximize work not done is to defer refining Epics until the team actually has capacity to do the work. Discussions before the team is able to start development are likely outdated at best and wasted effort. We currently have 47 open Epics and 9 of them predate Nick and I joining the team.

Exploratory conversations with stakeholders are a good idea. These should focus on what makes the work valuable, large, or difficult. This information helps show the importance of work and set priority for the team to develop.

Refining Epics should focus on two key questions. What makes it valuable? What makes it big? Solving for valuable and attacking large empowers focus, and prevents both feature and scope creep.

Refinement should expose dependencies that could block delivery. We need to reframe ticket containing a solution. We need to understand the end user's desired outcome or key goal and empathize with the to do real work. This will speed medication to patients who need it.

How will we handle refining new work that comes up for an epic as we work through it?

This is an interesting question. IF we've agreed on what makes the work valuable, that is large, difficult, or hard, we should not discover new work. Should we discover new work, my personal opinion is that the standup is the perfect place for this discussion. Remember, our Daily Standup? The Scrum Guide defined the Daily Scrum for formulating a plan for the next 24 hours. Are we not as a team empowered as a team to huddle and figure stuff out as needed? This is Important Thing afterall and will speed medication to those who need it.

How will interrupt work be handled?

There are questions and objections around interrupt work. Is the interruption more important than the Important Thing(tM)? Does it rise to the level where all development must stop so we can focus our attention on it? Then that is now the more important thing and everyone should now focus efforts on that, with gazzelle like intensity. If this is not true, it goes to the pile of stuff that is not most important to be stack ranked the next time we roll through a refinement session/itteration planning.

What if an epic becomes blocked?

Well, my friend, how important is the result of all of this planning and work? If it is "Giant Eagle" important, then let's get all hands on deck and unblock it. After all, this is the most Important Thing. If it becomes blocked and is not the most important thing, then it gets shelved until such time as it is no longer blocked. Those tasks for the Epic that were completed and deployed will remain in the wild awaiting the completion work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment