Team Development Framework I

Team Development Framework Implementation Plan
We will consider the implementation of TDF in an already ongoing project, i.e. we will consider the case of transformation. This case is the most frequent and more complex case than implementing TDF in a project that is just being created, where the necessary changes can be made at the design stage.

The implementation plan is based on the Flying Jet Fixing mental model. Typically, if management wants to implement change, they prefer to pull people away from their tasks and conduct training sessions that address exercises that are disconnected from real-world tasks. This approach is bad for two reasons: 1) people get distracted in the training because the work tasks are more important anyway; 2) people need to understand how what they have been taught relates to their real work. As a rule, after the training they tend to behave in old ways, and all the frameworks provided to them are quickly forgotten.

Therefore, we recommend changing approaches to work during the work itself and on the material of the work itself: repairing a flying jet.

The proposed plan consists of 8 sprints, each of which ends with a team meeting. Once the plan is implemented, such meetings start to take place regularly and according to certain rules, which will ensure Continuous Improvements, Focus, Transparency, Value Delivery and – the most important achievement of Phase I – Demanding Environment.

Once again, let us clarify that this plan is not prescriptive. If you can and want to execute everything written here exactly as it is written here – you can do it. But some adaptation will likely be necessary. Some steps will not be applicable – for example, you already have an epic axis, and there is no need to re-create it.
Before the First Meeting: Building a Team
You start with a team consisting of one person – yourself. That said, technically, you may have employees, and, technically, they may be on the team.

'M Team Leader: any team should have a leader – someone who is interested in seeing the project successfully close and who is willing to do much more than the bare minimum.

This model may seem trivial, but there are times when no one cares about a project. In that case, this guide will not help you in any way, nor will Agile.

In ‘green’ cultures it is common to assume that a leader is either not needed at all (as in Scrum) or the leader should help the team by providing them with snacks and drinks. If you have managed to build such a team for which you can only stay out of the way – congratulation.

'M Team Leader: any team should have a leader – someone who is interested in seeing the project successfully close and who is willing to do much more than the bare minimum.

This model may seem trivial, but there are times when no one cares about a project. In that case, this guide will not help you in any way, nor will Agile.

In ‘green’ cultures it is common to assume that a leader is either not needed at all (as in Scrum) or the leader should help the team by providing them with snacks and drinks. If you have managed to build such a team for which you can only stay out of the way – congratulation.

'M Distributed Leadership: people can be leaders in the areas they are best at. This is a good model, but in order for people to also engage in leadership behaviour, two conditions are necessary: they have to want to do it, and they have to be able to do it.

'M Psychological Contract: in reality, for a person to be on a team, they need to enter into a Psychological Contract: they agree to do more than their role implies, and in exchange they get the right to make decisions about the team and the product.

If people do not agree to this – do not bring them to the team. Use their competencies in Command & Control way. So before the team starts working, talk to all potential candidates for the team and invite those who are ready to invest in the project.

'M Deliverables: what will be the result? The model is that something remains as a result of any activity: code written, agreement on how to proceed, understanding of a new subject area.
Deliverables before the First Meeting:
  • People who have accepted the psychological contract and are ready to get involved with the team;
  • An appointed meeting that people have agreed to attend, lasting at least two hours;
  • A reserved place to hold it in which you will not be distracted.

The First Meeting: Epics Axis
At the first meeting, do not do anything to ensure psychological safety or develop any rules of communication. Just have a respectful conversation. And start with what people are most interested in: what they are doing now.

In such a discussion, people may be surprised to discover problems in their colleagues's work that they had never thought of. It is easiest for people to attribute others' behaviour to their personal traits rather than the situation, although the situation determines behaviour to a greater extent.

In the meeting itself, formulate epics that are derived from what people are doing right now.

What is an Epic?
An epic is a small project. This means, among other things, that an epic should be completable. If a team has an ongoing activity, it is a process, not an epic.

