Beweg dich, um agil zu bleiben

Move to stay agile

In today’s world, in my opinion, standing still in your job is the same as committing career suicide–this applies to individuals as well as the teams they work in. The world is moving at a tremendous pace, technologies and their respective ideas are becoming quickly antiquated. The evolving workplace continually challenges people’s roles and responsibilities to the point that they induce, relatively speaking, identity crises. How shall we move forward? What do we change? How can we improve? How do we satisfy our customers? These questions are posed by our colleagues every day. Are you and your teams working the same way as you have in the previous year? If you answer yes, I assume then that you are satisfied with the value your customer has reaped from your team’s services and works. In my experience, this is often not the case. In my coaching experience I often get the feeling that teams are unhappy with their progression, and the goals they have (or have not) yet achieved–therein lies crux.

New roles, new responsibilities, and new leadership paradigms quickly challenge the assumption we’ve held at our workplace—nowhere is that most strongly felt than in the IT industry. The trend towards “agile” ways of working have been eagerly followed, adopted (in some ways incorrectly) in a hasty attempt to survive and keep up with the customer’s needs. Agile methods have begun to seep into various departments in your organisation, even in departments that aren’t directly IT related. This puts us in a roughly challenging position, keenly felt by long-time employees (and teams), who have traditionally over a period of time, cut themselves a little niche market of know how that gives them a sense of identity and value. They have the impression that they have power over the company because they see themselves as essential and non-replaceable and this is neither beneficial to the company nor the team.

Beweg dich, um agil zu bleiben

SPF Illustration (c) Copyright 2019

In my opinion, nothing could be further from the truth. During my years on the field in organisations developing their know-how, expertise and capabilities, I’ve always maintained an attitude of sharing knowledge and making knowledge accessible to everyone in the organisation. Knowledge belongs to the whole organisation, and so I’ve actively coached teams and delegated responsibility to them, regardless of their age or experience.

Some time ago, I was asked to transform a team from a static, silo based, waterfall, low performance team (with a ridiculously bad reputation within the IT department) into an ever improving team applying scrum. There were many employees who believed this within the department. I had two of them in my team. One was an external contractor who had become part of the furniture because she had been there so long, and the other was an employee who had been the only person working in his field (at this company) over the last 10 years. Both of these employees were absolutely certain that without them the company would grind to a halt.

Unfortunately, not everybody wants to use scrum or to be agile. And so it was in this team, the members just did not want to do scrum because of what it meant for them. If I had a dollar for every time somebody in this team said “but it just works, let’s not change it” I would be rich. The single biggest problem was the fact that it was required for the team to change to way it communicated and worked. It meant that they would need to interact with other people at eye level (within the team and throughout the company), and this was categorically rejected. Secondly it meant they would need to share their knowledge, and help other people, and as I found out, this was a “no-go” to these more experienced employees, who were scared of the consequences. After beating my head against the team wall for many sprints (yes, we were sprinting) I still could not get my team to grasp the benefits of sharing and growing and moving forward. They refused to budge from their standpoint, and I wasn’t able to remove their fears that were being driven by these two employees mentioned above.

Eventually something had to give. And true to form it was the external consult who was the first to be removed from the team. I still remember her parting comments at her farewell dinner. “Mark my words, without me, you will get nothing done. You will come begging me for help within weeks” . I suppose I always loved a challenge, but I feared the team might not be up to this one, as at least half the team shared her view, and my trust in the team had begun to wan. I knew that we would need to implement a few little changes (small steps) and the team would be required to leave their comfort zone and move on. Losing somebody with this much know how always impacts negatively on the team and we were hard pressed to fill the gaps. The steps the team did implement, although we were taking more time than before, did start to take root, and with good retrospectives being held every sprint, the team got to grips with the loss. We continued to implement small steps every sprint and we did move forward. In particular I noticed a massive increase in team members know how during this time. I´m pleased to report that 6 months down the line, the team had not contacted the consultant at all, and the team was producing code faster and with less bugs than before.

As to the second employee, this was a different kettle of fish. Not liking the new direction the team was moving forward and after we hired a junior developer to help in his area of expertise, he felt compelled to resign and move on. He was not enjoying his work, he didn’t want to work with anybody, and certainly was not prepared to share his knowledge. To be honest this made me sad for him, but what made me angry was his comment when handing in his resignation to me: “When I leave, you can close the company doors. Without me you cannot continue to do business because I am the only one who knows how this area works” . My blood was boiling and so to ensure that he was able to leave immediately and not impact the team negatively, I waived the period of resignation and cut it down to the bear minimum for a handover of their daily tasks. The team decided that we wouldn’t even have know how transfer sessions with him.

