I recently had an engineer ask me, “Why does Scrum make me work so slowly? I felt like I was getting a lot more done before we started using Scrum.” It’s a fairly common question, so I thought I’d post the answer I gave him and a few details that came from our discussion.
His frustration came from the fact that he bought into the myth of multitasking. The more correct name for “multitasking” is Rapid Context Switching (RCS)—a skill that humans don’t really have. Nevertheless, he felt like he was accomplishing a lot because at any point in time he would have four or more projects in progress. He felt that it increased his credibility among the engineers if he could provide a long list of projects whenever someone asked him what he’s working on, and he would look back at each day with great pride for having been able to move each project forward a bit. He measured his contribution in lines of code. There are, however, problems with that approach.
First, all of his projects were always in motion right up to the final deadline. As he crossed the finish line, he would do a Big Reveal to show his team which ones were finished and which ones weren’t. He couldn’t do it before the last day of the project because he didn’t know himself which ones he would finish. His failures to deliver, combined with the surprise factor at the end of the project, would launch the rest of the team into a scramble to account for his missing code. As you can imagine, he wasn’t very popular among his peers, but management loved him because they saw him as the guy with the highest bandwidth. He had fooled them into measuring work in progress rather than work completed—which brings me to the second problem with this approach.
As a software engineer, you create value when you have user-relevant code working correctly in production. Until your code is available for revenue generation, you really haven’t contributed any bankable value for the company.
Finally, the RCS approach usually increases the time to delivery for any given project. It emerged because we as an industry were too indulgent with un-prioritized pools of work; the scatter shot approach increased the odds that you had done the right thing. But Scrum removes that problem altogether by insisting that the process starts with a triaged backlog, ordered by business value. With that clarity, we no longer have to guess how to maximize our contributions.
We have to change how we think about value contribution and we have to shift our rewards to be in line with this new realization. We have to stop encouraging people to declare success and walk away until the code is in production and working to generate revenue for the company. In short, we have to measure people by what they complete, not what they start.