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:
- Push versus pull,
- Story-driven versus interrupt-driven,
- Utilization maximization fallacy, and
- Flow.
Pull and push are simple four-letter words (and they are sometimes used as invectives as other more infamous four-letter words are) that are not always understood. In software-centric organizations, a simple operational definition of pull is teams accept new work when they have the capacity to do it and the work has a reasonable chance of progressing to done without interruption. Work is pulled by the people doing the work based on the capacity of the system. I recently heard a configuration specialist in a Scrum team say “I ask the product owner what’s next on the backlog when we have the capacity to do more.“ The conversation is a good indication of a pull work entry process. Push is the opposition of pull, reflecting the situation where work is given to people and teams based on the arrival of the work or demand rather than capacity or flow considerations. A number of years ago I worked for a consulting firm that used a push process between sales and delivery. The salespeople sold the work and then pushed the sold work into delivery usually with a promised start and end date.
Story-driven and interrupt-driven teams have to manage their work queues differently. Prioritized backlogs are a feature of story-driven teams. Requirements, while they may be dynamic, reflect market needs. Operational support teams are often interrupt-driven. Work comes to interrupt-driven teams in an unpredictable fashion.] I recently helped a large team supporting a large ERP package that was having fits meeting commitments they were making to their clients. The team would diligently plan a sprint (story-driven work) only to have tickets from incidents (interrupt-driven work) disrupt their plans. We split the team into two components one using a Scrum approach and the other using a kanbany form of Scrumban.
Many organizations require teams and leaders to plan for maximizing capacity utilization by planning people (often called resources in this scenario) at 100% capacity. This approach pushes work to each step in the process without regard to constraints and bottlenecks yielding lots of work started but less work completed. The focus on planning 100% utilization in software teams is potentially counterproductive because it generates planning errors and compression. All systems (human and/or mechanical) have a capacity. Read Parkinson’s Law and The Myth of 100% Utilization for more on the 100% planning fallacy.
Flow is the amount of value that travels through a process in a specific time. Flow is often measured as a function of pace and consistency. The predictability of the flow is influenced by how much work enters, how well the work is triaged and how well the team exploits the constraint in the process.
Armed with these four concepts we will explore several common team-level work entry patterns over the next two weeks. We begin with:
- Scrum By The Book, and
- Everyone For Themselves.
