We like automating things, we do software. Remove the people from the loop.

What next?

Automation is good in itself (more efficient) but the next step is to build on it. We can reach for more difficult problems, we can introduce innovation.

The thing is, when we do this we can’t automate it because we can’t understand it (yet) so we need people.

Thus we are back where we started only at a higher level.

I would argue this has happened several times already. e.g.
- Building software was hard
- So we invented make
- We started building more complex software
- So we invented more sophisticated tools
- Continuous delivery became possible

But I feel it _is_ useful to be able to talk about how forces outside of teams and development organisations affect them. These forces are often seriously underestimated (or even unknown). There, I think, the system metaphor of an organisation is nice and easy to grasp. Or do you have another suggestion?

I’ll finish off with a “poem”:

Some Things
———–
Some things… are in our minds
Some things… are external
Affect our minds more than we think

Some things… we can change
Some things… other’s can change
We can change more than we think

Some things… are unchangeable, decided
Buried in the walls
To change those
We must cease and be born again

I agree with most of what you say in your post. It’s very much along the same lines as my own thinking. On a micro level, people are much more important in software dev than in, for example, a factory setting. But something still bothers me about “The people are the system”.

Do you agree that “the system” is the context, the environment in which people are trying their best to achieve some results? If you do, that is a very big context. It would include things like office furnishing, management culture, customer agreements, outsourcing strategies etc etc, as well as obvious things like the micro process the team employs for each feature. Most of these things are beyond the power of the individuals or the teams to change, but have a serious effect on the effectiveness of their work. Only management, and sometimes not even them, can change them. This is also “the system” and it can have a very real detrimental effect on the outcome of the work even in software.

I think the statement is simplistic. I suggest this wording: “The system consist more of people than in many other areas”. Not as catchy, I’ll admit.

“If you follow a number of features from idea to deployment you will find that the “production line” is unique to each feature.”

If true, this, as they say, changes everything.

Ken Schwaber says (I’m paraphrasing): Scrum doesn’t solve your problems, it only exposes them. So my question is, when you abandon Scrum because it you can’t get it to work properly, are you doing the only right thing, or are you just avoiding dealing with the impediment that Scrum has exposed?

If the environment is chaotic and interdependent, do you really need to use a Kanban based approach, or would you be better off changing the environment, if possible. Is chaos and interdependence caused by poor code quality, insufficient training and other variables that should addressed? And could Kanban be just what you need to stay mediocre in those areas? I think the answer is yes — sometimes. But my experience is insufficiently varied to generalize about it, so I’m just pointing out the possibility.

Niklas Bjørnerstedt on February 7, 2012 at 9:19 pm said:

Hi Dagfinn,
I am aware of that possibility, it is just that it was not relevant in the case I was involved with. It was an organization that has hundreds of developers and scores of ongoing projects. These projects often involve large parts of the organization to some degree. Add to that the fact that my mandate was to help a few of these teams, not the whole organization. It would have been quixotic for me to set the goal of changing the environment. Most scrum “remove the impediments” stories are really about big projects, not big organizations where the actions of one project often have unintended consequences for other projects. A scrum of scrums is not a good solution in this kind of environment.
The case David Anderson talked about in the Meetup is also a situation where you just have to accept your environment. A startup is a startup.

Geir Amsjø on February 21, 2012 at 4:46 pm said:

Hi Nicolas,
David Anderson like to tell “Scrum stinks, Kanban is the way” stories. That is fine, but it is interesting that the examples he uses describes a bad Scrum implementation. The same goes for your story with the valiant Scrum Master. In the story there is no Product Owner, and that is probably the reason why the Scrum Master was allowed to continue with his eager team shielding practice. The Scrum Master is supposed to shield the development team if necessary. A good product owner would never allowed this bad, sub-optimal behavior to continue without bringing it up as a major problem in a retrospective.

Niklas Bjørnerstedt on February 21, 2012 at 9:10 pm said:

Geir,

