What causes dark Scrum
- management not involved
- people lack motivation
Other reasons I see:
What causes dark Scrum
Other reasons I see:
In my earlier post I explained why we needed this. In this one I’ll describe some principles and practices that should be in it
Use some degree of test-first. At a minimum, anytime a request is made the question “how will I know I’ve done that” should be asked
An understanding that delays in feedback, workflow and between getting and using information causes unplanned work
Scrum proponents take pride in the fact that Scrum can work anywhere, in any domain. But keeping it in its generic form leaves big gaps in the practices people should be using.
The result of this is often that people have to reinvent things and don’t have ready access to concepts that would guide their adoption. These challenges are exacerbated when the immutable aspects of Scrum need to be modified a little. What often happens is people try to follow Scrum, often referring to the Scrum Guide and what they learned in their CSM class. They should be using Scrum as an open framework as it’s intended.
originally posted July 2017. Co-written by Jim Sutton and Al Shalloway
Abstract: This blog suggests that instead of looking at whether we should choose between Scrum and Kanban, we can see Scrum and Kanban as process patterns and benefit from the best of both.
Scrum and Kanban are often presented as “solutions” for developing software within an organization. Yet every real organization combines unique histories, personalities, and individual skills and beliefs. Even the best off-the-shelf “solutions” require variations to fit the context of the real organization to which they are being applied. If the adopted approach is not designed for these variations, the results will be less than hoped for.
Scrum proponents have long espoused that Scrum is intentionally simple and expect the teams to figure out what’s needed. I have never understood the validity of this approach. Simple is in the eyes of the beholder- a simple starting point may be simple for some but not for everybody. Being incomplete requires reinventing the wheel. Admittedly being more complete without adding complexity takes more effort to create. But that’s a methodologist’s job.
Talk to most any team that is having trouble with Scrum and you’ll see some common patterns of problems:
Learning how to write small stories with agreed upon acceptance criteria prior to writing code would be a good idea. Continue reading “Focus on the work, not the framework”
“We cannot solve our problems with the same thinking we used when we created them” Einstein
The team focus of 2001 is no longer viable. Early adopters could adopt Scrum without regards to the bigger picture. The key was having a cross-functional team that Scrum and XP were designed for.
But as soon as Agile spread beyond one team, it ran into challenges. Team dynamics are different from organizational dynamics. Scrum ran into problems because forming cross-functional teams required committing someone who was needed on several teams to one team. Agilists didn’t have methods that solved this problem.
I think Scrum is a good framework when it is used where it was designed for – a cross-functional team creating a new product. This, of course, represents a very small number of the time where it is used. The variation in where it is used requires a variation in the framework. This seems self-evident to me. But the response I get to this is “people need a well-defined, clear, set place to start.” I agree with this. But does it mean the place to start is the one people are promoting? I don’t think so.
From the Scrum guide, “Scrum’s roles, events, artifacts, and rules are immutable.” To me this means they are not as applicable as possible to most teams’ context since no one size fits all well. And Scrum is designed not to adapt – it works because of how it is defined.
When pressed on this, I get “we must keep it simple.” But this is the second falsehood. It implies that tailoring it to the need at hand will be more complicated. It doesn’t need to be. We must remember we need sufficiency as well – “as simple as possible but no simpler.”
My solution? Get a consultant who can quickly identify the ‘well-defined, clear, set place to start’ that works for your situation. Many consultants can do this, others can’t. Find one who can.
It’s nice to see the Scrum community finally accepting the importance of Lean and Kanban. But putting Lean/Kanban practices into Scrum does not make Scrum the same as Lean.
Perhaps the biggest different between the two is where our attention is when we have to remove an impediment. In Scrum our attention is “how do we remove the impediment by being faithful to Scrum’s practices.” In Lean, there is no attachment to any practice. Instead we ask “how do we remove the impediment by attending to Lean principles?”
In Scrum’s case, the assumption is that the team will figure out how to alleviate this impediment. But the best solution may not include having a stable team. For example, when multiple teams are working on a common codebase it may be best to dynamically form a feature team to work together (think of this as spontaneous mobbing).
This is a practice that I first used over a decade ago when test platforms were highly constrained. Immediately worked well and adoption was simple. The 7 teams that worked together to do this were following Scrum (with difficulty) before shifting to this model. Afterwards, they were no longer doing Scrum. We had to think in a Lean way to get to a Lean solution.
This was originally published May, 2017
Note: This blog assumes the reader understands the basic roles and practices of Scrum.
Scrum suggests that the way to improve a team’s workflow and the organization within which it works is to remove impediments to its core roles (product owner, team, Scrum Master) and practices (cross-functional teams, daily standups, and using time-boxing for work, demos and building backlogs). It takes an inspect and adapt approach that requires little understanding of the underlying laws of software development other than an acknowledgement that reducing the time for feedback is essential and that small batches are better than large ones.