"Eventually, they may even break into the building"

Starting 1985, and more intently after the election of Mr Rudy Giuliani as Mayer of New York, the hypothesis behind Broken window theory was implemented in an effort to reduce crime rate in the city. Most known elements of this initiative were "quality of life" and "zero tolerance".

"The broken windows theory is a criminological theory of the norm-setting and signaling effect of urban disorder and vandalism on additional crime and anti-social behavior. The theory states that maintaining and monitoring urban environments to prevent small crimes such as vandalism, public drinking and toll-jumping helps to create an atmosphere of order and lawfulness, thereby preventing more serious crimes from happening." Source: Wikipedia. Emphasis added.

Add a comment


While i expect this to be rare and unfamiliar to most of my readers, in some organizations there are managers that sometimes complain about teams, specifically about their productivity and quality. As an external, i often do not have the knowledge to really form an opinion about this, and as a developer i have my gut feeling and instinct, and to be honest, sometimes when i look at what the team is able to produce in a single iteration i think that: Indeed this seems like not a lot of functionality for 7 people to achieve in 2 weeks. 
While this is all good and nice, this is not a good enough tool to analyze the dynamics that lead to the problem in productivity.

Add a comment


Every so often I get a request to bring Agile to the organization, but without the extra stuff.

Here are some examples:

  • We want to do Scrum, but without the self organization stuff. Just the Scrum part.
  • Teamwork is not important for us. Anyway each person gets his plans from me.
  • I want them to do Agile, only after I finish writing the architecture specification for them.
  • We want the exact same agile across all the organization. Please make sure everyone adheres to the process that we have defined.
  • We're doing Agile for X years now, and they haven't figured out how to plan a release.
  • And the list goes on.

In an analogy, consider the following statements:

Add a comment


Ship at sea״I know that I want to invest more in retrospectives and in learning. But I never have the time. Reality is too important to let secondary things like fluffy meetings to manage our precious time".

Sounds familiar?

The important takes second place to the urgent.

Why is that? Why is the urgent always attacking us at the worst time, crumbling all our plans to dust?

In most cases I encounter, explaining the reason is dead simple and extremely hard to do. It boils down to: we know we're not on the right path, but we also don't know what the right path is.

Add a comment


Ever so often I encounter a question along the lines of: "We have two-week iterations, and we didn't finish our scope. Can we make this iteration three weeks instead of two?"

The answer is: you can, but you should not.

To understand this it's important to understand what an iteration is.

Let's start with what an iteration isn't:

An iteration is not a release. It could end with a releasable product, but the iteration in itself is not a release. A single iteration could include several releases of the product, or multiple iteration could form a single release of the product, or a single product increment could be release every iteration. All three options are game.

An iteration is not a version. A version is a specific increment of your product or portfolio, and there is no link between iterations to versions.

An iteration length is not variable. Well, at least not frequently. Iterations' length should be fixed.

An iteration is not a planning artifact. OK, this is more tricky. Iterations are very useful in planning, and very handy in forecasting releases. But they are not an artifact used in a plan like the X-axis of a Gantt chart is. 

So what is it then?

Iterations are instances of time in a predefined cadence. As such, iterations are instruments to measure the current pace of a development team (typically software), and, as such, are also instruments to plan ahead by forecasting the expected pace of the team.

Add a comment