Impact-Driven Scrum Delivery brings together Scrum’s capacity to deliver working software, with the ability of Impact Management to define actionable metrics, and to evaluate outcomes well before the production of working software. The idea of "outcome over output", lately emphasised in the Agile community, can now be realised in all types of projects – not only those where it is feasible to do the measuring by releasing the proposed new solution to a small percentage of real-time users. Finally, Impact-Driven Scrum Delivery solves "the Product Owner’s dilemma", and makes the management ideal of "pivot or persevere" an inherent capability of the process.
Implementing Scrum involves adoption of a new paradigm across the organization. In most instances, the severe level of culture shift and change aren't really appreciated. Once people get into the change process, they realize what they're facing and try to backtrack. Very often soft options — such as Scrum-but, Scrum in a Waterfall wrapper, or "our version of Scrum" — are inadvertently or purposely taken, and chaos ensues
There is no such role as project manager in Scrum. But there are project managers in the organization. So what is the project manager supposed to do when the team is transitioning to Scrum? The easy part is that this question has already been asked and answered so many times. The hard part is that the answers are different and sometimes contradict each other.
"Scope creep" is a term that I see being used by Scrum teams. I've always wondered if this term smells of inadequate Scrum implementation. It's an indication of traditional project management that's disguised in the appearance of Scrum.
I recently was asked this question: "Typically, does the ScrumMaster have stories in any given sprint that track for iteration planning, backlog refinement, or any other sprint/Scrum tracking activities? Or does the ScrumMaster's time fall outside the velocity for the Scrum team?"
People who have experienced good stand-ups will generally know what can be done when things aren't working well. This capability is obviously less likely for people with limited experience to reflect on. I've written this paper as an attempt to partly compensate for inexperience by describing the benefits and consequences of common practices for daily stand-ups. These patterns of stand-ups are intended to help direct the experimentation and adjustment of new practitioners as well as provide points of reflection to experienced practitioners.
If you have, as most people do, two-week iterations, you will hold, more or less, 20 retrospectives in a year. Running such a number of retrospectives becomes an interesting challenge. How do you keep your team focused during retrospectives? How do you avoid retrospective monotony? How do you find ideas for a different and original retrospective in each iteration?
There’s a lot of buzz on Kanban right now in the agile software development community. Since Scrum has become quite mainstream now, a common question is “so what is Kanban, and how does compare to Scrum?” Where do they complement each other? Are there any potential conflicts? Here’s an attempt to clear up some of the fog.