Build it… without delay

The expressions “Build the right thing” and “Build the thing right” are helpful in connecting practices with outcomes and expressing how the two ideas are complementary.

Sometimes I speak with people who are not seeing that shipping sooner and more often is a necessary part of building the right thing. For these occasions I thought it might be helpful to make this more explicit.

Sometimes I speak with people who are focussed more on one consideration than the others. Though complimentary, they also compete to some degree for attention and resource and need to be appropriate for the situation – it isn’t just about more of all three. This ternary variation of the yin-yang idea represents that there may be tension between these considerations and that they need to find a balance.

Thank you to everyone in LinkedIn’s Agile & Lean Software Development Forum who contributed to the discussion that helped shape the idea.

Performance Management – a new team responsibility

I have a lot of empathy for HR people these days. They have many difficult challenges but it seems only one, blunt instrument with which to tackle them all. The Performance Appraisal is required to provide answers to an array of gnarly questions e.g.

  • How much should people get paid?
  • Who gets promoted and who gets fired?
  • How do we tell people they need to improve?

The trouble is that Performance Appraisals really aren’t very good at determining any of these things. As anyone who has participated in one will know, they are time consuming and happen too infrequently for goals to be meaningful or for people to learn from the feedback they receive.

Other problems are well understood. Feedback is given by only one person who, being human is prone to bias. The feedback flows in one direction only i.e. ‘downwards’ from someone who is in a position of authority. This is hardly conducive to the kind of conversations that might help people to introspect and grow.

Leaving aside personalities and competence, sometimes there isn’t always sufficient trust for people to be candid about their shortcomings with the person who ultimately controls their career. It also creates an enormous challenge for review managers, who often feel uncomfortable with the arrangement and who would appreciate candid feedback themselves.

Finally, Performance Appraisals are especially damaging for Agile teams, where collaboration is highly valued and easily undermined. Some Agilists have even suggested that people refuse to participate in Performance Appraisals altogether. No wonder everyone, including HR, find the whole exercise frustrating and demoralising.

15 years ago, I was attracted to Agile because it empowered people challenge ineffective and wasteful practices. Surely there is a better way? Something that is inclusive, frequent and fairer to all concerned.

360 feedback to the rescue?

These too are heavy, costly and mostly reserved for those considered to have the greatest potential. Subjects are often able to ‘game’ the process by selecting who rates their performance. Finally participants don’t get to see the feedback directly, receiving a filtered version which has been “assessed” by a “superior”.

360 peer reviews feel like a step in the right direction but ultimately suffer from the same problems as regular Performance Appraisals i.e. they are too infrequent, not inclusive and can be gamed. Not much help for an Agile team.

HR meet Agile, Agile this is HR

Thankfully, there is now a growing recognition that the traditional approach to Performance Management (TPM) doesn’t work and overall, does more harm than anything else. TPM enforces hierarchical culture.

Feedback needs to be frequent and meaningful if it is to help people develop

Not surprising then that the drive towards increased business agility has created a movement away from TPM to something that embodies the progressive values of modern organisations, such as respect, autonomy and engagement. That something is called AgileHR and more specifically… Agile Performance Management (APM).

The opportunity

When it comes to pay, we begin by acknowledging the ideas popularised by Dan Pink about motivation. Pay people enough to take the issue of money “off the table” and whatever profit sharing we do is carefully considered to incentivise teams and collaborative working. One example of an alternative reward system is Happy Melly’s Merit Money. There is still lots of work still to be done in this area, but at least it is starting from a better understanding of how people behave.

Next, let’s consider Agile for a moment. Fast feedback through customer collaboration enables teams to be given more autonomy, self-organising around clear customer objectives. In this setting teams are held to account for their performance and develop greater trust with their customers and stakeholders.

The greater transparency and accountability of Agile changes the game. It creates the possibility that teams can now be responsible for their own performance management. The team just needs a practical way to be able to accept this responsibility.

Enabling performance self-management

So how does this happen? A good place to start is by establishing team agreements that give the team ownership of their Performance Management process. This includes the ability to inspect and adapt it to their needs as necessary. They discuss and agree the competencies that are important to them as a team, the cadence of the feedback and the face-to-face interactions they will have at the end of each review cycle.

