Work Entry – Patterns

Work entry, in its simplest form, is the steps needed for work to be triaged to ensure that it is the right work, that it is ready to be worked on, and the priority of the work. A simple work entry process for a Scrum team includes the following steps:

• People write stories, ideas, or requirements of varying quality,
• Those items are evaluated and cleaned up,
• Updated, well-formed stories are added to the backlog (become product backlog items – PBI),
• Once on the backlog, PBIs are prioritized (and re-prioritized), and
• In time, PBIs are pulled into a sprint.

A team’s work entry process is only one step in a value flow. Work entry gets a piece of work to the front door, after which planning, building, and delivering the PBI has to occur.  However if too much work is forced into the team, or the wrong work is available, or if the team is constantly interrupted by higher priorities, delivery will suffer. This is not the step to mess up.

There are numerous common patterns of behavior for bringing work into a team. One is the gold standard and the rest are a series of compromises. The patterns are:

1. Prioritized, Single Point of Entry
2. Prioritized Pull with Prioritized Incident Push
3. Front Door Pull, Back Door Push
4. Prioritized  and Unprioritized Push with Incident Flow
5. Free For All

We begin with the two bookends’ the single point of entry and the free for all scenarios. 

Prioritized Single Point of Entry 

In the single point of entry scenario, a team’s work funnels through a single person (usually with support and advice) that prioritizes the work based on a set of criteria. In agile, this is the process a product owner follows to work a backlog. The team pulls the work from the backlog as capacity is available to start and complete work with minimal delays. This is the gold standard for work entry at the team level. 

This work entry process is useful for avoiding five of the 8 causes of work entry problems: 

         ✓ Difference in goals

         ✓ Need outstrips supply 

  Pay practices

  Project v Product Perspective

        ✓  Urgency/importance dichotomy 

  Class of services

        ✓  Control

        ✓  Yes’itus 

Delivery Pattern: Priority Order (close to first in, first out)

Ability to Deliver: Predictable

Free For All

In the free for all scenario, each person on the team sees themselves as a free agent out to maximize the perception of their individual utility so they accept work as they see fit. Work is either pushed to the team or individuals or individuals pull work without This is the worst-case scenario for work entry. This approach solves none of the 8 causes of work entry problems and is always a reflection of deeper issues in the organization. 

Delivery Pattern: Unpredictable 

Ability to Deliver: Inconsistent

Next the middle three!

 

SPaMCAST 647 – Fixing Work Entry, Hybrid-Agile, Essays and Conversations

The majority of work entry problems are caused by eight problems. The eight problems often occur in clusters and are a reflection of organizational culture.  Knowing that there are eight problems is useful when they can be recognized. Unless people wear their motivations on signs hung around their neck, recognition requires conversation and observation.  Fixing any problem starts with recognizing that problem. 

We will also have a visit from Susan Parente who brings her, Not A Scrumdamentalist column to the podcast. Today Susan and I discuss the concept of Hybrid Agile and the new book Hybrid Project Management https://amzn.to/3al4b4F that Susan wrote with Mark Tolbert

 

Re-read Saturday, Fixing Your Scrum, Week 10, Chapter 10: Sprint Planning

Chapter 10 in Fixing Your Scrum, Practical Solutions to Common Scrum Problems, by Ryan Ripley and Todd Miller, dives into planning.. Sprint planning one of the major events in Scrum. All sprints should start with planning (not planning is one of the silliest but common antipatterns). Todd and Ryan begin the chapter by reminding the reader of the definition of sprint planning and the output of the event. The outputs of planning are a sprint backlog containing a forecast, the Sprint Goal, and knowledge. I am always amazed by the amount of information and knowledge generated during planning, as the whole team knows what they are going to tackle and how they are going to tackle it.  Planning is a TEAM EVENT. The scary part of this chapter is that none of the antipatterns Todd and Ryan identify in this chapter are common. 

 

Work Entry Definitions

Linking The Pipes

How work comes to a team and the decision process deciding which work to start is the definition of work entry. Every team has a work entry process. Work entry ranges from highly controlled (Scrum for example) to everyone for themselves. The term, work entry, doesn’t have the fuzziest, user-friendly feel to it, however, you ignore this process at your own peril.  It is the single most important determinant of whether an organization, team, or individual is going to embrace the ideals of the agile mindset. Understanding work entry requires grasping four concepts:

 

SPaMCAST 646 – Reduce Cost and Risk With Off-Premise Infrastructure, A Conversation with Albert Ahdoot

In the Software Process and Measurement Cast 646, Albert Ahdoot and I focus on discussing the impact of strong off-premise infrastructure on the delivery of value, the impact on the bottom line, and the mitigation of risk.

 

Re-read Saturday, Fixing Your Scrum, Week 9, Chapter 9: Thinking In Sprints

Chapter 9 in Fixing Your Scrum, Practical Solutions to Common Scrum Problems, by Ryan Ripley and Todd Miller, tackles the sprint. To paraphrase the Beach Boys

Everybody’s gone sprintin’

Sprinting’ Scrum-i-a