An epic formula is 'We want X to Y'. It specifies not only what the team wants to achieve, but also why it is needed.

It is easier to work with epics that have clear bold titles.

What To Do:
  1. At the meeting, just talk about the big tasks that the team has.
  2. Write the names of these tasks on the board. At some point, you will notice that people start repeating themselves and talking about things that have already been talked about. This is a good thing. Just ask the team to comment on whether they are talking about the same thing or different tasks.
  3. During this discussion, important tasks will start to emerge – that is where you start formulating epics.
  4. Keep in mind that the entire scope of work can be divided into epics in many ways and that there will still be some tasks that are not related to specific epics.
  5. Tell the team what an epic is and how it is built. From this point on, start calling such large tasks epics.
  6. Formulate the first epic together with the team.

If you manage to formulate all epics in this meeting, that is good; if you do not, it is even better. Agree with the team how you will complete this work for the following sprint. Will it be a separate meeting or will everyone write their epics separately? Either way, this will be the first team decision, so work not completed to completion is better than work completed.

Deliverables:
  • Maximum: an Axis of Epics; minimum: one well-written Epic.
  • Possible: agreement on how to finalise an axis of epics.

The Second Meeting: Responsibility
If you do not already have an Epic Axis, this meeting should be dedicated to it. Since people already understand what an Epic is and have discussed much of the work, one meeting should be enough to complete the Epic Axis. If you have time left, it is better to wrap up the meeting and not discuss new topics.

If you already have an Epic Axis, the second meeting will be about responsibility.

There is no responsibility in Agile. As Vladimir Tarasov says, ‘Two soldiers are sent to fetch brushwood, one is put in charge’. Classical PM says that a responsible person should be assigned to even a small task and put it in the responsibility matrix. Agile does not use the word ‘responsibility’ anywhere except in ‘the whole team is responsible for everything’. Which is equivalent to saying that no one is responsible for anything.

We consider abdicating responsibility to be a mistake in Agile, an unbalanced 'green' solution. In our work, we place responsibility in Epic. The Epic Owner is the person responsible for closing the epic. Fixing responsibility for stories is too small, making people responsible for objectives is too large. The epic is, from our perspective, the best element for which people can be held accountable.

Task Structure. We will appeal to the classic definition of task structure several times in the TDF, and the Responsibility Grades Framework will be built on it.

Ask your team: ‘A kettle costs $100. Its price was raised by 10%, then it was lowered by 10%. How much does the kettle cost now?’ If you already understand the basic rules for working with your team, you will write the conditions on the board.

The only correct answer is $99. But instead of it, people can give such answers as: ‘1 percent less’, ‘$10 less’ or, worst of all: ‘I do not know’. The answer ‘$99’ shows that a person cares about the convenience of his colleagues and brings a finished, not an intermediate result.

Structure of the Task:
  • R – Resources. Resources are what the team has. In the task, resources are three statements: 1) ‘a kettle costs $100’, 2) ‘the price of the kettle was first reduced by 10%’, 3) ‘then the price of the kettle was increased by 10%’.
  • P – Purpose. Purpose is what is to be achieved. In this case, to answer how much the kettle now costs. This may be necessary so that the shop employee can change the price tag.
  • T – Tools. Tools that help a person to convert R to P. Here it is the ability to work with percentages and arithmetic.

Responsibility Grades:

Specialist. This is a person to whom you can give resources, explain what needs to be done and how to do it, and the person will do everything accurately and, if they encounter difficulties, will come back to you and ask. People like that are very valuable. Most people are below that level.

Have you ever had such situations where you gave a person all the resources on Monday, explained what needs to be done, showed examples, gave instructions, encouraged them to write to you if something is unclear, told them that the deadline is Friday at 4 PM. And on Friday at 4 PM you get a job that looks like it was done in the last 15 minutes? And you then have to redo it all at home on Saturday?

