Beiträge

Agile Health Check - Wir sind stark - Maturitätsmodelle

3 Gründe, warum agile Maturitätsmodelle wenig bringen

Agile Maturitätsmodelle, welche die agile Reife eines Teams prüfen, sind weit verbreitet in der IT-Industrie. Man könnte nun meinen, dass Dinge, die weit verbreitet sind, auch einen entsprechenden Nutzen bringen. Leider ist dem meist nicht so (siehe auch https://www.scrum.org/resources/blog/heres-whats-wrong-maturity-models). In diesem Artikel erkläre ich dir, wie ein typisches Maturitätsmodell aufgebaut ist und anhand von drei Faktoren, welche Problematiken damit verbunden sind. Zum Schluss zeige ich dir eine Möglichkeit, wie du die Problematiken der traditionellen Maturitätsmodelle umschiffen kannst.

Agile Health Check - Wir sind stark - Maturitätsmodelle

Typische Merkmale eines Maturitätsmodells

Als erstes müssen wir klären, was denn ein typisches Maturitätsmodell ausmacht. Grundsätzlich geht es davon aus, dass es verschiedene Stufen der Agilität (meist vier bis sechs) gibt, die in aufsteigender Reihenfolge erlangt werden können. Eine Stufe kann dabei nicht übersprungen werden. Zuerst muss eine Stufe vollständig erlangt werden, erst dann geht’s weiter mit der nächsten Stufe.

Um zu prüfen, ob eine Stufe erreicht ist, gibt es eine Liste mit (meist sehr konkreten) Fragen, die beantwortet werden müssen. Je mehr Fragen mit “Ja” beantwortet werden können, desto höher ist die erreichte Punktzahl. Entweder beantwortet das Team selbst die Fragen oder ein externer “Assessor” beantwortet sie nach Beobachtung des Teams. Am Ende ergibt sich eine Gesamtpunktzahl mit der erzielten “Maturität”. Aus den Fragen, welche mit “Nein” beantwortet wurden, ergibt sich somit automatisch das Verbesserungspotential für das bewertete Team.

Problem Nr. 1: Maturitätsmodelle sind statisch und starr 

Wie oben erwähnt, bestehen typische Maturitätsmodelle aus einem Set an Fragen, die es zu beantworten gilt. Das Problem dabei ist, dass eine Änderung von Fragen im Modell (z.B. aufgrund von neuen Erkenntnissen) dazu führt, dass die Werte nicht mehr vergleichbar sind. Daher bleiben solche Modelle meist über längere Zeit stabil, um diesem Problem zu begegnen. Das macht sie natürlich sehr starr und schwerfällig gegenüber Änderungen. Wie wir alle wissen, ändern sich die Vorgehensweisen in der IT rasend schnell. Mit diesen Änderungen veralten die Maturitätsmodelle ebenfalls sehr schnell und werden damit je länger je weniger relevant.

Zudem ist dieser fixe Fragenkatalog für ein Team ziemlich langweilig. Spätestens nach dem zweiten Mal wird es die Fragenbeantwortung entweder an jemanden delegieren oder nur noch oberflächlich beantworten, ohne dabei gross nachzudenken. Das ist jedoch genau das Gegenteil von dem, was ein Maturitätsmodell erreichen möchte. Dass sich Teams selbst hinterfragen und von sich aus bessere, effizientere Wege finden ihre Arbeit zu erledigen. 

Problem Nr. 2: Maturitätsmodelle sind einengend 

Eine weitere Problematik besteht in der Art und Weise der Fragen. Meist werden Praktiken abgefragt, welche zwar agiles Arbeiten bedingen, jedoch lediglich die Spitze des Eisbergs darstellen (vgl. auch https://www.borisgloger.com/blog/2020/07/17/doing-vs-being-agile-erfolgreiche-agile-teams-1).

Daneben gibt es eine Vielzahl von unterschiedlichen Praktiken, die je nach Teamzusammensetzung, entwickeltes Produkt, Branche, Entwicklungsvorgehen, Skills, usw. sehr unterschiedlich sein können. Vielleicht fehlt ja genau diese eine Praktik, die perfekt für das spezifische Team wäre und einen hohen Nutzen bringen würde. Es scheint daher ein wenig anmassend zu sein, mit einem Maturitätsmodell zu wissen, welche Praktiken für ein Team “gut” sein sollten. Fokussiert ein Modell hingegen auf Werte und Prinzipien, so ist die Beantwortung der Frage meist Auslegungssache und wird pro Team unterschiedlich interpretiert. Dies ist jedoch ein Graus für das Management, möchte es doch eine Vergleichsbasis haben. Das führt direkt zum nächsten Punkt.

Problem Nr. 3: Maturitätsmodelle werden zweckentfremdet

Mit Maturitätsmodellen, welche am Ende eine Punktzahl ausspucken, ist dem Missbrauch Tür und Tor geöffnet. Für ein klassisch denkendes Management ist dies ein perfektes Instrument, um die agile Reife von Teams zu vergleichen und im schlechtesten Fall sogar noch finanzielle Anreize (z.B. im Rahmen von MbO Prozessen) darauf zu setzen. Agilität ist jedoch sehr individuell und entwickelt sich in jedem Team anders. Sobald ein Team merkt, dass damit gemessen und verglichen wird, wird es das “Spiel” mitspielen und die Fragen so beantworten, dass es in einem guten Licht dasteht. Damit ist der Nutzen ad absurdum geführt und stellt lediglich eine Belastung (waste) dar.

Dass es auch anders gehen kann, seht ihr im nächsten Abschnitt.

Unsere Alternative: SPF Agile Health Check

Was unterscheidet nun unseren “SPF Agile Health Check” von den oben skizzierten Modellen?

Aufbau SPF Agile Health Check

Der “SPF Agile Health Check” besteht aus fünf Dimensionen mit denen sich das Team auseinandersetzt:

  • Wert erzeugen
  • Qualität liefern
  • Fokussiert bleiben
  • Als Team agieren
  • Beweglich bleiben

Diese fünf Dimensionen sind typisch für agil vorgehende Teams.

  • Als Beispiel ist es Aufgabe im Product Ownership (in Scrum z.B. via Product Owner), den Wert des Produktes des Teams zu maximieren. Qualität ist in agilen Vorgehen ein inhärentes Merkmal.
  • Qualität ist nicht verhandelbar. Falls die Qualität vermindert wird zugunsten von schnellerer oder umfangreicherer Lieferung, so stellt dies eine technisch Schuld dar und muss in Zukunft irgendwann wieder abgebaut werden. Erlaubt der PO dies zu oft, so wird das Produkt sukzessive schlechter in der Qualität. Im Extremfall führt dies dazu, dass entweder die Kunden abspringen (obwohl man ja viel Funktionalität geliefert hat) oder dass das Team im Sprint nur noch mit dem Herstellen einer vernünftigen Qualität beschäftigt ist und deshalb keine neuen Features mehr liefern kann.
  • Der Fokus ist sogar ein dedizierter Wert im Scrum Guide. Fokus erreicht ein Team in Scrum automatisch, da es innerhalb kurzer Frist, z. B. zwei Wochen, ein funktionierendes Produktinkrement liefern muss. Weiter wird im Scrum Guide ein Product Goal sowie ein Sprint Goal definiert. Dies stellt ebenfalls eine Fokussierung dar.
  • Teams stellen den eigentlichen Motor in der Agilität dar. In Teams wird Wert geschaffen. In Teams arbeiten Individuen zusammen und es entsteht Interaktion, Kommunikation, Zusammenhalt, Identifikation und vieles mehr. Wie wichtig Teamarbeit ist, zeigen diverse Studien. Details sind hier schön erklärt: https://www.atlassian.com/blog/teamwork/the-importance-of-teamwork
  • Beweglichkeit, der eigentliche Ursprung des Wortes Agilität (Engl: agile, Lat: agilis für beweglich, flink) ist in der modernen Softwareentwicklung ein Grundelement seit der Gründung des “Manifesto for Agile Software Development” (2001). Reaktion auf Veränderung wird dort höher gewichtet als die Planbefolgung. Dies ermöglicht in einer schnelllebigen Welt (VUCA) auf Veränderungen möglichst rasch zu reagieren.

Zu jeder dieser fünf Dimensionen besteht jeweils ein Set an Aussagen. Diese Aussagen beurteilt das Team nun anhand von zwei Kriterien:

  • Wie leicht fällt es uns dies zu tun?
    Wie schwer fällt dir eine Aufgabe?

    Wie schwer fällt dir eine Aufgabe?

     

  • Wie regelmässig tun wir dies?
    Wie häufig machst du eine Aufgabe?

    Wie häufig machst du eine Aufgabe?

Als Resultat entsteht am Ende ein Bild pro Dimension mit einer Einschätzung des Teams zu den vorhandenen Aussagen:

AHC - Dimension Wert

Agile Health Check – Dimension Wert

Nach Beurteilung der fünf Dimensionen diskutiert das Team darüber, wo es gerne Fortschritte machen möchte und welche Massnahmen es zur Umsetzung definiert. Daraus ergeben sich die folgenden Vorteile:

Flexibilität im SPF Agile Health Check

Wie oben ersichtlich ist, können die Fragen pro Dimension spezifisch für das Team, das Produkt, die Branche oder das Entwicklungsvorgehen sein. Das spielt letztlich keine Rolle hinsichtlich des Ergebnisses. Wenn ein Team findet, dass bei ihnen zum Beispiel eine andere Dimension zusätzlich wichtig ist, so kann es diese selbstverständlich hinzufügen oder eine bestehende ersetzen. Dabei ist zu beachten, dass die Fragen bezüglich den Kernwerten der Agilität nicht “herauskonfiguriert” werden.

Weiter sind auch die zu bewertenden Aussagen flexibel und können nach Bedarf angepasst werden. Dies geht spielend einfach kann sich ebenfalls von Team zu Team unterscheiden. Wir stellen zwar ein Grundgerüst an Aussagen aufgrund unserer Erfahrung mit unzähligen Teams zu Verfügung. Dies stellt aber kein Muss dar. Es hat sich aber als bewährt herausgestellt und es ist eine Frage von Kosten/Nutzen, wieviel Zeit der Kunde in eine konfigurierte Version investieren möchte.

Somit ist unser “SPF Agile Health Check” rasch an neue Gegebenheiten und Entwicklungen angepasst. Und da keine Zahl zum Maturitätslevel als Ergebnis vorhanden ist und damit auch ein Vergleich von Teams bewusst keinen Sinn macht, ist das Modell auf Änderungen gut vorbereitet.

Offenheit und Individualität des SPF Agile Health Check

Wie vorher grad erwähnt, ist das Anpassen auf spezifische Team- oder Firmengegebenheiten kein Problem. Orientiert sich ein Team an Scrum, so sind die Fragen in diese Richtung zu beantworten. Wenn ein Team nach Kanban vorgeht, dann sind die entsprechenden Begriffe aus der Kanban-Welt relevant.

Findet ein Team eine Frage als nicht relevant, so wird sie elegant aus dem Spiel genommen. Dies beeinträchtigt weder das Ergebnis noch das Vorgehen im Workshop. Im Gegenteil, das sichtbar machen führt dazu, dass diese bewusste Entscheidung des Teams transparent ist und bei einer nächsten Durchführung wieder ins Bewusstsein rückt.

Im Workshop selber findet bei der Positionierung der Frage auf dem Flipchart die entscheidende und wertvolle Diskussion statt. Damit wird innerhalb des Teams eine gemeinsame Sicht auf den Stand der Agilität erarbeitet. Es geht nicht um das “Erfüllen” von vordefinierten Kriterien. Das fördert letztlich den Teamzusammenhalt und am Ende hat man ein gemeinsam erarbeitetes, sichtbares Resultat.

Und letztlich der Spassfaktor beim SPF Agile Health Check

Durch die lockere Art des Arbeitens mit Flipchart und Zeichnungen wird zudem der Widerstand gegen solche “Assessments” reduziert, da schnell klar wird, dass es nicht um die Erreichung von einem Zustand geht, sondern ein gemeinsames Bild zur Agilität geschaffen wird. Ebenfalls ist die Positionierung innerhalb der beiden Achsen keine Wissenschaft, da die Achsen bewusst “schwammig” gehalten werden. Das soll verhindern, dass plötzlich die Komponente Auswertung und Vergleichen ins Spiel kommt.

All das führt dazu, dass Teams einen “SPF Agile Health Check” nicht als formales Assessment betrachten, sondern als Möglichkeit, als Team weiter zu wachsen und besser zu werden. Ziel erreicht 🎯!

Möchtest du auch einen Versuch wagen? Dann sprich mit uns. Gerne führen wir für dich einen “SPF Agile Health Check” durch, damit auch die dies erleben kannst und mit deinem Team weiterführen kannst.

 

Dein Kontakt

 

Stefan Meier

Stefan Meier, Agile Coach

E-Mail: stefan.meier@spf-consulting.ch
LinkedIn: https://www.linkedin.com/in/thinkquality/
Kontakt zu SPF: https://www.spf-consulting.ch/kontakt/

 

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
Email: richard.gathercole@spf-consulting.ch
Kontakt: https://www.spf-consulting.ch/kontakt/

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
Resignation
Becoming too comfortable
Lack of decision-making
Gossiping
Blame and lack of responsibility
Silos
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
Email: sufi.mohamed@spf-consulting.ch
Kontakt: https://www.spf-consulting.ch/kontakt/