Again, the team sat down together and we were forced to implement some small changes (even one or two radical ones) to take up the slack. Our comfort zone was gone again. It was clear that we had to move a bit more. The team accepted the challenge and we moved, using small steps while sharing the knowledge gained and helping our new young team member to get his feet. After the person in question had left, it took just 6 weeks before the affected department came to me to offer feedback. The feedback I got was staggering. They thanked me for the smooth transition from the old to the new employee without any down time or interruption in service; and secondly, they praised the new employee for his adaptability, his initiative and independence, for his incredible ability to do what they wanted, in a friendly and uncomplicated way, while delivering their requests faster and with a higher level of quality than they had ever seen before. Additionally they stressed on me that they had felt an increased team awareness of this area, and that the team seemed to be sharing a great deal of responsibility and know how for this department. They blatantly asked me why I had not implemented this change before.

In both situations, it was clear that the employee’s opinion of their abilities and area of impact within the company was completely incorrect and cemented that age-old adage that “no one is irreplaceable“. Although I eventually stepped down as scrum master, I was always impressed by the way the team had mastered these challenges. They did this not by standing still, but by continuously inspecting and adapting to meet the new situation while assuming more and more of the responsibility for the product themselves. Yes, as scrum master, I was the catalyst for this by enforcing that we stuck to the agile values and principles while implementing scrum correctly, but even after I left the team, it continued to grow as they implemented small steps to bring them closer to that goal of goals, a high performing agile team. To me this is what it is all about. Yes, you can stand still but then the world will pass you by. You will get left behind even if you do have a high repository of information. And your belief that you are essentially and irreplaceable will disappear like mist on a warm day. Slowly at first, but faster and faster once it warms up. This applies to teams and to individuals. But if you keep moving and keep sharing, if you inspect and adapt then your team (and you yourself) will continue to grow and hopefully you will be happier doing it.


Dein Kontakt

Richard Gathercole

Richard Gathercole

The 7 Qualities of Highly Effective Teams

The 7 Qualities of Highly Effective Teams

It’s been a long time since you last worked with a functional team, you wonder how you can get them to the state where they are simply in synch, cooperating with one another, and effectively getting things done without all the interpersonal problems between them. Your colleagues are trying to convince you that agile is the problem, but you’re not so convinced. You knew that they were dysfunctional long before agile, and if you are new to your team you know very well that agile can’t be the problem–I mean, how could a methodology cause your team’s dysfunction? It makes no sense whatsoever. Your agile coach told you that it’s possible to have a functional team, it sounds good, but how do you even notice when a team is functional? All you’ve seen are dysfunctional teams. Let’s add to what your agile coach, or scrum master told you over a coffee break.


The 7 Qualities of Highly Effective Teams

SPF Illustration (c) Copyright 2019


„What do high performing teams look like?“ you ask. That is a good question. Can you put it into words if someone asks?

Let’s compare notes and after we’ll tell you how you can get started on the road to high team performance.

A unified outlook
Ownership and accountability in their work
A high level of emotional intelligence
A visible culture of excellence
A passion for their work
Alignment on performance objectives with other departments
Supportive and inspiring leaders

Absence of trust
Unresolved conflicts
A mass exodus of talent
Becoming too comfortable
Lack of decision-making
Blame and lack of responsibility
Avoidance of vulnerability
Workload imbalance
scapegoating and subgroups
Fixating on past and current problems


The list of traits for a dysfunctional team can go on and on. But who cares about dysfunctional teams? You’re there to make them a high performing team. Before you can get the team to perform, you need to get them to agree. How do you do that? Have the team develop a charter.

No nation was ever formed without an agreed and signed constitution–the vocabulary of their cooperation, the reason for their existence, and the timeless principles that bind generations after generations of citizens.

What is a team charter?

You’ll probably recall something known as a project charter which was once used to align the objectives, participants, the scope, the budget, and the deadline for projects. It was the reference document during the development of the project itself. A team charter is similar and not something your team should leave out. Your team charter is simply the team’s constitution, their reason to exist, the principles and values they share that transcend their selfishness and egos.

These are the effects of creating a team charter:

  • Securing team buy-in, including the team members who have shown resistance in the past.
  • Holds all team members, including developers, leadership personnel, and anyone else taking part in the work accountable, to the same principles.
  • Identifying and defining roles and responsibilities in a clear, measurable way.
  • Identifying and defining operations such as ways to adapt to change and how impediments are addressed
  • Defining the team’s reason for existence, its mission and purpose to the entire organisation
  • Gives clarity and reduces confusion in case of conflicts arising during the work.