There are people – an awful lot of them – who need to be micromanaged rather than developed, or you will not get any results at all. If you have people on your team who do not reach Specialist level – remove them from your team.

If you have a person at the Specialist level, you should invite them to the team only if they are active and ambitious. Otherwise, you should manage them through C&C.

Teammate
This is a person who, given resources and a goal, can figure out how to achieve the goal by themselves: they do not need instructions and micromanagement. With the right effort, such a person can develop and become an Epic Owner.

Epic Owner
This is a person who is responsible for an epic that they have formulated. An Epic Owner is a person who, with knowledge of the project's purpose, can formulate the small project needed to close the main project. The Epic Owner gets the resources, sets the objective themselves, and determines the path to achieve it.

Team Lead
Team Lead is the person who has the ultimatum responsibility for the success of the project, including bringing in the necessary resources to close the project. This is you. If there are other people on your team at this level of responsibility, you are lucky. Appreciate them.


What to do?
  1. Conduct a kettle price experiment.
  2. Present the framework to your colleagues.
  3. Set expectations: an Epic Owner is someone who is at the Epic Owner level. They are even named the same.
  4. This framework is exactly what the team is given, it is not worth discussing unless the team sees its obvious inapplicability to your case. In that case, discuss and change it, but always keep in focus that this is a framework about responsibility, not about position or professionalism.

We at Kite worked mostly with management teams that included the leaders of the respective teams. Such people were at least at the Epic Owner level, which resulted in all epics on the team being covered by someone on the team.

The opposite case is the intern team. In this case, you are responsible for all epics.

A good case is when you have a few responsible people you can rely on and who together with you can take responsibility for all epics in the project.

If there is a recommendation for sharing responsibility, it is this: give people the opportunity to take responsibility, and if they are not capable of taking responsibility, take it away. A framework on how to take responsibility and not lose a team member will be presented at Phase II.

Deliverables: Every Epic has a responsible person.

The Third Meeting: Planning
People do not like to plan. Agile memes about the unpredictability of the world people tend to take as a permission to not think ahead and do what is clear for them. That is why at this meeting you should take one and only one epic and break it down into sprint-length Stories. When dependencies are discovered, you should spell them out and put them in the appropriate Epic, but always keep the focus on the Epic you are planning.

The Story follows the same formula as the Epic: ‘We want X to Y’, but depending on the type of story, it may have a different first part. Whether you use User Stories, Job Stories, some other types of stories, or break down Epics into tasks altogether is up to you and your team.

Epics should be planned top-down. Often people tend to plan bottom-up: take a story they need to complete and think about what epic it relates to. The top-down approach is to take the epic and figure out what stories it is made up of – that is, what needs to be done in order to complete the Epic.

Once you have one Epic planned out, you can discuss how to evaluate the Stories. Evaluating Stories is a well-written topic. We will just say that it is up to the people who will be involved in completing the Story to evaluate it.

Evaluating a Story is a function of time and energy. The longer it takes to complete a Story, the more points it has; the more exhausting a Story is, the more points it has. To better understand energy, imagine having to spend 4 hours doing something you love or 4 hours taking an exam. In the first case, you probably will not feel tired, while in the second case you will be exhausted and wll not be able to do anything productive that day.

In order to plan the rest of the Stories, there is usually a special meeting: the Story Writing Workshop. Either way, it is worth deciding at the end of the meeting how the team will finalise the planning.

It is important to note that planning does not mean the order in which the Stories are done. It is just the slicing of Epics into Stories.

You will find that some Stories need to be completed, but they have nothing to do with any Epics. That is normal. Create a Miscellaneous column for them. An indicator of poor planning would be if there are a large number of Stories in this column, or if every Sprint the team takes Stories mostly from this column. This would mean that the team is not working on closing the project, but is stuck in operations.

Whether or not to take any of these into work for the next Sprint is up to you and the team to decide.

