Thread by @RonJeffries

There is a sense in which Scrum is quite useful as an approach to building a thing that will take some time, and a few people, to build. Followed fairly closely, with a light hand, it lets the team get the work done, while allowing stakeholders to see and guide progress.

1/16

"Followed fairly closely", however, includes the Inspect and Adapt components of Scrum. BOTH the Sprint Review AND the Sprint Retrospective are important.

2/16

The Sprint Review has all stakeholders inspecting the product, and providing guidance to the team on how to take it forward. For the Sprint Review to work, there MUST be a Product Increment to review. Without the Increment, this critical control loop is lost.

3/16

The Sprint Retrospective has the team inspecting their process of planning and building the Increment, and improving that process. In early days, teams quite often struggle to get an Increment at all. They need to learn to create smaller backlog items and complete them.

4/16

Later on, teams often struggle to maintain a consistent rate of delivery of capability in the Increment. They need to learn to evolve the design, keeping it clean and appropriate to the evolving needs of the product and its construction.

5/16

These matters should turn up in the Retrospective, and they need to be addressed. Most commonly, the team needs two things: the knowledge of how to build the Increment in the Scrum fashion, and the time and support for doing the building as it needs to be done.

6/16

At base, these things seem quite simple: review and improve the product, review and improve the process. Neither of these things is easy. In particular, building a new product incrementally, in repeated iterations of the Scrum cycle is certainly not easy.

7/16

Unfortunately, software development is a mystery to those who cannot do it. Frankly it's often pretty mysterious to those of us who CAN do it. I came to Agile ideas after a quarter of a century of very successful software development, and I still had big things to learn.

8/16

Those big things, including TDD, refactoring, continuous integration, and so on, simply did not come up in most conventional software development, nor in most software education.

But they are critical to making Scrum work.

9/16

Because software construction is an art understood by few, and Agile construction by fewer still, many would-be agile teachers, coaches, managers, product owners, and team members come to the table under-equipped.

10/16

If they'll do as Scrum asks -- really do it -- the Sprint Review and Sprint Retrospective, inspecting both the product and the process, can give them the success they deserve.

11/16

But through not knowing how different Agile development is, they often do not make space in mind or process for what needs to be done. The result is that expectations are not met, frustration builds up, pressure builds up, and things get worse rather than better.

12/16

It's kind of ironic. Scrum, when one really attends to its inspecting and adapting principles, will work pretty well in a wide range of situations. (There are places where I wouldn't start with it, but few where it would be actually harmful, in my opinion.)

13/16

And yet, because people are not aware of what's needed, they get ahead of themselves and Scrum's simple yet elegant approach never gets a chance to work. The result is often that
Scrum makes lives worse rather than better. I call that Dark Scrum.

14/16

Dark Scrum is entirely unnecessary. If the teachers, coaches, managers, product owners, and team members get a bit of education and attend to the simple (but not easy) things that need to be done, Scrum can work just fine.

15/16

Like anything worth doing, you have to do it well. You have to learn. You have to observe how you're doing and adjust when there's room to improve, learn when there are things you don't yet know.

Simple, not easy. Mostly, though, you just have to do it.

16/16