The team charter is a living document

Remember, creating the charter itself is enough to bind the team in an agreement; however, actively taking advantage of the team charter will effectively increase its benefits. To ensure the team charter remains a living document, you can:

  • Put it somewhere visible, where the team can see it all the time.
  • Digitise and document it in your documentation tool.
  • Link your other documents to it, like the definition of done, or the definition of ready
  • Review elements such as „who do we serve“ in the backlog refinement meeting to remind the PO, and yourselves what the answers to these questions are:  „What is the point?“ „Who cares?“
  • Use it in your sprint planning to help you prioritize.
  • Reference it in your retrospectives, when team members violate the principles agreed in the charter.

People who don’t know each other, who have different motives and reasons for doing what they do, need some sort of agreement, a familiar vocabulary that is not only transparent but also positively reinforcing. Take a look at the example principles and values defined as statements often found in team charters.

Fighting Fair

  1. Think about and enjoy our differences
  2. Don’t interrupt anyone, let them have their say
  3. Everyone has a chance to respond and then it is your turn to listen
  4. Remember, we are nice people
  5. Win: win – try to understand what people want
  6. People are to speak in a calm manner
  7. Be respectful
  8. Take work and feedback seriously, but not too seriously
  9. Be aware of awkwardness — remember people are trying
  10. If you are angry or upset, think about moving away for a short time
  11. Give people the benefit of the doubt
  12. Breathe (source).

A team charter is a valuable asset in building a sustainable, long-term focused high performing teams. Try it out and see what happens!

Create your team charter today, and don’t hesitate to contact us should you need any help or support!


Dein Kontakt

Sufi Mohamed

Sufi Mohamed

Stefan Meier Illustration (c) Copyright 2019

Fokussierung steigert Produktivität

Sind wir doch ehrlich, wir alle haben Mühe, uns auf unsere Arbeitstätigkeiten, Prioritäten und Verantwortlichkeiten zu konzentrieren. Welche Auswirkung hat dies auf eine ganze Organisation, wenn dies der Grossteil aller Kollegen und Kolleginnen um dich herum dies auch so erleben? Und was bedeutet dies für eine ganze Organisation, wenn das Fokussieren nicht gefördert sondern behindert wird? 650 Milliarden US-Dollar pro Jahr werden in US-Unternehmen verschwendet, weil viele glauben, dass Menschen Multitaskingfähigkeit besitzen (Cherry, 2019). Wie viele Aufgaben können deiner Meinung nach die Mitarbeiter deiner Organisation gleichzeitig erledigen? Eine, nicht mehr. Das menschliche Gehirn ist nicht in der Lage, Multitasking zu betreiben (Wallis, 2006). Wissenschaftler nennen dieses Phänomen „Task-Switching“ oder „Context-Switching“. Das ist es, was das Gehirn tatsächlich tut.


Stefan Meier Illustration (c) Copyright 2019

Stefan Meier Illustration (c) Copyright 2019


Warum du nicht ‚Multitasking‘ kannst?

Das menschliche Gehirn kann nicht gleichzeitig zwei Objekte mit gleichem Fokus halten. Der Mensch wählt aus, worauf er achten möchte. Das Gehirn entscheidet immer was wichtig ist, durch einen Mechanismus, den Psychologen „adaptive Exekutivkontrolle“ nennen (Meyer, 2008). Der Mensch befindet sich in einem ewigen Start-Stopp-Start-Stopp-Zyklus. Die Aufgabe, für die du normalerweise 15 Minuten gebraucht hättest, dauerte jetzt 2 Stunden. Das liegt daran, dass alles andere was du während der Ausführung dieser Aufgabe begonnen hast, deine ursprüngliche Schätzung verlängert hat, und die anderen Aufgaben, die du dazwischen erledigt hast, haben Sie auch länger als geplant gebraucht. Du wirst bald frustriert feststellen, dass du nicht wirklich etwas erreicht hast.

Stell dir das vor: 1000 Mitarbeiter einer Bank machen genau das Gleiche – ‚Multitasking‘.

Was sind die Folgen von ‚Multitasking‘?

  1. Du brauchst mehr Zeit, um Aufgaben zu erledigen, als wenn sie sie einzeln erledigen würden
  2. Du machst mehr Fehler beim Aufgabenwechsel, als wenn du eine Aufgabe nach der anderen erledigt hättest
  3. Je komplexer die Aufgabe, desto mehr Risiko gehst du beim Aufgabenwechsel ein
  4. Auch wenn der Aufgabenwechsel lediglich 1/10 einer Sekunde dauert, wenn dies eine Gewohnheit ist, wirst du trotzdem mindestens 40% deiner Produktivität verlieren (Quellenangabe).