Deliverables:
  • Scheduled Epic;
  • Agreement on how Stories will be evaluated;
  • Agreement on how you will plan the remaining Epics;
  • Deciding whether to take any of the Stories to work.

The Fourth Meeting: After Action Review and Retrospective
The Retrospective was originally a rare event – at the end of the [NC] project. It was thought that people would have learnt lessons from the closed project and would be more experienced in the next project. However, there was also the idea that Retrospectives should be held more often during the project [JH]. Scrum has popularised Retrospectives every sprint – and we believe this is too frequent.

Retrospectives are needed for two reasons: to learn from past successes and failures and to close the gestalt, i.e. to disconnect from negative experiences related to other people. You can learn quick lessons every sprint, but in order to learn deep, fundamental lessons and really close past resentments, you need immersion. That is why we separate these two activities.

Kite's practice is to do a deep Retrospective every half a year: in January, after people have rested, and in August, also after people have rested.

A quick Retrospective that can be done immediately after an event and at a team meeting is called an After Action Review (AAR). AAR has advantages:

  • People do not like retrospectives. The first thing people start saving time on is the Retrospective. Doing work, analysing metrics, planning – all these activities are perceived by people as having to do with work, while Retrospective is something non-work related. That is why a deep Retrospective should be done when people are not yet in the midst of a work rush – after a holiday. AAR is conducted in a more technical way, so it is perceived as a more work-related activity.
  • Title. After conducting Retrospectives became popular, people started to understand completely different things behind the name. By using AAR, the lessons learnt activity can be made clearer.
  • Emotions. Some people on a Retrospective may cry, others may walk out slamming the door [ED]. This can really be the case in a deep dive, when the Retrospective is given at least a whole day. But when you have one hour, even an experienced facilitator will not be able to work with deep emotions. Moreover, we can argue that many people do not like Retrospectives precisely because they are asked to open up emotionally. Some people do not want to do this – and you are not their therapist to insist on it; other people use emotion to get attention – and others may not want to tolerate it. So if an emotional employee cries, others may slam the door.

In summary, we recommend a deep Retrospective every six months or more often if there is an important enough event; for operational work, we recommend AAR.

You should have quite a few potential issues by this point; if not, postpone the AAR and conduct it after Key Results but before Integration.
Conducting an AAR, which Kite uses, consists of three steps: 1) discuss the rules, 2) discuss the problem, and 3) develop a solution. If you want to develop your own approach, you can consult the [AR] sources.

At AAR, we do not rate people's moods on a 10-point scale, we do not use games, and we do not tailor the technique.

At the very beginning of the meeting, conduct a Check-In – a brief recounting of the person's past sprint. Such a short story, even though it contains personal stuff, actually sets the mood. Follow the rules:
  • You can only talk about yourself.
  • You cannot interrupt the person, but after the person has finished, you can ask a clarifying question or show your support.
  • Do not give advice.
  • You cannot start discussions. Only clarifying questions and support.
To start the Check-In, ask the team who would like to start. The person who starts first, after they have finished, passes the floor to the next person of their choice until everyone has spoken.

Everyone must be sure to speak. If something very bad has happened in a person's life – something so bad that he or she cannot participate in the work process – that person should take a break and not come to work meetings or to work.

After the Check-In, discuss the AAR Rules. The most important rule is Norm Curt's Prime Directive: ‘Regardless of what we discover, we will rely on the fact that each person did the best they could in that situation, with those resources, with that knowledge…’

We would put it this way: if you understand the Prime Directive, no more rules are needed. But this rule is not worth imposing, but discussing.

  • Write the text of the rule on the board: large and legible.

  • Ask people to say what they think about it. Do not force people to speak if they do not want to. Write key points on the board: positive in green, negative in red, neutral in blue. After a while, people will develop a common understanding: some points people will agree with more and more, some will go unheeded.

  • The most important takeaways from Prime Directive: we do not blame people for what they did; if we had the experience we have now, we would have done things differently, but we did not have that experience then; with those resources we could have done more than we did, but we did not know how; in general, it is hard to create perfect solutions in a stressful situation. If people are significantly missing one of the main takeaways: tell your opinion with the takeaway and ask what the team thinks about it.

  • The leader speaks up last. If you have an adequate team, it will not be difficult to speak: everything has already been said for you.

  • Ask if any other rules are necessary. If so, discuss them. Remember that you should not accept a rule just because someone suggested it.

  • Thank the team.

