Tag: continuous improvement

Agile Assessment

Many organisations and teams that adopt Agile come to the point where knowing how agile they are becomes an important question. It’s especially important when first stages of Agile transformation prove to be successful, teams finally work at a sustainable pace and it becomes more difficult to identify obvious areas for further improvements.

There are many agile assessments available (please refer to a great blog post by Ben Linders), but none of them fit to my needs 😉 and therefore I ended up creating my own evaluation. It’s grounded on an assessment presented by Dean Leffingwell in Scaling Software Agility:Best Practices for Large Enterprises, but I made several adjustments based on my experience from working with various Agile teams and projects.

The assessment is a great input for the team to improve. Moreover, if you have more Agile teams working together, the assessment can be a vital source of information for Scrum Masters and management that should enable them to work on organisation-level impediments preventing the teams from working even more effectively.

The assessment consists of 66 statements/questions grouped in 7 areas: product ownership, agile process, team, quality, engineering practices, fun & learning and integration. Every team member should assess each statement using a scale from 1 (the worst) to 5 (the best). As a result, you get an average assessment of each statement for the whole team and resulting evaluation for each area. The latter is used to plot a Radar Diagram that graphically presents the results.

Please be aware that there is no single, correct interpretation of the assessment’s results. It’s something that very depends on your organisation, maturity of the team and people you’re working with. Furthermore, it’s not final values that matter the most, but their relative comparison and how they change over time (progress/improvement).

Feel free to download the assessment and adjust it to your needs. Please don’t hesitate to let me know if you think that some changes should be implemented.

Download Agile Assessment Download the Agile Assessment spreadsheet

Good Retrospectives

Overview

Retrospective is one of the inspect-and-adapt opportunities provided by Scrum framework. It’s a time-boxed event for the team to analyse their way of working and identify and plan potential improvements.

Sprint retrospective is one of the most important, but probably also the least appreciated practices in the Scrum framework. Therefore, retrospectives have to be carefully taken care of because inspection and adaptation lie in the heart of agility. It’s an important mechanism that allows a team to continuously evolve and improve throughout the life of a project.

Atmosphere

Sprint retrospective is a time to think about the process and practises hence the full Scrum team has to attend it (including Product Owner and Scrum Master who facilitates the discussion).

Assuming trust and safety are in place, everyone is encouraged to be completely honest and reveal all difficult issues one has in mind. Team members are expected to present their opinions in an open, genuine, yet constructive atmosphere. It’s facilitator’s responsibility to ensure that discussion stays positive and professional, focusing on improvement of the team as a whole. It’s critical for retrospectives’ long-term success that finger-pointing, assigning blame and personal criticism is absolutely avoided.

Quantitative Assessment

Before you jump in into a hot discussion some reporting of important metrics should be done. It’s required to set a context for the discussion and objectively present how the team has performed.

There is no one-fits-all set of metrics you should be using – they very depend on the business context, stakeholders, project, etc. However, it’s the team who should come up with the metrics they want to use to monitor and improve their work.

Last but not least, please bear in mind that whatever you finally produce it shouldn’t be static and set in stone forever. People and teams get used to their own measurements therefore, it’s good to try something else after a while. Replacing your metrics not only helps you cover other perspectives and uncover different unknowns, but it also keeps stagnation from creeping in.

Apart from velocity, risk assessment and product quality assessment the metrics you can use may include:

  • # stories
  • # stories accepted
  • % accepted
  • # stories not accepted
  • # stories added
  • defect count
  • # new test cases
  • # new test cases automated
  • % test cases automated

Qualitative Assessment

Retrospective, though important, is not a heavy-weight ceremony. It’s an open discussion that should include three main questions/points to address:

  • What went well during the sprint?
  • What went wrong?
  • What can we do differently to improve our work?

All the improvement ideas identified in the brainstorming session should be noted down, but not all of them should be immediately converted into real actions for the upcoming sprint, though. It may sound disappointing for some team members, but they need to remember that delivering value, not improvement itself, is their primary goal. However, since iterations are short, over time, all the issues will be finally addressed (or replaced with new findings during next refinement).

Actionable commitments

Identification of actionable commitments is the key to successful retrospectives. Open discussion is desirable, but in the end, some well-defined actions have to be agreed on. And the word “actionable” is significant. Actionable commitments are well-understood by the team, have clear steps to completion and acceptance criteria, just like good stories.

Let’s have some fun

The way retrospective meeting should be held is not pre-defined. There are numerous techniques for conducting retrospectives and none of them is objectively better than the other.

To be honest, trying different constructions of the retrospective meeting may keep things fresh and interesting. After all, team’s engagement is critical for a retrospective to succeed. Some sample techniques can be found here: http://retrospectivewiki.org/index.php?title=Tools

Personally, I remember a retrospective where “Draw a problem” approach was suggested by the Scrum Master and it was a great success. The project was depicted as a ship where good things were like a wind blowing sails while bad things were showed as an anchor that prevents the ship (team) from sailing faster.

Potential problems

Retrospectives are critical for the team to improve, but they need to be run correctly to make it happen. The team has to see real benefits of spending time in retrospective meetings.

Some typical smells that retrospective is not effective may include:

  • team members not attending retrospectives
  • unengaged attendees
  • no resulting actionable commitments
  • finger-pointing and assigning blame
  • lack of trust
  • complaint sessions and no desire to improve

The most demotivating and frustrating problem, however, is the team failing to follow through on improvement actions identified during previous retrospectives. It makes the meeting waste of time with no real impact on day-to-day work. The team has to understand that commitments they make matter and have to be met.

There is no silver bullet to address the issues mentioned above, but it’s Scrum Master task to realise that retrospectives are ineffective and work towards addressing issues like these. And if the team is new to Scrum inviting an external facilitator to conduct the meeting is highly recommended.

Edit: A great source of restrospective’s fun: How to Make Your Retrospectives Fun