Along with the Daily Scrum, the sprint has become ubiquitous. The technique of timeboxing using a sprint is one of the first indications that a team is using Scrum. As with any powerful and useful technique, there is a natural tendency to bend, fold, staple, and hybridize the idea leading to all sorts of different problems. I have worked teams that adopted one-week sprints (and got a huge value from the quick feedback) and I have run into teams with multi-month sprints (these almost always end up ending badly). The Scrum Guide (new version), as the authors point out, states that sprints are one month or shorter. The sprint is a timebox in which work is done and a scaffold for the Scrum events.

The first of the antipatterns that Todd and Ryan tackle is one of the most common that I observe, the need for a special Sprint. There are nights when I lay awake contemplating the possibility that someone or some school somewhere is teaching newly minted Scrum Masters to add special sprints. Todd and Ryan point out any number of different variations on the special sprint theme;  sprint zero, design sprints, development sprints, integration springs, hardening, testing, bug, and planning sprints.  Maybe even sprints for sprints. In the end, what is being described is a timeboxed waterfall approach. If I was going to do waterfall I would want to timebox, but I would not call them sprints NOR would I try to rationalize that this was any form of agile. These special timeboxes are an attempt to deal with organizational issues that can span organization design or lack of training without addressing the underlying problem. A classic example of this issue is the testing sprint (development is done in one sprint and then testing in the next). Having written a few lines of code in my career facing this type of scenario, I can assure you that trying to get back into the same frame of mind as you were when you originally wrote the code isn’t easy and causes a lot of rework and technical debt. These types of issues are often dismissed as “culture.”  Remember that culture is a choice, not an excuse. 

Another of the common antipatterns is the “variable-length sprint.” Honestly, until three months ago I would have said that I had not seen this antipattern in nearly half a decade. People who don’t like timeboxes generally have gravitated toward Kanban or gone back to waterfall. To my shock, when gathering information to bid on a piece of work, I ran into an organization that blithely announced that they regularly changed the length of a sprint because they weren’t going to get everything done (they also had a testing sprint afterward). The product owner was less than sanguine as she had zero idea of when anything would be delivered and spent a decent amount of time making excuses to customers. I did not bid on the job and note on LinkedIn. Unfortunately, I now have encountered this old bugaboo several more times (all in one geographic area). Some of the issues reflect the lack of knowledge needed to break work down, having hit a velocity standard, or the ability to control work entry. Changing the sprint length does not address the root cause of the behavioral problem, but rather masks them.

The sprint is one of the most ubiquitous artifacts of agile, even when they are not using Scrum. Sprints are timeboxes that help teams to focus on delivering a specific goal and then get feedback quickly. Sprints are great but don’t work well when they are modified to hide organizational problems. 

The Coaches Corner in this chapter hit home for me the second time I read the book. The value of works like books, blogs, and podcasts change as we encounter situations in our careers. The exercise in the coaches corners provided me with ideas to help a group of people doing very different and unrelated work identify the common parts of their work-life so they discover how they could work together a little (and a little better). 

 If you have not bought your copy — what are you waiting for? Fixing Your Scrum: Practical Solutions to Common Scrum Problems 

Previous Installments

Week 1: Re-read Logistics and Front Matter – https://bit.ly/3mgz9P6 

Week 2: A Brief Introduction To Scrum, and Why Scrum Goes Bad – https://bit.ly/37w4Dv9 

Week 3: Breaking Bad Scrum with a Value-Driven Approach – http://bit.ly/3stGc9Q 

Week 4: The Product Owner – https://bit.ly/3qpKvSn 

Week 5: The Product Backlog – http://bit.ly/3cAEk9c 

Week 6: The Development Team – http://bit.ly/2OLVAAs 

Week 7: Embracing The Scrum Master Role –  https://bit.ly/3m0HB5D 

Week 8: Management – https://bit.ly/31Kv39l 

 

Teams: Organizational Attributes

Teams don’t live in a vacuum. Every team is an intersection of boundaries of all sorts of organizations. Organizations facilitate teams to a greater or lesser extent. In the workplace, the employer’s organization will have the most significant impact on how teams form and perform but it is not the totality. Other influences can affect the structure and performance of teams. In the short run, many organizational factors are difficult and slow to change (not impossible).  Many of the behavior factors noted earlier in this thread might be an affectation of the organization. A few of the most critical attributes to consider are:

 

SPaMCAST 645 – Getting A Handle on Data Security, A Conversation with Paul Katzoff

The headlines of 3 and 4 April 2021 are stark – the data of 533 million Facebook users available on the web (change your password now).  You have 533 MILLION reasons to take Paul Katzoff’s message on data security to heart.

 

Re-read Saturday, Fixing Your Scrum, Week 8 – Chapter 8: Management

Chapter 8 in Fixing Your Scrum, Practical Solutions to Common Scrum Problems, by Ryan Ripley and Todd Miller tackles management. The gap between labor and management is an age-old problem. I am sure that the artisans and workers that constructed the pyramids had their own version of Dilbert. The focus on the team, a core tenant of agile and Scrum, is perceived as exacerbating the management versus worker dichotomy. By identifying anti-patterns and proposing approaches to solving those issues this chapter is useful for bridging the gap. 

 

Teams: Behavioral Attributes

The second category of attributes that are important for teams to be effective is behavioral attributes. These attributes describe how individuals and teams as a whole act. While the first category, skills is about the individual, behavior is about the team as a group. All team members’ behavior should contribute to how the team works together to meet it’s goal. The most important behavior attributes are: