When Scrum Isn’t Agile enough
by: Jeffery Howey
I’ve rarely run into scenarios where a 2 or 3 week time frame from User Story to Release was seen as a bottleneck – especially with history working on 18-month projects in my (not-distant-enough-to-forget-the-pain) past. However, during a recent class, I was challenged by a savvy Scrummer with the question, “What if Scrum isn’t Agile enough?” It took me a moment to grasp the gravity of the question before me. Scrum? That which I espouse as an ideal (albeit, not the only) way to deliver customer value frequently and regularly?
After just a few minutes of deeper investigation, it became clear that 3 weeks was not too long for this particular querent’s customers. In fact, their customers were delighted that they could put forth a request and see it come to fruition within a month (if it was of sufficient priority, of course). It was the Scrum Team itself that was concerned that they could frequently turn around functionality more quickly if they weren’t bound by a 3 week release schedule. They, wisely, wanted to avoid Sprints that were much shorter as a majority of their backlog fit nicely into 3 weeks.
Lucky for me, the question came only 10 minutes before I planned to tackle training material that started with “Kanban: Where it fits.” Rather than delay the discussion, we tabled our deep-dive into Scrum and regained the attention of a few audience members by flipping to that section immediately.
Call it Kanban, call it Lean, call it whatever you like (I know this article will ruffle a few feathers with the use of any of these words), but the point is this: Agile itself is meant to be agile – to identify what is needed and to do it. “We value… working software, customer collaboration and responding to change,” after all. As an Agilista at heart, the goal is to deliver value as quickly and sufficiently as feasible. (note the period at the end of my last sentence)
This particular team supported a robust reporting platform that crossed multiple data sources and business units. They worked aggressively to groom their Product Backlog on a regular basis, pointed every Story, crossed every “T” and dotted every “I” in the Scrum Guide. Scrum was working well for the team and their customers. But they still felt something could be done more quickly with some of their User Stories.
The stories at issue generally revolved around minor changes to existing features – such as adding additional validation or selection criteria to reports, modifying existing data field structures, incorporating ad-hoc data from external sources into their data warehouse. During our discussion, the team indicated that initially many of these User Stories were given a point value of 1 because they were so small. After several Sprints, the team revised their pointing structure to attempt giving more valuable information with their Story Points (a noble effort) and created a new set of criteria to help the myriad “1’s” in the backlog break out into at least something through 5. This did not feel right to the team as it was not very useful to anyone but themselves for identifying effort. They then discussed combining multiple requests into one larger epic to be sized and tasked; but immediately voted down the idea (rightly so) as it was seen as simply a planning tactic and would cause confusion all around. The team was left dissatisfied as the Story Points were not incredibly meaningful and the tasking discussion during Sprint Planning often took as long as making the code change would take.
Eliminate waste! The team was ready. My only question to the team was this: “What if some portion of the team’s time was spent just working down the list of priorities?” Within minutes the team felt validated with ideas they had already discussed – but felt broke the “rules” of Scrum. They had identified that they could sacrifice one team member per Sprint to focus on these issues. But, it is not a principle of Agile to sacrifice a teammate to anything, even if the more mundane tasks were rotated. During our few minutes of brainstorming down the bunny trail, the team identified that they could carve out 10 hours of their Sprint Capacity every Sprint to focus on delivery of these prioritized requests and actually improve their overall velocity by removing the overhead of the Scrum rituals related to these small bits of work. As an added bonus, nobody had to be sacrificed.
The next steps were quickly evident. Beginning with their next Sprint, the team would modify their capacity to allow for 10 hours of time on the “Hit List” (as they called it) in a FPIFPO (that’s first “priority” in, first “priority” out) approach. Following the tenets of Agile, these were not immediately assigned to individuals – which allowed them the freedom to self-organize around WHEN the 10 hours of time would be given to the work. This also allowed the team to swarm on priority requests and work together when feasible.
The “Hit List” is now a separate piece of the Product Backlog, but is clearly maintained in a visual manner that allows the Scrum Product Owner to see the priorities across the portfolio. The team has empowered the Product Owner to guide the team’s allotment of time when needed. If there are more priorities on the “Hit List” than the rest of the Product Backlog, the team may devote more than 10 hours during their next Sprint to the FPIFPO work; or less time, if other priorities are on deck.
The kicker to this article is in the moral of the story. In the end, the team had the answer. They had tested different ways to implement the answer. There was some initial distress in the idea of jumping from the Scrum side of the creek to the Kanban side, understandably wanting to avoid confusion internally and with their customers. But a little wading into the creek built confidence that it is possible, in many settings, to wade (vs. jump or swim) the waters between Agile processes. I was happy to nudge them into the water, but through inspecting their progress and adapting to their reality, this team used their own collective knowledge and creativity to answer the question “What if Scrum isn’t Agile enough?”
Are you ready to roll up some pant legs and wade?
