The first method was to take the ceremonies and artifacts from Agile Mechanics and enrich them with the principles behind them. Thus, in the evaluation, instead of implementing them, we focused on fulfilling their meaning.
Let's illustrate this with two examples of Scrum ceremonies — Stand-up and Retrospective.
Stand-up
Ask the team a simple question — why do we do stand-up? You can hear answers like:
- To think about what we did yesterday, what I'm going to do today and whether I have any obstacles
- To see how much who did
These answers are fairly common and yet neither is the point of Stand-up. The first is a bookish description of what Stand-up is, and the second is something where Stand-up often slips in the case of micro-management.
👉 The point of Stand-up is to reconcile together on the current increment, whether we are progressing as we expected and whether something needs to be changed. For example, help yourself with a difficult task, change priorities, or rearrange current work to achieve our goal.
In practice, you can see this, for example, from the following discussion:
Team Member 1: “Yesterday I started the implementation of the commission calculation, today I would put it in for lunch.”
Team member 2: ” Cool, so I will connect it in the application, about 13:00 it will be on the test environment.”
Team member 3: ” So I will test it this afternoon, so that the Commission Count View functionality could be completely finished today.”
This is how a stand-up team that makes sense can look like. For example, you will also know that you do not need to convince the members of the meaning of Stand-up, they know it themselves.
Another example of the fulfilled sense of Stand-up and at the same time the maturity of the team:
Team Member 1: “Team, I really don't have much to do today, I have a job for like 2 days.”
Team member 2: “Great, you could/could help me with...”
For more examples of what to observe to evaluate your stand-up level or tips on how to do stand-up meaningfully, see our previous article Daily Standups Championship.
Retrospect
As with stand-ups, we can ask ourselves the question — why are we doing a Retrospective? Typical answers tend to be:
- To tell each other what went well, what went wrong and define action steps
- Because sometimes it's good to stop by and see how we work
Yes, but why? What do we want to gain by doing this?
👉 We want the next Sprint to move not only towards our goal (value addition, e.g. functionality), but also in the way we get to that goal (e.g. Way of Working — the way we work in a team, the state of the environment in which we work, the relationships we have with each other and the relationships with our surroundings, obstacles on our way, and generally inefficiency that slows us down.)
An example of meaningful debate during the Retrospective:
Team Member 1: “Last time we dealt with a test environment at Retrospective — does anyone know where it went?”
Team member 2: “It's being solved, I talked to Jirka and next month new iron will be purchased and the guys have already tested the car deployment. I'll know on Monday when we can count on it.”
Meaningful Retrospectives look like team members engage in specific actions/solutions and don't expect anyone to work it out for them. At the same time, the team goes back to these actions and evaluates their impact -- did it bring us the result we needed?
One of the other manifestations of the mature Retrospective is experimentation with different formats. Nowhere is it said that the Retrospective has the only correct format (e.g., the classic 1. What went well and 2. What we want to improve). In practice, the opposite has been confirmed to us — routine kills improvement, and different formats offer new stimuli. You can get inspired for new Retrospective formats in the article Fire up your retrospectives! Popular sources of inspiration for Retrospectives can also be Internet portals such as e.g. Retromat.
Enrichment with meaning has more explanatory value, but is more demanding
Taking individual ceremonies (Standup, Retrospective, Refinement, Planning, Review) and enriching their assessment gives us a much better picture of the level of Agility and at the same time it is much better perceived on the team side — we talk more about why a given meeting/activity is happening than it is supposed to happen. But following the meaning costs us something. In practice, this requires:
- It's time, because it takes several times more time to evaluate the meaning than simply checking the existence of a meeting or recording in Jira.
- Seniority of man, typically an Agile Coach or Scrum Master — he has enough experience to be able to evaluate the fulfillment of the meaning of the ceremony from a simple discussion in the team.
- Seniority of team and surroundings — if a senior Agile Coach requires fulfillment of meaning, not simply mechanical execution of meetings, the team must understand him—be at a similar level of seniority.
For junior teams and Agile coaches, there is then a way in the form of Self-checku, which we described in Past work. This Self-check will be prepared by experienced Agile Coaches. It is possible to project “seniority” in what behavior we want to observe in the team.
In addition to the need for seniority and time requirements, we were significantly limited by our commitment to a specific methodology — see examples from SCRUM above. The consequence was that we could not use the same method of evaluation across teams that used a different methodology than SCRUM and yet were Agile.
Evaluation of principles from the Agile Manifesto
So we went back to the roots in our deliberations. Where is Agility defined? In the Agile Manifesto (https://agilemanifesto.org/.) 12 principles are defined here (https://agilemanifesto.org/principles.html), which must meet any methodology, procedural framework, be it SCRUM, Kanban, or anything else.
So we took these basic 12 principles from the Agile Manifesto and built upon them the measurement of Agile maturity as follows:
- We have rewritten the principles into an understandable form with great sensitivity so as not to confuse and bend the meaning of the principle into something else.
- We ran a pilot on a part of the company and made adjustments based on feedback (clarity).
- We have expanded to the entire company with regular evaluations.
Specifically, at T-Mobile and Slovak Telekom, we have created the following transcription of Agile Principles:
This table is regularly filled in by Agile Coaches with their teams similar to how we are in Past work described at Self-Check. It is mainly the discussions that trigger these evaluations and trend monitoring. Coaches also make sure that everyone understands that it is a tool that is intended mainly to serve the team and that the results are incomparable between teams. They become guarantors of a safe space so that such an assessment can take place at all.
Advantages and disadvantages of following Agile Principles
The way we follow Agile principles has allowed us to focus on the essentials behind Agile Mechanics, and by not relying on a specific methodology, we are able to apply this measurement to all teams.
Further, we have been shown in practice that this method compared to the simple mechanics of observing:
- Requires Higher Seniority in understanding these principles both in coaches and in the team — a lot of effort must therefore be devoted to the competence of coaches and teams (as in the previous monitoring sense.)
- Provides outputs at the level System functioning — for example, during the evaluation in the teams we showed that people were overloaded thanks to point 8., while elsewhere there was a complete lack of business representation in teams due to point 4 — which is the essence of Agility.
- It makes sense to evaluate rather in the longer term — the monthly or shorter frequency has not worked very well for us yet (after a while it becomes routine without added value); the optimum can be a quarter or half a year.
In the next article, we will look at the last way to track Agility — that is, meeting (business) goals.