The Agile mindset

Introduction

The agile mindset is our passion. We believe that it will change the world to make companies healthier and employees happier.

We are now working with agile teams for more than 10 years. We have seen many different companies and projects using agile methods. There is a lot of information out there about the agile Manifest, Scrum, Kanban, XP and many more. Still we and especially our clients have a lot of questions how to transform a traditional company into an agile company. The agile mindset was initiated by IT people. So most of the time the IT department, especially the development starts to use Scrum or Kanban. Soon questions about how to embed the agile operation model into the rest of the company pop up.

We assume that many people out there will have similar questions we try to solve all day long. Our goal is to share these questions with you and try to find the best solution with your help. We want to use these solutions as patterns and develop an operation model for agile companies.

We want to raise questions in areas which are covered by some of the agile methodology but where information is missing or where there is too much interpretation possible. We also want to raise questions in areas which are not covered by the agile readings so far.

The following areas seem to be especially interesting to us:

• Organisational structure
• Product management
• Agile teams

Organizational structure

A company is a complex system. It needs to interact with employees, partner, shareholder and customer. None of them is acting rational, that means it is not fully predictable how they will act and react.

To manage this complexity Frederick Winslow Taylor introduced the scientific management theory in 1911. The goal was to encourage production efficiency and productivity by knowing exactly what you want persons to do and then see in that they do it in the best and cheapest way. According to Taylor, scientific management affects both workers and employers, and stresses the control of the labour force by management.

This is the organizational structure still found in 90% of the companies worldwide. It seems very obvious that something introduced in 1911 is not a good fit in 2017. Especially because the circumstances when Taylor was writing 'scientific management' was focusing on the industrial revolution. At that time labor was mainly used in fabrics producing goods that could be clearly specified. This is also one prerequisite specified by Taylor.

So why is this relevant to us? Because most of the problems within companies trying to adopt agile practices are because of the hierarchical (=Taylor base) organizational structure. It fosters to keep the focus inside the company instead of focusing on the customer. Beside that Taylors model  cannot handle complex situations. The assumption is that the manager exactly knows what a person should do. But in our complex world the manager has less information about a product than the product owner. This leads to wrong decisions.

Szenario 1)
Imagine you set up a Scrum team with a Product Owner (PO), some developer and a Scrum Master (SM).  The product owner does surveys with future customers and tries to analyze the market. He has a good overview of the competition and creates user stories for an MVP (minimum viable product). Now the hierarchical structure jumps in. Someone from top management wants to get a presentation to understand what the team is creating. He immediately starts discussing with the PO about the MVP. The manager is above the PO within the hierarchical structure so the PO needs to change the MVP. Then the marketing manager will jump in and again he wants to change designs. The same will apply with legal, customer care and so on. At the end the MVP will look very different, most likely much more complicated.

For sure we cannot build features without the business experts but it would be good to have experts for the product area. They experts will need to find solutions for the product. Most of the time it is the other way round. The product management is asking to get approval from the business experts rather than the business experts getting approval from product management if they found a solution that is smart and focus on the customer.

Product management

The goal of a company is to either service a customer/partner or to produce one or more products. Especially for IT products the ratio of products never or rarely used is at 70%. This means that most of the features are waste. Agility is all about avoiding waste, so one important part of the agile mindset is focusing on building the right products.

At least we should fail fast if we find out that the product will end up to be never or rarely used. As soon as we stick to plans just because of the plan itself we will never fail fast. The goal is to evaluate early and often so that we can make the decision as soon as possible if we detect that the product is not the one the customer wants.

Agile teams

Many companies adopt agile principles nowadays. They start using Scrum or Kanban by training some employees as Scrum Master and Product Owner. As soon as the team starts using agile methods they find out that there are many questions not answered in trainings and in books:

• Why does the Sprint planning takes so long?
• When is a ticket done?
• How to handle releases if there are many Sprints within one release? 
• How to interact with IT-Operations?
• What does it mean to have a deployable artifact?
• QA is not included in Scrum. Should they be part of the team? How to do regression testing?
• What is DoR, DoD?
• How to estimate Sprints? Why is the velocity now growing?
• Retrospective: I think we can skip them? Which value does a Retro have?
• Impediment list: Why are impediments not solved? Does the team have an impediment list?
• Grooming sessions: What is this? Why do we need it?

The goal is to specify more clearly how to operate agile teams and setup templates and best practices.