Zumindest hat nun die Bank 60% der Arbeit erledigt, oder? Falsch. Die Realität ist, dass selbst unter den geleisteten Arbeiten die Wahrscheinlichkeit, qualitativ hochwertige Arbeit erbracht wurde, bestenfalls minimal ist.

Was bedeutet Kontextwechsel in Organisationen?

Kontextwechsel in der Organisation bedeutet, dass die Person, die eine Aufgabe ausführt, von einem Projekt zum anderen wechselt. Die Zeit, die benötigt wird, um zur ursprünglichen Aufgabe zurückzukehren, dauert jedes Mal länger.

Focus spart geld

Im Buch Quality-Software-Management: Systems Thinking untersuchte Gerald Weinberg die Auswirkungen der Produktivität auf ganze Teams. Weinberg stellte fest, dass ein Teammitglied, das nur eine Aufgabe erfüllt oder an einem Projekt gleichzeitig arbeitet, dort 100% seiner Arbeit einsetzt und höchstwahrscheinlich mit der höchsten Qualität der Lieferung erfolgreich ist. Ein Teammitglied, das zwei Projekte gleichzeitig durchführt, produziert bis zu 40% Verschwendung (ca. 20% pro Projekt) wenn es den Kontext wechselt. Der Fokus wird nicht gleichmässig auf die Projekte verteilt sein, die Person wird sich entscheiden, welches Projekt mehr im Fokus steht. Je mehr Aufgaben ein Teammitglied parallel bearbeitet, desto mehr Zeitverschwendung entsteht. Das Unternehmen muss dann akzeptieren, dass bei fünf oder mehr parallelen Aufgaben 80% der Bemühungen dieser Person aufgrund des dauernden Kontextwechsels verloren gehen. Wieso: das Teammitglied muss zuerst immer zuerst den Kontext der Aufgabe fokussieren und verstehen, bevor es tatsächlich damit beginnen kann.

Wie können agile Methoden dazu beitragen, den Fokus zu verbessern?

Einer der wichtigsten Werte bei agilen Methoden ist der Fokus. Es ist absolut wichtig, sich darauf zu konzentrieren, Dinge zu erledigen, anstatt die endlose Verschwendung fortzusetzen, die durch das Start-Stopp-Start Phänomen entsteht. Ohne diesen Fokus können wir uns nie sicher sein, was wir tatsächlich erreichen.

Fokus hilft uns dabei:

  1. unsere Aufmerksamkeit auf die Bedürfnisse des Kunden richten
  2. die Wertschöpfung als unser zentrales Ziel zu erhalten
  3. Aufgaben priorisieren und mit dem Ziel arbeiten, Ergebnisse zu erzielen
  4. die wichtige Arbeit beenden
  5. effektiv miteinander kommunizieren
  6. zielgerichtete Meetings und Engagements zu haben
  7. mit Blick auf die Qualität zu liefern
  8. die Kosten der Verzögerung zu reduzieren
  9. Risiken effizienter zu minimieren
  10. und zu guter Letzt: die Arbeit in der Hälfte der Zeit zu erledigen

Bei der Optimierung für den Fokus lernen wir, dass ‚Multitasking‘ kein geeignetes Vorgehen ist, somit der Kontextwechsel schädlich ist und dass unsere Organisationen auf einfache, effiziente Prozesse ausgerichtet werden müssen, um Verschwendungen zu reduzieren.

Die Agilität hilft uns dabei, indem es uns ermutigt:

  • zeitnahes Feedback einzuholen
  • kurze Iterationszyklen für schnelles Feedback zu haben
  • frühzeitiges validieren von Ideen und Lösungen anzustreben
  • Erwartungshaltung zwischen den Partnern zu definieren (so z.B. zwischen Kunden und ihrer Organisation mittels Akzeptanzkriterien)
  • kurze, aber regelmässige Treffen abzuhalten
  • aus den bisherigen Erfahrungen schnell zu lernen, damit die Menschen, das Team und die Organisation effizient vorankommen können


Fokussierung hilft dir, dein Ziel für dich, für das Team und für die Organisation als Ganzes zu erreichen. Als Hilfsmittel dafür unterstützt dich der SPF Agile-Health-Check u.a. den Fokus deiner Organisation zu überprüfen. Mache das Fokussieren zu einem wesentlichen Kulturelement in deiner Organisation.


Hier erfährst du mehr über den SPF Agile Health Check.

Dein Kontakt

Samuel Fankhauser

Samuel Fankhauser