One slack notification at a time

If you use slack, then like me, you are probably familiar with the constant beeping of multiple channels. It’s very easy to get tuned out of all the busyness and long discussion threads. Unfortunately, that seems to increasingly becoming a permanent fixture of our remote work reality.

What is frequently lost in this remote working reality, are the small and random acts of kindness and appreciations which come more naturally in face to face interaction.

Our agile coach noticed that, and decided to start a #kudos slack channel, where we can post appreciations for small and seemingly insignificant acts of concrete help. Why add another channel? Why don’t just appreciate people in existing channels?

Because the small token of appreciation will be drowned by other threads that have “higher priorities”. Having one place where people mentions others and appreciate their help sounds pretty good to me :)

And although the channel is public, we don’t invite 400+ people immediately. Instead, we opt for personal mentions and invite people gradually, we want people to be compelled to continue this and mention / invite other people in.

We are just starting out, i’ll check back in a few weeks to see how our small experiment will turn out :)

Closing with a quote from Laszlo Bock:

“Simple, public recognition is one of the most effective and most underutilized management tools.”

Like the culture you’re seeing? You might want to check out our team! Join us in making the next life-centric digital solutions!

Appreciations at work was originally published in DKatalis on Medium, where people are continuing the conversation by highlighting and responding to this story.

Metrics, love them or hate them

When you hear the word metric, what goes on in your mind? KPIs? Measures? A tool for Management to meddle in your day to day work?

While KPIs and metrics are often used interchangeably, for the sake of clarity in this article, we define ‘metric’ as a quantifiable measure that shows the status of a specific process.

But why do we want to know the status of a specific process, you ask? To answer this question, let’s take a step back and talk a bit about agile teams and continuous improvement.

Agile Teams & Continuous Improvement

In an agile delivery team the ability to self organize is paramount. Self organizing does not mean the team can do whatever they want, it means (everyone on) the team owns their result and by extension act on it by introducing whatever effort they can come up to give better result overtime. This means that while result is important, the learning from any given situation or experience should never be sidelined.

And since learning is a broad term, let’s break it down so that it makes sense. Learning henceforth will be defined as insights gained from experience. For Agile teams, that will be the experience of the team.

Not that we dismiss the individual, but experience from each team member in the process will be subjective. In the interest of extracting workable insights, it would be valuable to have some objective data setup for the team to look at, and don’t forget to always provide some context while working with these data, since context gives meaning to the otherwise bland facts and figures.

To have a cadence around assessing data + context in order to have improvement overtime is at the core of the concept known as Kaizen / Continuous Improvement (popularized by Masaaki Imai through his book Kaizen: The Key to Japan’s Competitive Success). Here is a good read if you want to know more about Kaizen.

Going back to our earlier question: Why do we want to know the status of a specific process? The answer is simply to improve.

Oh, and that data + context we are talking about, that’s right:

Data + Context is metric!

Now we know that without metrics, forget improvements, assessing any process will be rife with bias and subjectivity.

But we also have to remember that it’s a means to an end, in fact, you should never measure something for the sake of measuring it. If you are a member of an agile team, and you think the metrics used are useless (e.g. the number of team members that have completed agile training), it is imperative for you to challenge it.

Agile Metrics

Now that you know metrics are our friend, here are 4 common performance measures you can choose from.

1. Speed

One of the more popular metric for Speed is Velocity, although, a word of warning, it is also maybe the most misunderstood. If you are starting out, Description and antipattern described in this article by Agile Alliance is quite helpful.

If your team has implemented this for some time and you have some questions, the understanding presented in this nifty article on this subject is, well, quite nifty.

2. Process Health

The most popular used in teams for process health is Burndown chart. Also if you are a team starting agile development, a Self Assessment test is a good tool to measure how your team matures in term of agile implementation, bear in mind that maturity measurements works best as discussion tool for improvements rather than evaluation tool, people need to sign up for it.

3. Quality

When we are talking quality, then first we must consider Code Coverage, be careful though, this metric is simple, easy to understand, calculate and quantify, but to have this metric work for the team, watch for some antipattern that can arise. Here is a simple article that points out the dangers of having Code Coverage for code coverage’s sake. One more useful metric is Defect Leakage.

4. Joy

Joy is the least straightforward, but one of (if not) the most important measurement. The Joy measurement in itself may not tell much, but used in conjunction with other measurement may prove it to be highly valuable. For example, if your burndown chart and defect leakage is improving greatly but your NPS shows many detractors, then the team may be burned out.

Metrics for measuring Joy includes NPS, or an anonymous survey taken at the end of each sprint. The point is not to address individual qualms, but more to have a gauge on the team’s temperature.

Tying it All Together

Many of us are familiar with the adage “you cannot improve what you cannot measure”, in this context, i would like to reword the adage to:

“you need only measure what you desperately need to improve”

In other words, Focus is key. The rule of thumb is any human cannot focus on more than 3–4 things at any given time. So set maximum 4 things to measure and improve, and choose the appropriate metric to track and assess that. If you are looking for ways to effectively cascade your business goals to team and individual level, you can look up OKR (Objective Key Result), the internal grading system first introduced in Google.

Finally: Make metrics visible to everyone, put it on a board where people gather, or if you use a system to track it, show a dashboard via a monitor where it can be seen by everyone.

Ask yourself this, if you want to lose 2kg in 3 month, which scenario has a better chance of success: One where you declare the goal in your head and no one knows about it? Or one where you tell everyone close to you about your goal and ask them to support it?

Lastly, don’t get obsessed with metrics, listening to what team members are saying during retrospective is equally important in setting up a high performing team. You may need to tweak or even change what to measure depending on what the team deems important.

Happy measuring!

Like to tinker and learn through trial and error? We might use your quirky mind in our team! Join us in making the next life-centric digital solutions!

Common Metrics for Agile Team was originally published in DKatalis on Medium, where people are continuing the conversation by highlighting and responding to this story.