Late on the second day of a three-day workshop, a hand came up a table at the back of the room. I had noticed the person getting increasingly fidgety as the day progressed. The class had just finished an exercise on controlling work in progress. Before they spoke I noticed the people at their table edging away from them. They threw down the proverbial gauntlet with the question,
“So why exactly shouldn’t I immediately start anything I am asked to do, even if I have other things on my plate? My boss always says thank you and wishes everyone else would help him out.”
One of the most common tropes in agile and lean circles is the adage, stop starting and start finishing”.This question challenged that closely held belief. Challenging closely held beliefs is where real growth occurs. This was a serious question and we had the time so I chose to involve the class in coming up with an answer to the question.
I began the discussion by reframing the question (something I was taught by a sales mentor I once had – everyone should have mentors). I broke the class up into teams and asked them to decide when the right thing to do was something new that had not been planned.
Two of the usual suspects popped up immediately (and in every team).
- When production is down.
- When the CEO tells you to do it.
During the debrief, almost no one considered the risk of pushing back ON either of these items acceptable. No one considered it possible that the CEO (or other executives) knew or cared about other work that might be impacted. I would hope they were wrong.
Some of the more interesting reasons, albeit less universal that we exposed included.
- When another team needs something for an important project (and wasn’t planned for).
- When an important stakeholder asks for something urgently.
- When a large piece of work is blocked waiting for a vendor to respond.
- We have a Service Level Objective to start working on any incident within 4 hours. (The person who called this item out to the class noted less emphatically that starting and completing were two different things – everyone laughed.)
- When I think it’s in my best interest. (Interesting this was not put on the list by the person who asked the question but rather by someone at another table who was from the same company – in-person classes are interesting).
- We have spare capacity.
The problem with the list, except numbers one and eight, is that they are tangled mess of organizational, planning, and communication failures that lead to pressure break work intake discipline. We all agreed, even the person who posed the question, that taking in unplanned work in each scenario had consequences. Individuals might accept those consequences, at least in the short term, whereas teams might not want to assume those risks. For example, the individual best interest scenario suggests that at least one person in the class was introspective enough to consider the tradeoff we all have considered at some point in our careers.
Bottom line, there are reasons people jump the work intake queue or chronically start more work than they can finish. I can’t argue with production being down, I’ve been there. So long as it is not your team’s code that caused the problem, fixing the problem is a rush. For the rest of the list, the consequences outweigh the potential benefits (sometimes it is in the long run but Piper always has to be paid).
Now that we had the reasons why we might break work intake discipline, I challenged teams in the class to consider the consequences at individual, team, and organizational levels.
Advertisement
“Mastering Work Intake”: The ultimate guide to conquering project chaos and achieving predictable delivery.
Jeremy Willets and I have written Mastering Work Intake: From Chaos to Predictable Delivery which will be released on January 9th. Regardless of whether you’re creating, enhancing, or maintaining software products, work intake is a challenge you deal with constantly. Doing the right work at the right time can make or break your project, and there are surprisingly few resources to show you how to manage this process effectively. You need to know what your team is executing, what work is next, and the skill sets required to do the work.
Jeremy and I have pooled our experiences and knowledge to create a collaboration that you will want to keep at hand as you deliver value to your stakeholders and organization!
Order your copy from
JRoss: https://bit.ly/474ul6G
Amazon (US): https://a.co/d/7nYupx5
For physical copies outside of the US and Canada:
UK and EU: https://www.eurospanbookstore.com/
For international orders outside of Europe: https://a.co/d/7nYupx5 (or the Amazon store for your country)
