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.
Continue reading “Why Shu Ha Ri and Scrum Can Make for a Dangerous Combination”
This was originally published in May 2009
Virtually 2 years ago I wrote a blog called Challenging Why (not if) Scrum Works. Basically, I was looking to see why Scrum worked so I would be able to best take advantage of Scrum. I believe Scrum works very much due to the structure of the team, the iterative nature of development and the proper context within which the team works. In this prior blog, I reported my experience with teams that were co-located, had all team members work together and worked on only one project compared with those who were not co-located, had team members of different roles report to different managers so they were not always working together and these same people were typically on 3-5 projects at once. The co-located teams were three times more productive than the other ones – even though the people, domain and customers were virtually the same. I thought this was a great insight for two reasons. First, it meant if you couldn’t deliver (or even build) in increments, there were things you could do to improve your development methods. Second, if you could do incremental development, these practices were some of the first things to implement.
Continue reading “Challenging Why (not if) Scrum Fails”
This was originally published in May 2007. Minor edits made. I have left the # of years the same to keep context.
I have repeatedly heard that “Scrum succeeds largely because the people doing the work define how to do the work” (see From The Top by Ken Schwaber for his full text). However, I do not think that is even a third of why Scrum works – and be clear, I am certainly not questioning that Scrum works – I just want to get at the why it works.
Continue reading “Challenging why (not if) Scrum works”