Loss of humility easily and quickly

Loss of humility easily and quickly

When I finished my private pilot course a few years ago, I started flying a small plane to visit the surrounding airports. And it didn’t take long for me to start bringing my friends and colleagues with me. My confidence grew and after about a year I had the feeling, like many other novice pilots,

Continue reading »

Many companies use the OKR (Objectives and Key Results) framework to set the goals of agile teams, and the popularity of this approach is constantly growing. The benefits are indisputable, but what about the readiness of agile teams to start using OKR? Take a look at the 3 most common issues that agile teams can help you identify with OKR workshops: 1. Indifference to results and team focus At the workshop for defining the OKR team, only the product owner with the scrum master tries and the rest of the team more or less passively watches. One possible reason is that your team is still used to passively taking on tasks and does not perceive its responsibility for the team's results. That is why they do not yet own the team goals and do not yet see their role in defining them. The solution here is rather long-term. One option is to lead the team to teamwork and prioritize team goals over individual ones. And that's exactly the job for your scrum master/agile coach. Also, be sure to see if your reward system is based on individual goals instead of team goals. Try to involve OKR in agile team ceremonies so that they become a regular part of their lives and the team gets used to them. 2. We want to cover everything we do today in OKR Some teams initially try to make as many OKRs as possible to see that the team is doing a lot of work. A possible reason is that your team is still focused on maximizing the work done instead of maximizing value for the customer. Many teams are therefore accustomed to initially starting a large number of activities at once and have a fragmented focus. Many open activities lead to their late delivery and often to non-transparent communication about the status of these activities. The solution is again longer-term and consists in guiding product owners and teams to prioritize their work. Finish things rather than open new ones all the time. And the same applies to OKR. OKR defines only one or 2 for the team so that the OKR team remembers them and does not become just a task book, which you will always meet at the end of the quarter. And this then leads agile teams to the need to prioritize the focus on a few things. 3. Mistakes in team design OKR will also show you the flaws in the design of your agile teams. If teams have to deliver frequently and validate results with customers, it places much greater demands on teams being end-to-end. Suddenly, it will be more transparent, where the team lacks developers, or even other vital roles for a successful delivery. And so your team complains to OKR that they don't make sense as defined. Try the technique 5 times why at such a moment. You may find that this is a team design issue and not an error in the definition of OKR. If the problem is in the design of the team, think about whether you will hire the missing specialists, allocate them from elsewhere in the company, or whether someone can learn the missing skill in the team. Finally That's why we liked OKR not only because of their business benefits, but also because of how transparently they show the state of agile teams. As elsewhere in an agile environment, OKRs don't solve these problems on their own, but they can give you input on how to continue working with your team. And what is your experience with the informative value of OKRs about the state of agile teams?

How can OKR help you diagnose the state of your agile team?

Many companies use the OKR (Objectives and Key Results) framework to set the goals of agile teams, and the popularity of this approach is constantly growing. The benefits are indisputable, but what about the readiness of agile teams to start using OKR? Take a look at the 3 most common issues that agile teams can

Continue reading »

How to give feedback correctly

How to give feedback correctly

One of the basic skills of members of agile teams is the ability to give feedback to their colleagues. However, basic agile approach training usually does not provide any guidance on how to provide feedback. And so it happens that the transmission of feedback sometimes ends in the emotions of both participants or, in the

Continue reading »

Muda or 7 Types of Waste in Software Production

Muda or 7 Types of Waste in Software Production

Anyone who has ever dealt with Lean has probably encountered seven types of waste (Muda). Lean was originally created in Toyota for industrial manufacturing. That’s why it was initially harder for me to understand how I could apply this kind of waste to software production. Personally, an article on the kanbanize.com website helped me a

Continue reading »

My experience with team scaling

My experience with team scaling

It turns out that it is not uncommon for a scrum team to grow to such a size that the advantages of having a team together all the time disappear and the overhead begins to increase. We will look at how to deal with such a situation as simply as possible and avoid inconvenience in

Continue reading »

How many teams can an agile coach have at once?

How many teams can an agile coach have at once?

In a number of companies, people have recently started to fill themselves in the role of agile coaches on a large scale. For example, in connection with the Spotify “framework”, we often encounter questions about how the role of an agile coach differs from a scrum master. Is the difference between these roles really just

Continue reading »

Illusions about team performance and fragmented focus

Illusions about team performance and fragmented focus

Fragmented focus – this problem appears in almost every of the large companies that start with agility. The team has too many requests in progress than it can handle with the current number of people. Sometimes people in the team just slip into opening more and more requests. Elsewhere, part of the company culture is

Continue reading »