AgileIQ Blog

Are We Going to Make It?

  

 Email Article  

Tweet  

  

by Thomas Vollmer

In my previous post, I wrote about the importance of trust for effective agile development. A good way to build trust is to say what you are going to do, and then doing it.

For any given sprint, the team says what they are going to do in three major ways: definition of done, working agreement, and sprint commitment:

• The definition of done shows what actions the team considers mandatory for an item to be done. Often, different criteria are used for tasks, stories, sprints, and releases. For example, one criterion for a task to be done may be that the code is checked in and all tests pass.
• The working agreement shows how the team has decided to work together. For example, the team may require that all production code be written in pairs.
• The sprint commitment is given by the team during sprint planning, and includes which stories the team believes it can deliver that sprint.

Note that the definition of done and the working agreement are overall team agreements and not sprint specific. Also, they are very specific to any given team, and are best determined and agreed upon by that team for their particular situation.

Throughout the sprint, it is up to the team to do what they said they were going to do. Three things you can do at each daily standup to achieve this are:

1. As a team, take a quick look at the burndown chart
2. As a team, ask “are we going to make it?”
3. If not, discuss as a team what can be done in order to make it

What exact actions the team decides to take when things aren’t going well is of course critical. Helping each other out even though it’s “not my job” and doing the simplest thing possible (but no simpler) to solve technical problems are great. If that doesn’t suffice, I recommend thinking about not finishing one of the stories, which will directly reflect in velocity. This is by far the simplest to manage because the effect is immediate and highly visible. Breaking the definition of done or the working agreement (which usually translates to a drop in quality) usually causes indirect, non-linear and unpredictable effects.

In Trust We Trust

  

 Email Article  

Tweet  

  

by Thomas Vollmer

Effective Scrum depends on a high degree of trust between all team members, including the Product Owner and the ScrumMaster.

• Since the scope for a release is not fixed (only time and money are), Scrum asks the Product Owner to trust that with their help, the team is going to deliver the most value possible by the release date.
• In order to make this happen, the team needs a very strong focus on results, which ultimately depends on trust among team members.
• Scrum asks the ScrumMaster to trust the team to self-organize and deliver. In order for the team to take responsibility for results, the ScrumMaster must allow the team to fail safely when needed.

There are of course more instances of mutual trust, but the above should give you an idea.

No matter what role you play on a Scrum team, ask yourself at the end of each sprint: did we increase trust among each other?