STANDARD for Accountability in an Agile setup

Accountability is crucial for the Growth part of Care&Growth, and at least in the companies I usually work with, in an agile setup. The word Accountability is mentioned as a key to success – and as something that is lacking. “People need to be more Accountable!” is something I hear quite often. But what does that mean and how is it done?

In Care&Growth, the model for Accountability, including what it means and how it is achieved, is central. In the model for Accountability, the concept of STANDARD is central. The STANDARD sets the expectation for your work; without a STANDARD we cannot know if people live up to expectations or not, because they are not clear. Yet, it is very common not to have a clear STANDARD. This means that leaves leaders to go by gut feeling when reviewing performance. Even if our gut feeling is very powerful and useful in many contexts in our lives, for performance review we need something more tangible to go with it!


Different jobs have different characters. This may be a trivial statement, but it has some less trivial consequences, and to deal with that properly, I find the Cynefin model very useful (see picture below and read more at

In many lines of work, a STANDARD can be quite straightforward to set; that goes hand in hand with the work tasks being quite straightforward (see the quadrant named Obvious). However, when working in a Complex work environment, it is not as easy to foresee how work will pan out. In the Complex quadrant, we for example find Software (SW) development and IT integration, and for these lines of work, Agile ways of working (WoW) are both useful and common.


Working in the Complex quadrant, a large portion of the know-how and planning must be carried by the Agile teams. It is in fact not possible for the leader to know best; he or she relies on the team for knowledge, planning and visibility. Therefore, in this type of environment, the STANDARD needs to reflect that high level of delegation.

Definition of Done

There is a concept in Agile WoW called Definition of Done (DoD). DoD defines when a task is Done, meaning ready – truly ready! In SW development, for example, it is not enough to have finished the programming and have a chunk of code; test, documentation, integration, and visualisation also need to be in place before a task can be seen as Done.

I mention DoD here because I think the STANDARD, in this case, needs to follow a similar line of thinking, and I think “DoD is fulfilled before work is considered finished” is an excellent part of a STANDARD for SW development. It speaks about how things shall be done rather than exactly what, since what will change every time.

STANDARD for Agile teams

A suitable STANDARD in SW development (and other lines of work in the Complicated, Complex, or Chaotic areas in the Cynefin model shown above) needs to focus on behaviours. Remember that in Care&Growth, we say that we can be Accountable only for Process and not Outcome.

As mentioned at the beginning of this text, a lot is delegated to the teams, so what should leaders follow teams and individuals upon? Here is a list that can be used as a starting point:


STANDARD for Agile leaders

For Agile teams to be efficient, their leaders must have a corresponding STANDARD to adhere to. The teams are the ones getting the actual work done. As we know, the leader’s job is to Care for his or her subordinates and help them Grow – set them up to succeed. Let’s look at the list above together with corresponding statements needed from the leader to make it happen:


As can be seen, the leader is serving the team, setting them up to succeed by both caring for them and holding them Accountable (for them to grow and succeed).

Accountability in an Agile setup

We learn from Care&Growth, that when holding people Accountable, we look at if their work is above or below STANDARD. In an Agile setup, that will all be about showing the right behaviours, and trusting that it will lead to great results. This doesn’t mean to say we won’t have deadlines! But it means we will not work towards that deadline blindly, but with awareness. We will re-visit priorities based on feedback from the demonstrations, we will act around dependencies not to get blocked, we will speak up when we see that something is more complex than first estimated and we will take help as well as help others so that we together can meet and exceed the customer’s expectation. That is what this type of STANDARD can help us to achieve – the right behaviours to make success possible.

To stay in touch with our content, sign up for our newsletter

1 Response

Leave a Reply