Month: December 2015

Setting goals: OKRs

I’ve recently come across a great video by Rick Klau about setting goals at Google.

OKRs stands for Objectives and Key Results and are used at Google for setting goals at company’s, teams’ and individuals’ level. A great advantage of this system is that individual goals are aligned with company’s goal, therefore, everyone is rowing in the same direction.

Key points about OKRs at Google:

  • Objectives should be ambitious, not straightforward.
  • Key Results are measurable, they should be easy to grade.
  • OKRs are public (starting from CEO).

Last but not least, OKRs are independent from employee’s performance evaluations. That is, promotions, salary discussions, bonuses, etc. should be separated from OKRs. They are used to make people contribute to company’s goals rather than evaluating how employees are performing.

More in Rick’s post: How Google sets goals: OKRs

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

 

Managing Product Adaptability

Overview

Creating reliable and adaptable software is not straightforward even if the team embraces Agile practices. In most cases, however, it’s not lack of technical capability or poor performance that prevents the team from achieving this goal. My experience says that the teams are aware that constant refactoring, automated tests, design spikes, etc. are required to keep the system reliable and adaptable – it’s senior stakeholders that usually fail to understand it.

Market is very demanding nowadays. Industry after industry demands for continuous innovation. Pressure for frequent releases and responsiveness to constant changes grows. And Agile seems a good solution for software teams to deliver valuable, high-quality products quickly. However, they need to be quick but should not cross the line and make mistakes. They “need to be quick but should not hurry“.

And unfortunately senior stakeholders far too often adds to this pressure and sacrifice long-term gain for short-term wins. Unreasonable deadlines are set and all the features are requested to be delivered. And in most cases the team manages to do that – velocity accelerates and the team delivers what they were asked for. But it’s a false acceleration, because corners are cut. And adaptability is the first thing that suffers from such an approach. Technical debt grows quickly and accumulates.

technical_debt_accelerated_velocity

Technical debt

Technical debt is invisible, especially at first sight and in short-term. Software is being delivered, features get implemented so why to bother about it at all, right? What really suffers, however, is system long-term reliability and, most of all, adaptability, but it usually doesn’t come to light quickly. But it’s a real problem that in long-term results in dropping velocity, increased cost and time to delivery, growing number of defects, and above all decreasing customer satisfaction. The company is no longer ready and able to deliver valuable software and adapt to tomorrow’s client needs.

technical_debt_coc

It’s especially frustrating from team’s perspective, because – if you ask them – chances are that they will directly mention parts of the code that need urgent refactoring and that contribute to technical debt the most.

Product Quality Assessment

This being said I suggest that one of the measures you can use to monitor if system’s adaptability is not deteriorating [too fast] is Product Quality Assessment performed by the team:

reliability_adaptability_assessment

This measure depicts team’s sense of the project’s “feel” (“smell” as called in XP). It can be supported by a chart that plots growth of the test code compared to executable code over iterations (both should be growing proportionally).

Why, in my opinion, this measurement is so important when there are dozens of other KPIs available? It’s not to say that it’s the most important KPI you should use, but it’s a canary in a coal mine that gives you an advanced warning of system adaptability potentially going down before other measures notice it. It gives you a chance to have a closer look into the problem before velocity drops, number of defects grows and the cost of getting rid of technical debt becomes [too] high.

Managing technical debt

Please be reminded that technical debt, like financial debt, has to be managed. It’s important to realise that there is no debt-free product, but you should be aiming at keeping technical debt low so that it doesn’t affect future product development. There are several possible ways of paying technical debt back, but the most important thing to remember is that it should be done regularly and incrementally. You need to avoid large balloon payments as a means of servicing technical debt when it’s far too costly, frustrating and time-consuming. By using some simple measures you can make technical debt visible – both to the business level and technical level. And hopefully convince everyone that technical quality is critical to achieve long-term goals and it shouldn’t be short-changed for current needs. Continuous value generation should be viewed from a whole product life cycle perspective after all.

To be fair, it has to be noticed that technical debt is not bad by definition – it just has to be acknowledged and managed properly. There are situations when technical debt doesn’t need to be paid back, i.e.: product nearing end of life, throwaway prototype or product built for short-life.

Please bear also in mind that technical debt can be intentional, i.e. when a fixed deadline has to be met. However, rather than being hidden it should be well-thought-out decision. The decision that not only allows for technical debt, but most of all acknowledges the consequences of introducing it and involves a concrete plan for getting it paid back in future. Otherwise it would be living a lie and asking for trouble.