Actually, there were multiple product owners on the valiant Scrum master project. Since I was not part of the project I cannot say whether this particular product owner did a good job. I find it interesting that you are so certain that the cause of the problems was a poor scrum implementation. It is dangerously close to the “if you get sick your faith is not strong enough” argument. Suppose the product owner had taken this problem up in a retrospective. The result might then have been a team that was forced to abandon most sprints. It is not always possible to eliminate the root causes of disturbances.

Some of the remedies to this kind of problem that I’ve heard in Scrum circles are based on ever more planning. That is not a road I am comfortable with.

PS Spell my name right next time…
Geir Amsjø on February 23, 2012 at 11:03 am said:

Sorry about the name spelling, Niklas. I know i have done that before also, probably because I used to communicate a lot with a Nicolas before..

In a good Scrum implementation this situation might go on for some Sprints, but eventually (probably in a retrospective) it will be detected and labelled as an impediment. And dealt with as such.
I totally agree that if 50% of your work cannot be planned for a Sprint, you have a serious problem. You can do one of two things:
1. Accept that this is how the the organization works, and it is nothing we can do about it: Go for Kanban instead of Scrum to free yourself from the iterations and the commitment.
2. Threat it as an impediment and try to solve the (organizational) problem.

In most cases (I have seen and heard about) the root cause of all these “not plannable tasks” are support cases i.e. failure demand. This should be attacked and not accepted, don´t you agree? I know you as a Lean thinker and even a Systems thinker…

Scrum is designed to challenge the whole organisation and surface problems. It is explicitly empirical. It is NOT a “project management model”. The good Scrum implementations acknowledge that and they will not allow impediments like the ones you (and others) describe live for long.

Niklas Bjørnerstedt on February 24, 2012 at 10:13 am said:

Geir,

Yes, impediments should be identified and removed… when that is possible. My point is that in certain contexts there are impediments that can not be removed. These impediments do not have to be failure demand. Some of the examples i cite are about customer demands that are so urgent that they can not be ignored. They can also arise from other parts of the organization that are outside the project’s control.

Geir Amsjø on February 24, 2012 at 12:54 pm said:

OK, now we seem to be closing in to the core issue – and I didn´t expect us to have very different positions. Impediments should be removed, the question is however, when to give in. It is a question of attitude and the urge to improve the end-to-end process. It is obviously harder to attack end-to-end problems or dysfunctions when there is another organization (a customer) owning significant parts of that process. In my mind people tend to give in too easy!

I think the heading of this article is provocative and in a way wrong. If you use Scrum you should have problems – otherwise you are doing it wrong(!) Of course it is tempting to turn away from these problems. They may be painful to fight. That is why Courage is one of the Scrum values. The framework is designed to surface dysfunctions – so that they can be dealt with.

So do Scrum fail? I don´t think so. This is a simple, empirical framework that is very adaptable. If you run into problems that seems unsolvable short term, it will most likely be possible to address more long term. There might be good reasons for not taking the fight right now, but please do not blame the framework for that.

Niklas Bjørnerstedt on February 24, 2012 at 1:41 pm said:

Geir,
I think the title of the article is correct if you consider sprints to be an integral part of Scrum. The point I am making is that sprints (and the supporting ceremonies) do not work well in some environments. In the trend towards lean start-ups there are more and more efforts that encounter these problems. At the other extreme there are organizations that are so complex that efforts to make sprints work risk pushing the organization into a planning fallacy that is very close to the thinking behind waterfall processes.

Geir Amsjø on February 24, 2012 at 3:12 pm said:

OK, I agree that in some environments I would recommend Kanban and not Scrum. That is because the nature of work is “always urgent”. No need to estimate or to plan, just do it. Use the WIP limit to improve. I recommend it because I can not see any urge to change this.

When it comes to the very complex organizations I would really encourage to move away from accepting complexity towards fighting complexity. And I would have used Scrum, even if it will be painful in the beginning.

So, yes you might say that Scrum fails in some special cases. The Sprint fiction chapter is OK. But I think it is kind of sad that far too many don´t like the pain of seeing their own problems and start blaming this framework rather than solving problems.

The valiant gate keeper chapter on the other hand is just a bad implementation or poor understanding of Scrum.