The falsehoods in the truth

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.

Putting Lean-Kanban practices into Scrum is not the same as being Lean

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.

The Real Reason the “Agile Wars” Are Destructive – It’s Not What You Think

This was originally published in June, 2014

I am enthusiastic over humanity’s extraordinary and sometimes very timely ingenuity. If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday’s fortuitous contrivings as constituting the only means for solving a given problem. Buckminster Fuller

Continue reading “The Real Reason the “Agile Wars” Are Destructive – It’s Not What You Think”

Why Shu Ha Ri and Scrum Can Make for a Dangerous Combination

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”

Challenging Why (not if) Scrum Fails

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”

Challenging why (not if) Scrum works

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”

TDD “Good” Tests Part 3. There must be no other test that fails for this reason

When organizations adopt TDD as their development paradigm, early results can be quite good once the teams get over the initial learning curve. Code quality goes up, defect rate goes down, and the team gains confidence which allows them to be aggressive in pursuing business value.

But there is a negative trend that can emerge as the test suite grows in size over time. Continue reading “TDD “Good” Tests Part 3. There must be no other test that fails for this reason”

What I have Learned from Scrum

Here are some things I have learned from Scrum.

  • Cross functional teams are good. Just having them achieves a three to tenfold improvement over a group of people working on several projects at once. And they improve innovation by the team.
  • Time-boxing increases discipline, visibility and the ability to pivot.
  • Small batches are good and breaking work down into small pieces is essential.
  • Smaller release cycles improve most everything.
  • It is useful to have a team coach.
  • Do not expect people to figure out what they need to do just because you have put them in a framework.
  • Focus on learning the practices of a framework makes learning what you actually need to accomplish (flow) harder.
  • People like to be given a set of practices to use.
  • Defining a simple set of practices to use can lead to rigid dogma.
  • Take an approach that transitions you to the behaviors you need.
  • Approaches that work well in one context may not work well in another even though people them everywhere without noticing this.
  • And, just because you can put whatever you want into a framework, that doesn’t mean the framework is not prescriptive. In itself, the framework has things you must do.

Continue reading “What I have Learned from Scrum”

What I Think About Scrum

First of all, I like Scrum. I think it can be a great framework when used in the right place. But I also think it must be taught as a tool in your toolbox, not an end in and of itself. This means initial training of Scrum should include more of the flow model (eliminating delays in workflow, feedback and using information) on which it is based. Test-first methods should also be incorporated into this training. This combination allows for teams to avoid most of the pitfalls teams new to Scrum face. I also believe one should look to see if Scrum or Kanban is better for a particular team (or something in between). See first comment for how I do this.

See Why Agile Coaches Need to Know Both Scrum and Kanban.   

Continue reading “What I Think About Scrum”

Why Being Explicit in Workflow is Useful: Case Study, Scrum Based on Lean Flow

Scrum is a lightweight framework that encourages correct action through performing its ceremonies and practices. While that is great in theory, the lack of the “why” of the ceremonies often has them be not followed.

Consider the “sprint” in Scrum. According to the Scrum Guide, “The heart of Scrum is a Sprint, a time-box of one month or less during which a ‘Done,’ usable, and potentially releasable product increment is created.”

It implies the need to start and finish stories in the same iteration. In other words, one of its objectives is to have a short time between the beginning of a story until it is completed. Here is what this provides. Continue reading “Why Being Explicit in Workflow is Useful: Case Study, Scrum Based on Lean Flow”