Beiträge

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/