less code, more software

is an excellent book by Jeff Sutherland, subtitled A revolutionary approach to building teams, beating deadlines, and boosting productivity (isbn 978-847-94108-4). As usual I'm going to quote from a few pages:

The most powerful part of Scrum from his [Jeff Johnson] point of view? Demos.

Scrum is not about the developers. It's about the customers and stakeholders.

I learned a lot about systems theory and how a system only has certain stable states. As a cell evolves, it moves from one stable state to another. Figuring out the rules to move a complex adaptive system from one state to another, and how to make the next state a positive one rather than a negative one, was something I spent nearly a decade on. To change a cell, you first inject energy into the system. At first there's chaos, there seem to be no rules, everything is in flux...

"How many gantt charts have you seen in your career?" I asked.
"Hundreds," he replied.
"How many of them were right?"
He paused. "None."

In business we all too often focus solely on individuals, even if production is a team effort.

It's the system that surrounds us, rather than any intrinsic quality, that accounts for the vast majority of our behaviour.

Every three weeks each team had to demonstrate to their colleagues what it was working on. This was an open demonstration; anyone could come. And if that demo wasn't both working and cool, [MediaLab] directors killed the project.

"Sprints." We called them that because the name evokes a quality of intensity.

Nothing gets moved to Done unless it can be used by the customer.

After engaging for a while in Sprints and Stand-ups, you stop seeing time as a linear arrow into the future but, rather, as something that is fundamentally cyclical.

People think in narratives, in stories.

The Product Owner has to be available to the team, to explain what needs to be done and why. While the Product Owner is ultimately accountable for the Backlog, there needs to be a constant dialogue with the team.

Orientation isn't just a state you're in; it's a process. You're always orienting... [OODA]

Some buses are busy busing people. Picking up passengers at stops. Not stopping when there are no passengers. Busy bus-y.

Suppose bus 5 picks up slightly more passengers than normal. This delays it slightly. It takes slightly longer to reach the next stop. This means it again picks up slightly more passengers than normal. Bus 5 gets further and further behind bus 6 ahead of it.

Do we understand the bus system? We have a cause and an effect which seem plausible. I've learned that saying something is a cause and something is an effect is fraught with danger. With a deeper understanding, what is cause and what is effect start to blur together. Saying this is a cause and that is an effect is a clumsy way of saying they are part of the same system.

Back to the slightly delayed bus 5. Behind bus 5 is bus 4. Bus 5's delay means bus 4 picks up slightly fewer passengers than normal. Bus 4 gets closer and closer to bus 5 ahead of it.

Now it's less clear bus 5 is causing the problem. Perhaps bus 5 picked up more passengers than usual because bus 6 ahead of it was catching up bus 7 ahead of it. And bus 7 is really the cause. But two ahead of bus 7 is bus 9. Maybe bus 9 in the cause? Or maybe we need to look at the whole system.

You wait ages for a bus and then two or more turn up at the same time! The buses are queueing just like the passengers at the stops! A trip that should take 15 minutes takes 45 minutes.

Queues will form when processes with variability are loaded to high levels of utilization without constraint.

What does the Bus "route" master do? They constrain the system.

• Buses depart at evenly-spaced fixed-duration intervals.
• If a bus is ready to go but it's not its time yet then it waits.
• They limit the number of people getting on the bus.
• They do something if people are not getting off the bus!