Team_Retrospective

The retrospective is probably one of the most important aspects of every agile implementation. In order to keep it helpful and valuable, i recommend that scrum masters and facilitators learn about different ways of conducting retrospectives and use different activities in their retrospectives, this helps in keeping this meeting interesting and fun which leads to more learning and creativity.

A customer i am working with just finished its “pilot” scrum project, to wrap up the pilot and share the learning we thought that it would be nice to have a summary retrospective.
This retrospective went really well, and in this post i will share the retrospective plan we used. Here we go.

Add a comment

Theory_Broken_Build

"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

System_Thinking

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

agile_Training

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

The_vision

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

How can we help?

Email:
Subject:
Message:
multiply one and three and get

Register to get notified about new blog posts