[?] What if people are convinced that the Prime Directive is rubbish and that people should have done better? In that case, the team has no underlying mental model for either AAR or Retrospectives. In such a case, the leader should not conduct the AAR and focus on something else: why do people on the team have this mindset? This is a question that should be addressed by a professional.
Discuss the Problem. It is best if you have a title and columns. The title should state the problem – what is important here is that it is written down. The problem should not have a solution in it. The columns help you analyse the problem. You can choose from the given columns or add your own.

  • Why it is a problem. ‘Users of our system could not use it for three hours last Friday because we had to shut it down due to integration issues’. Yeah, but why is that a problem? Let people spell out trivial answers – and write them down: 'Users were outraged', 'Some customers left us', 'Our reputation has deteriorated', 'We lost money', 'Our competitors ridiculed us on Twitter – and we feel bad'.
  • The next two columns are discussed together: what went well and what went badly. When discussing the good side, write down even the most trivial responses. When discussing the bad side, remind the team about Prime Directive. Ideally, when discussing the bad side, people will only talk about themselves. But if the ideal does not work, ask people to talk about the situation, not the participants. 'I failed to get the dump in time' instead of ‘Ethan promised to provide me with a dump in advance, but brought it to me at the last minute’. If you blame people, they will get defensive and in turn blame others.
  • Who to thank. Thanking colleagues helps you close the gestalt and not get emotionally involved in the situation. All in all it helps, but it absolutely does not work. Listen to the first person thanked, hand them a marker and ask them to write down on the board who they are thanking; take the marker away from the person and give it to the next person who wants to speak before they start saying anything. Let the person decide whether to speak first and then write on the board or vice versa.
What will we do differently? If the AAR results in action items, formulate them and put them in the backlog. If you can formulate a rule based on AAR results – formulate it and put it in the list of rules and monitor its implementation in the future.
AAR rules for Timelid from Kite:Project:

  1. Do not encourage ‘green culture’: if someone wants to cry or shout, they can do so in a private place. Do not deny other people's feelings, and having a good cry is good psychotherapy in itself: tears bring out cortisol. But you should not do it at the expense of other people.
  2. The worst thing that can happen at both AAR and Retrospective is not swearing and mutual accusations. The worst thing that can happen is silence or reassurance that all is well. So if people behave disruptively, that is a good thing: disruptive behaviour can be worked with.
  3. You can ask people to speak up if you think the person has something to say. It can happen that a person is waiting to be asked. But you should not force a person to speak if he or she does not know what to add. It is this kind of pressure that leads to reluctance to do Retrospectives and AARs.

Deliverables: Written Action Items or Team Rules.
[NC]
[Norman Kerth – Project Retrospectives, 2001]
[JH]
[Joseph Heagney – Fundamentals of Project Management, 5th Ed., 2016]
[ED]
[Esther Derby, Diana Larsen – Agile Retrospectives, 2006]
[AR]
[Combined Arms Center – Leaders Guide to AAR, 2013] [U.S.Agency for International Development – After-Action Review Technical Guidance, 2006] [Angus Fletcher, Preston Cline, Matthew Hoffman – a Better Approach to After-Action Reviews, HBR, 2023]

Fifth and Sixth Meetings: Objectives
Much of what you need to know about Objectives has been said by Edwin Locke and John Dorr [OB]. Before you start creating Objectives, discuss with your team the criteria you will use to set those Objectives. Generally, people know about SMART objectives – and for 70% of cases, that will be enough. We will describe these and some other criteria you can use except for measurability: this will be the focus of the next meeting.