Assurances need to be provided around confidentiality and anonymity so that people are able to be candid and give meaningful feedback. Team members are also given full control of the feedback they have been given. This enables them to have confidence that no one else can see their feedback without their knowledge and prior agreement.We provide appropriate coaching support to help team members act on the feedback they receive, and also for the team to call for help if it has a problem it cannot resolve.

Enabling the continuous exchange of feedback between everyone in the team creates a lot of feedback, so we need be really smart about how it is gathered.

Simple relative rating by competency is fast and light

The first part is for team members to give competency ratings. Relative rating is light and fast, providing context for the supporting verbal feedback. Because everyone is exchanging ratings, the wisdom of the crowd helps to eliminate individual bias.


Carefully formulated commendations and recommendations recognise great competency behaviours and suggest ways in which people can improve. Capturing this feedback throughout the review period, when behaviours are observed and relevant makes it more meaningful and less onerous.

The grey area shows how the individual rated themselves whilst the grey area shows the median rating from the team

Appropriate visualisations provide a way into face-to-face coaching conversations that develop an individual team member’s competencies and those of the whole team. The nature of these conversations having been agreed by the team up-front.


The traditional approach to Performance Management is ineffective and a poor fit for Agile teams. Sadly, 360 peer reviews aren’t much help either.

An Agile approach to Performance Management is one that is aligned with the principles of respecting people, fast feedback and learning. It would be inclusive, frequent and treat everyone equally. With appropriate support, it is possible to remove the need to have any one person responsible for Performance Management, eliminating a further impediment to team self-organisation.

TeamSense makes the frequent exchange of meaningful feedback between team members viable. Individual and team competencies are made visible and provide a way into conversations that drive improvement. It enables Agile teams to take responsibility for their own Performance Management.

Planning is key to Agile development

When I saw this meme, I just had to laugh. Then it got me thinking about how wrong this picture really is…

It is a total fallacy to suggest that there isn’t any planning (or plan) with Agile development or that Agile results in poor quality.

If anything, there is more planning with Agile development than with traditional “plan driven” projects. It may not seem like it, because planning is a continuous activity happening as the work progresses. The “plan” itself is expressed in a very different form i.e. as an ordered list of work items that can be continuously re-prioritised by the business, to deliver the higher value items sooner. This kind of plan supports better commercial decisions. It is clearer to everyone where we are now and better at forecasting how long it will take/cost for further items to be delivered.

Unlike traditional “plan driven” projects, Agile development is all about quality. Quality becomes the responsibility of the whole team, who work to a robust Definition of Done. This ensures that each item of work isn’t considered complete until it is of serviceable quality. The steady release of functionality to the customer not only delivers value to them sooner, it provides fast feedback making it easier to manage risk, especially those around getting the product increments into live.

Agile avoids the situation alluded to in the picture through highly discipled engineering practices such as Refactoring, where the internal structure of the system is continuously improved with the support of automated testing.

Agile does a better job at managing risk and stakeholder expectations, leading to better outcomes.

If absolutely necessary, Agile practitioners will compromise on scope, but never quality. With traditional “plan driven” projects the quality is compromised because the quality assurance happens at the end, where it gets squeezed by the inevitable and unforeseeable problems that will emerge.

In my experience, projects that begin with a long up-front planning/design phase still ended up with software that looked like the wires in that picture. This happened because when the plan/requirements/design/architecture were established up-front, it was impossible to know what was really needed and what the best technical solution would be. By the time anything got delivered, it was late, of poor quality and didn’t do what the customer had now discovered they really wanted.

The Agile approach enables planning that is far better at dealing with the emergent nature of software product development. Planning is continuous and quality is key. It is highly disciplined and difficult. It isn’t often you see it being done well, so maybe people can be forgiven for misunderstanding what Agile is really all about.

What does your team value?

We all want to be able to do a good job and get paid, but what else is important to us? Is there any value in sharing this with each other? I discovered that talking about this together had a surprising benefit.

