In June of 2012, I gave a presentation to the PMI Agile Interest Group in Atlanta about my team’s journey from using the Scrum methodology to more of a Scrumban process.
Why move to scrumban?
- One of the issues was was the additional stress around completing stories on the scrum board by the last day to avoid “failure.” Along with the pressure of solving new problems in the course of true R&D style development, the team felt pressured to (1) take shortcuts to complete work early enough, and (2) shortcut testing to close the story and claim the points. Regardless of the percentage of stories completed by sprint’s end, we determined that the average velocity over most three-sprint periods remained roughly the same.
- A second problem was the team spent a full day or more (out of 10) doing detailed tasking, in order to come up with estimates that led to incomplete stories and stress at the end. We also recognized that when starting a new story mid-sprint, we’d have to revisit the initial conversations anyway, when details were invariably forgotten. Also, based on the previous bullet, that the reliability of the projections wasn’t high to begin with.
- A third problem was that with a group of stories to complete, each team member started on a different story at the same time, which prevented collaboration and led to lack of focus.
What was the result?
Does Product Management Care about Scrum vs. Scrumban?
I argue that Product Management can manage Agile better under Scrumban than Scrum, especially when there’s a single person serving as product manager and product owner–because there’s less time-sensitivity around the product owner’s need to be present in the room with engineering.
The business still wants to know when things are going to be done–so it’s still important to ensure everything else (proper discovery, obstacle clearance, etc) is taking place to expedite timely delivery.
Here’s how it helped us:
With robust engineering practices around test-driven-development and especially behavioral-driven-development, the product owner’s information was captured during story elaboration when a feature is started. The team thinks through all the scenarios and details one or more stories to support them, with all scenarios for each story captured in English-derived Gherkin.
The team then gets to work and calls the product owner when the software is able to pass those specifications–and obviously, when questions come up. This process allows ample time for the product owner to engage in expectations management throughout the organization, requirements gathering, customer development, and all the other fun things a product manager is responsible for…..like meetings The PO needs to be available to see stories demonstrated once they’re ready for the “Done” column – and to answer questions when they come up.
Long term, velocity also improved by 20%. That also makes Product Management happy!