Specific
How do you realise that your Objectives are written clearly? Once the Objective is written, give each employee a post-it note and three minutes to describe how they understood the objective. The objective will be clear when everyone goes to the board, reads their description – and there are no objections or meaningful adjustments. If you can't make the objective clear and compact at the same time, make a more detailed description in a separate publicly available document.

Committed or Aspirational
These are OKR terms: every Objective should be either Committed – people understand how to close it 100% and will focus exactly on closing it 100%. Aspirational objectives are risky but interesting and lead to company growth. They may not be closed completely.

Relevant
The Objective should answer the question: what value do we want to get? The answer to this question will help prioritise the Objectives and choose only the highest priority ones. Do not limit yourself to answering ‘Yes, this is an important goal’, but specifically spell out the value that is being achieved.

Time-Bound
In our ideal universe, people work in cycles of six months, each such cycle starts with a Six-Month Retrospective and a Strategic Session, and ends with a holiday: the New Year and the summer. So we set basic Objectives for six months. You can set higher-level Objectives: one year, two years, or before the deadline.

Written Down
Objectives are not set until they are written down and saved in a place where each team member has access to them at all working hours.

Accepted
People must accept Objectives in order to be expected to work effectively on them. So while discussing Objectives, let everyone have a say, but always keep two points in mind:
  • Compromise. Compromises must be made, no matter how much Thomas and Kilmann convince us otherwise. The perfect solution that suits everyone may simply not exist or it may take too long to find it.
  • Adequacy. ‘That's rubbish, I would never agree to such a goal’ is a real phrase that was said in a strategy session by one of the participants. To ensure that such phrases are not uttered or can be simply ignored, there is a framework created within Sociocracy: Qualification as Objections [SA]. Not every objection qualifies as an objection, but for an objection to be valid, it must fulfil certain criteria. Work out the criteria as soon as you select the criteria for the objectives.
Number of Objectives. There is a general rule of thumb: a person can keep between 5 and 9 objects in focus.

  • If you get more than 9 Objectives, it means that you are trying to focus on too many things – and will end up focusing on nothing.
  • If you get 8 or 9 Objectives, you can try to achieve them, but prepare yourself for the fact that in six months' time you will be discussing the problem of disfocus at the Retrospective.
  • 7 Objectives is the limit that an effective team can focus on.
  • 5 Objectives is a good number to work with effectively.
  • If a team has fewer than 5 Objectives, it can either be a marker that the team is really extremely focused on the most important Objective or two, or that people themselves do not know what to do. You will feel the difference.
Responsibility. It is on the Objectives that team ownership is worth using, and it is worth recognising that individual team members may have no influence at all on some Objectives.
What to Do:

  1. Working with Objectives is similar to working with Epics, so all the activities will be familiar.
  2. Together with the team, discuss the criteria you will use to set Objectives.
  3. Together with the team, discuss Qualification as Objections. This discussion alone and capturing the result will be enough to keep people from making disruptive objections.
  4. Discuss Objectives. Allow the team to make suggestions and write them on the board. At some point you will notice that people start to repeat themselves and talk about things that have already been discussed. This is a good thing. Simply ask the team to comment on whether they are talking about the same thing or different Objectives.
  5. During this discussion, important Objectives will start to emerge – focus on them when formulating the Objectives.
  6. Do not try to formulate all the objectives in one meeting: it is important that people think about the objectives during the sprint.
[OB]
[John Doerr – Measure What Matters, 2018] [Edwin Locke, Gary Latham – New Developments in Goal Setting and Task Performance, 2013].
[SA]
[SA] Sociocracy is one of the frameworks for creating a self-organising organisation through teamwork. You can read about Sociocracy in the guide [Bernhard Bockelbrink, James Priest, Liliana David – A Practical Guide for Evolving Agile and Resilient Organisations with Sociocracy 3.0] or at [Link].