A while ago I learned how helpful it can be for teammates to take a little time out to discuss what really matters to them, as individuals and as a team. We all want to be able to do a good job and get paid, but what else is important to us? Is there any value in sharing this with each other? I discovered that talking about this together had a surprising benefit. Recognising common values led to a greater sense of connectedness within the team. Recognising values which were not commonly held, and were causing frustration for some team members, led to greater understanding and empathy. The simple list produced from that discussion became our Team Values and marked the beginning of the team’s journey towards self-awareness and greatly enhanced performance.

Bringing everyone to a common understanding of what a particular competency means is the first step in enabling the continuous exchange of meaningful feedback within the team.

Since then, I have applied this learning to discussing the competencies that matter to the team. To help this discussion I like to use the cards (shown above). Each one has the competency name and a brief description on the front and some example behaviours on the back. Teammates can pass them around, talk about their relevance to the team and ultimately vote or in some other way select the ones they think most important. In addition there should be some blank cards, to allow the team to come up with their own competencies as they wish.

We go on to establish team agreements around the other aspects of our competency feedback process e.g. cadence, conversations and inspection point, however I believe the discussion around competencies is of value in its own right.

You can find out more about establishing team agreements for Performance Management and get the template for the cards here.

Principles and values for Agile performance management

TeamSense enables the frequent exchange of feedback between teammates. But to really understand what it is all about, a good place to start is with its three core values and the principles that flow from them…

TeamSense is a tool enabling the frequent exchange of meaningful feedback between team members. But to really understand what it is all about, a good place to start is with its three core values and the principles that flow from them. Not only are these principles deeply embedded within the tool, they serve to inform how it can be applied in different situations, to drive individual and team improvement.

1. Respect

Fundamentally, respect is treating people as you would like to be treated. People generally like to be treated fairly and equally. They like to be consulted and have the opportunity to express their point of view. With TeamSense, ratings and feedback flow in all directions within the team. No one person is responsible for giving feedback or team performance. Everyone is.

As TeamSense is the team’s tool, establishing how to use it is done through team discussion and agreement. The team determine the competencies that are of value to them, the cadence at which feedback will be exchanged and the conversations that will happen during and at the end of each feedback cycle. This is more respectful than dictating how the tool will be used. It also enables the team members to reciprocate respect by agreeing to be bound by the team’s agreements.

The principle of ownership gives team members full control over their ratings and feedback. Nobody can access this data unless the individual explicitly shares it with them. This prevents the situation where people’s performance feedback is being accessed without their knowledge for purposes other than personal and professional development.

2. Individual Development

Whether we see personal development and growth as a purpose in itself, there is no doubt that a deeper understanding of our behaviours can be of great personal benefit. Professional development enables us to have successful careers, and though this is no guarantee of happiness, it can certainly make life a lot easier.

Taking a moment to recognise that we are all on a journey helps us to see our current state of being in context and to move forwards.

Meaningful feedback is essential for our development and growth. But to be meaningful, it needs to be accurate and from the heart. The closer feedback can be given to the observation that prompted it, the better the learning will be for the recipient. Sometimes however, for meaningful feedback to be given at all, it may have to be anonymous. Similarly, the recipient may only be open to receiving feedback that is given in confidence.

Receiving feedback is one thing, but really learning from it is another. The best aid to this is to discuss it in an informal setting with someone we trust. How this happens forms part of the team agreements mentioned previously and will vary depending on the constraints imposed by an organisation’s culture. Options might include one-to-ones with a Line Manager or some other trusted individual. In more progressive organisations this could be an HR person external to the team. They would act as the team’s feedback moderator, supporting team members in understanding and realising the recommendations they receive. If necessary they can also serve to mediate between team members in conflict.

3. Team Performance

Wanting people to have the opportunity to develop and grow isn’t just a noble goal. It is an important factor in enhancing the performance of the team. Appropriately anonymised charts make the team’s competencies visible in a way that is about the competencies, not the individuals. It raises awareness and provides a way into team discussion about how they can improve.


Unlike traditional approaches to Performance Management, TeamSense is founded on respectful and team centric values and principles. These values are aligned with those of Agile and Lean, making TeamSense a better fit for Agile teams.