The Seventh Meeting: Key Results
Metrics are the primary tool of the Demanding Environment. Metrics objectively show where we wanted to be and where we are now.

In this meeting, discuss the Mental Model Not everything Measurable is Valuable, not everything Valuable is Measurable.

Not Everything of Value is Measurable. Contrary to the belief that every objective should be measurable, we still cannot agree. The team is working on a mock-up. The objective is to win the competition and sell the design to the customer. The team has either sold or not. Even if the sale is not at a fixed price and the team has the objective for the contract amount, it is still immeasurable: during the whole preparation, the team has no data on how close it is to its objective: only indirect indicators can be measured.

Not everything Measurable is Valuable. Goodhart's Law says that the metric itself becomes the target if a person is penalised for the metric not matching the target. People start thinking locally: we will make a sale now and get a bonus, and the fact that it cannot be delivered on time and the customer will not be happy is not our problem.

That is why KPIs work in centralised hierarchical management, when employees are expected to do only their own work, and management is in charge. However, KPIs do not work well even in centralised hierarchical management: that is why corporations try to put the responsibility for the whole system on the employees themselves.

A team should be responsible for the whole system – even if it is small. If the team itself influences the system, then metrics show what the team is and is not doing well and can serve as a source for implementing improvements. But for this to happen, people must want the whole system to succeed, not individual parts of it. Which will not be possible if they are rewarded for meeting targets.

Funnels are a good example of such metrics: when a team measures not a single metric, but a collection of them, and when you can see how the resulting increase in clicks on a button converts into annual subscriptions.

Proactivity. You can respond to a problem proactively: try to solve it yourself or with the help of the team, or non-initiatively: pretend the problem does not exist or try to shift it to someone else. If you notice non-initiative people in your team, remember the Bad Apples theory: one rotten apple spoils the whole barrel [BA].

Sprint Quality. The team develops its own metrics to its Objectives. But one metric we suggest always using is Sprint Quality.

  • Every Action Item that the team has worked on in Sprint must be rated.
  • An Action Item has a Done status if the team agrees that the value was delivered, otherwise it is Not Done.
  • An Action Item has a status of Drop if its completion lost its value.
  • An Action Item has an Add status if the team did not plan it, but was forced to do so because that Action Item turned out to be blocking or urgent. If your team has a rule that every task that qualifies as an Add results in a Sprint interruption, you will not have this column.
  • An Action Item has Extra status if the team did not plan to do it, but had a spare time for it.

Sprint Quality = (Done + Add + Extra) / (Done + Not Done + Add + Extra) * 100%

What to watch out for:
  • A good sprint closes at 90% or more. If a team regularly closes a sprint at less than 90%, this is an indicator of problems.
  • If a team regularly fails to close a sprint at least 70% of the time, this is an indicator of big problems.
  • If the sprint is not 100% closed, but the team has Extra – this is an indicator that the team did what was interesting and not what was needed.
  • If a team has Drop on a regular basis – that is an indicator of problems.
  • Having an Add may not be an indicator of problems, provided it is not a big one.

Work with these problems on the AAR.

Deliverables:
  • The team began measuring Sprint Quality;
  • The team has developed Metrics to their Objectives;
  • A story is in the works to develop an environment to maintain these metrics so that at the next meeting the team can already capture the first measurement.
[BA]
[Will Felps, Terence Mitchell, Eliza Byington – How, when, and why Bad Apples Spoil the Barrel, 2006]

The Eighth Meeting: Integration
Devote the last meeting to making sure that all elements of the TDF are aligned. By this point you should have:

  • A habit of meeting regularly at the end of each sprint to look at the results of the past sprint, draw conclusions and plan the new sprint.
  • Governing Variables that show where the team is going: Objectives, Metrics, and Epics.
  • Work Breakdown Structure: planned epics cut into sprints.