High-perfomance teams? Why the leadership mindset makes the difference

women-1209678_1920.jpg

Real life example:

The days of September were over. Also, the days of summer vacation were well behind, but not for Mike. He was a developer in an Agile team, working on a top importance project. It was agreed that he will take some vacation days when all his teammates will return from sunny beaches, in October. Now, finally, his time for some days off arrived. He was working on an important user story and, not surprisingly, he was really stressed to finish everything before leaving for vacation. Putting a lot of effort, he managed to complete the story late in the evening. No one was in the office anymore. He wrote an email to the team and left for his vacation happy that “he left everything in order”. The next day, when the team checked the story’s implementation, they noticed that the it was crashing many automated testes. They tried to fix the code, but no use. More they modified, more tests would crash. After few hours of frustration and bad feelings, a team member decided to start again the implementation, checking the code that Mike left behind. It took few days of hard work until the story was ready to be demonstrated. The manager of the team received many suggestions to have a “hard talk with Mike”: he should never leave things like this. Maybe a punishment “would make him more attentive in the future”. Gladly, the manager understood deeply fundamental attribution error.

Fundamental attribution error

Fundamental attribution error is a term introduced by Lee Ross in 1977 and defines the tendency to exaggerate the role of people’s personality when it comes to their behavior and overlook the influence of the wider context. A simple example: let’s say you have a meeting with someone and the person is late. Usually, we jump rapidly to the conclusion that the person “does not respect the time of others people”, “s/he is not good at time management”, “s/he is not a serious person”, “s/he does not respect colleagues/customers/partners”, or “s/he does not care about [topic of the discussion]” etc. On the other hand, I don’t know about you, but me, when I am late for a meeting, I always have all these external factors that kept me from being on time: a car accident on the highway, an urgent call from a friend, the previous meeting went overtime etc. So, when it comes to situations with a negative impact, there is a tendency to blame others when they are the actors. Still, we blame the context when we are the actors. This explains well the “blame culture” existing in many companies.

The leadership mindset of high-performing teams

Looking at the case above, many people would react by blaming Mike. It starts with the team members, which in my view are leaders also, considering the shared model of leadership in Agile teams (check my blog on Who are the leaders of Agile teams and WHY?). It continues with Mike's manager. Let’s assume that Mike’s manager thinks that the root cause has something to do with Mike’s personality, problem that needs to be addressed. This scenario continues with two alternatives for the chat with Mike:

  1. Mike takes full responsibility. He understands that he needs to avoid at any cost getting in similar situations. In this state, it becomes so easy to decide that: he will try to avoid high importance tasks, he will not waste more time helping others, he will make sure to overestimate a lot to be certain he has more time. Mike was at the top of his attentiveness, what can be done more on that? He did the best he could, still things got wrong. Maybe, he should not care that much...In many cases this leads to emotional disengagement. Will any of these actions really avoid similar cases in the future in the company? Will this mindset lead to having a high-performing team?

  2. Mike gets into defensive mode, throws the ball of blame to someone else: someone else left the tests on red before him and he did not know that he was causing the problems, the tester of the team refused to stay late in the evening to test things out, it took him so long because another colleague was late in completing a task he depended on, the Product Owner missed something in the acceptance criteria and told him at 18:20, he helped another colleague working on a fatal bug, he had to attend all the top management meetings scheduled for that week etc. The fastest way to destroy a team is to start the blame game under the fear of punishment, because once started, it is hard to stop it. Having this approach erodes the psychological safety inside teams which is argued to be the main factor of high performing teams and trust in organizations overall (Google study 2015 - "Project Aristotle"). It generates in waves a culture where every time something goes bad, the first reaction of leaders is to search for a scapegoat and release a punishment. The natural consequence is the constant fear of not to making any mistake and when bad things happen, on finding quickly someone else to blame or hide it. So much insights on this topic can be found in Simon Sinek’s highly inspiring book: “Leaders Eat Last: Why Some Teams Pull Together and Others Don't(2017)”.

No matter what is written in the company’s stated values, culture is shaped by the way leaders behave, regardless of what they say. Schein states in Organizational Culture and Leadership (1985) that organizational culture is shaped by five behaviors that leaders exhibit, consciously or unconsciously. One of these 5 critical behaviors is the leaders' reaction to critical incidents or organizational crisis which is fast learned by the other members. The way the leaders react is the way “we do things in this company”.

Addressing the team’s context

Teams that understand fundamental attribution error are able to tackle differently these situations and are focused on building the right context, the right system, in which people are well protected and their humanity embraced. It starts with understanding deeply that if it happened to Mike, it could happen to any well-intentioned, engaged team member. The situation becomes a great learning opportunity for the team who can take a step back and ask themselves during Retrospective:

What can we do as a team so that this situation will never happen again in the future?

I witnessed teams coming together and unleashing a wealth of creative solutions which in fact take the team practices to the next level and improve the system:

  • user stories should be split into smaller ones so that no one works individually on a story for a week or two

  • code needs a peer review before being committed

  • all automated tests need to be on green before merging to main branch

  • a clearer Definition of Done (DoD) stating that code needs to be tested by someone else in order to consider it Done

  • the performance of the automated tests needs to be improved so that everyone could run them fast at any moment in time

  • pair programming more often

  • when someone leaves for a vacation longer than 5 days, they need to remind the entire team during the Daily Scrum and another team member volunteers to spend at least one hour on any needed handover

  • task rotation needs to be practiced consciously so that the team can handle urgent problems in case of unexpected days off etc.

Good Scrum Masters are able to facilitate workshops that result in concrete actions to be taken at team level. The learning process is also an iterative one in the sense that teams are challenged to find better and better solutions: What happens when a team member gets sick and misses work for two days? How about two months? What happens if the tester of the team is that team member?

Addressing the organizational context

If fundamental attribution error is your default reaction, you might catch yourself thinking now: “aha, so it is not Mike’s fault, it is his team’s fault!”. This is called group attribution error, fundamental attribution error extended to groups. Someone who is part of the team can clearly emphasize the context, the external factors that have affected the team in this case. But someone else, a manager outside the team or a member of a different team, will usually jump quickly to conclusions regarding the team’s attitude: “they don’t care about the customer”, “they are not reliable” or, even worse, “they are not to be trusted”, “they need a close control and checking”. That is why, trying to find solutions without the involvement of the team members will result often to wrong alternatives because the context is not understood. Still, it is never easy to be a manager who chooses “no blame” approach in a company with a deep blaming culture. When, as a manager, your boss wants to know “who?”, explaining your decision can quickly result in the conclusion that the person to blame is you, “not capable to manage your people”. It could be argued that managers who understand fundamental attribution error are more inclined to hold a Theory Y style (considering that people are internally motivated in their work and put their best efforts) , instead of Theory X style (people are not internally motivated to work, therefore reward and punishment is needed) according with Douglas M. McGregor(1960). Having a Theory X style while reporting to a manager with a Theory Y style becomes an act of great courage and true leadership.

It could be equally argued that this situation happened because the external context of the team was not appropriate:

  •  Maybe this is a company where there is no emphasize on caring for people. People should not be encouraged or even pushed beyond a human limit, like not taking a vacation for many months when working on an important project. There is no need to have a deep managerial experience to know that doing this will open largely the door for bad things to happen.

  •  Maybe the team had a huge time pressure. This is so often the case! It may come from a culture that rewards overpromising, management who commits on fixed scope, fixed time or management who is not considering estimations of the team.

  • Maybe the servers on which the automated tests are executed are overloaded and because of a cost cutting strategy decided by top management and despite the team’s efforts, they still take too long to run.

  • Maybe in this team the manager assigned individual targets (even the Product Owner) and all the other team members were assigned on different important tasks, without any slack time.

  • Maybe the culture of the company rewards individual effort only, there are many subtle messages that everyone should do “their part” and helping another colleague commented by managers with “this is not your job”.

  •  Maybe there is no official support in this company for automated testing/code quality actions including refactoring, because the decision makers do not still completely understand the value of it. Or, maybe the Product Owner has constantly taken out of the Sprint Backlogs the technical tasks because “we don’t have right now time for this”.

Methods like the Five WHYs have the power to reveal the root cause, if blame is always taken out of the exercise. Still, it is worth reflecting that problems can have multiple root causes, some problems show up in different teams and then solutions need to be taken at organization level, meaning management involvement is required. Great Scrum Masters/ Agile Coaches/ Agile Managers/Agile practitioners are able to facilitate, observe, understand so that improvement actions are taken also at organization level.

The key question

These types of situations are able to uncover big holes in the system and provide great opportunities to make the necessary improvements that will eliminate the root causes of the problems. That is why these situation are often called “growing opportunities”. Not being able to learn from them could be called “learning waste”. When leaders across the company have a deep understanding of fundamental attribution error, they stop the automatic blaming mode during crisis situation and start focusing on improving the system and learning. This soon becomes evidence that there is no need anymore to invest energy into watching your back. The psychological safety goes up and mistakes are uncovered and fixed quickly. A measurable sign that this is happening can be obtained by asking the survey question (used by Google):

How confident are you that you won’t receive retaliation or criticism if you admit an error or make a mistake?

Confession

I have been Mike. I will never forget that 24th December when, too eager to solve a bug, I sent an PL/SQL patch to the client and then ran to my manager saying: “I messed things up”. Gladly, I did not have credentials to install myself the patch directly into production, which I would have done, and therefore I was able to still enjoy a Happy Christmas! Good system.

I have been the colleague who stayed to help out late in the evening and the colleague who left because someone was waiting home. I have been sometimes the colleague who saved the day and been called an “angel”, but also the one who blamed or jumped to judgments. I have been Mike’s Scrum Master and Mike’s manager. And yes, I know how it feels to see Mike going home after being fired. All these experiences showed me that it is hardly ever someone’s individual fault: good people, with good intentions, sometimes get in trouble because the system is far from perfect, still, the best we knew to put in place. I also know that the blame game has no winners and that only when the blame tendency disappears, when everyone decides to step out from the blamer role, high performing teams have the context to emerge. 

Note: I am currently doing a research regarding the leadership needs of Scrum Masters, Agile Managers and Agile practitioners overall. Would you like to provide your input? I know, your time is precious. That is why, I will thank you by sending you two amazing materials on the same topic: an inspiring leader talking about psychological safety and another great example from literature of a leader healing blame culture in a non-software environment. Please let me know here. Thank you!

How does it feel to be part of an amazing team?

squad-3370836_1920.jpg

Did you ever have that feeling when you look around from your desk to the colleagues next to you and you are overwhelmed by gratitude for living that moment in time? I had the privilege to experience that quite few times and it was because I was part of an amazing team! I want to let you know exactly how it feels:

  1. There is a deep sense of purpose. Usually an amazing team is working on a higher purpose. Something that serves other people or makes the world a better place. This is very important because it creates the inspiration that everyone needs in order to stay motivated day after day without the need of any external pressure.
  2. There is a lot of trust between the team members. I see trust as this feeling of being so safe and secure that you can expose your highest weaknesses, fears or vulnerabilities because you know no one will ever use it against you. Because you have that, it is OK to admit you were wrong, it is OK to make mistakes. You are even protected from the worse versions of yourself. I remember when one colleague told me one day: “Roxana, I know that you try to help, but what you do right now is not helping us”. There is also a certain level of honesty mixed with compassion because at the end of the day you know that the team has your back.
  3. There is a lot of passion. Everyone is working on what they love. It is very difficult to feel part of an amazing team when you don’t like what you are working on. When there is a lot of enthusiasm and colleagues next to you dedicated to improve themselves and to evolve every day, the results are amazing. That takes me to the next one.
  4. A great sense of achievement. It comes from seeing the results of what we build together. That is why, it is a deeper form of success, mixed with a togetherness feeling that is very fulfilling.
  5. Joy coming from the great collaboration. In amazing teams working together is a true need, members complement each other, bring different perspectives, take care of different areas. It is crystal clear for everyone that progress could not be made alone and therefore there is a joy that someone else can give you exactly the helping hand you need.

I have to tell you that there are some unexpected side effects. Working in such a team got me into a state where I cared deeply about our work, sometimes more than I wanted to. Leaving on vacation gave me the feeling that I was missing out some things that would happen while I was away. Therefore, it got into visiting the office when I was on vacation because “I forgot my favorite pen on the desk”.  Also, leaving such a team is hard. It is a real internal conflict even when deciding to leave comes from following your goals and dreams. It is all fully worth it. I hope everyone can experience these feelings in their teams, because being part of an amazing team is one of the most wonderful experiences we can get from our professional lives!

Thank you to those beautiful people who allowed me to experience this. You will always have a special place in my heart.

10 steps to effective meetings that feel great!

Thank you to Startup Stock Photos for kindly sharing this photo  on Pexels

Thank you to Startup Stock Photos for kindly sharing this photo  on Pexels

We’ve all been there:  bored in a meeting that we can hardly wait to end, wondering “why am I at this meeting?”. The most common negative argument I hear from teams adopting Agile is that “there are too many meetings”. After discussing why they feel that, I always discover the same reason: the problem is not connected with the number of meetings, but with the poor quality of the meetings. Bad meeting are not only a waste of time and energy, but also affect the moral of the team and even the relations among team members. Still, despite clear consequences, tolerating bad meetings is quite common in corporate environments because it is so hard to pinpoint what goes wrong. That is why, knowing how a great meeting looks like is a good thinking tool because it makes us aware of the areas we need to improve as facilitator or participant.

  1. Clear, meaningful agenda. A great meeting starts by having a clear agenda: why did we gather today here? The agenda is meaningful, it is connected with a higher purpose and ideally with the overall strategy of the company, long term goals. The agenda is specified before the meeting so that the right expectations are set and members join prepared. Also, it is important to mention the expected outcomes: decision needed, feedback provided, free discussion with conclusions, brainstorming with top 3 ideas voted.
  2. The right people at the table. A great meeting has participants with different areas of expertise and perspectives, able to share ideas in a constructive way. The number of participants is not too high (“let’s invite everyone”), nor too low which requires yet another meeting to involve other stakeholders. According with Agile principles,  the best size of the audience is 6+/-3.3.
  3. The flow of the discussions is well facilitated.  During great meetings, participants share openly their point of view in a respectful manner, there is a constructive conflict of ideas leading to superior insights without damaging the relations between members, disagreements are encouraged and treated with curiosity, fully appreciated as opportunities to challenge approaches to the common goal. Discussions do not extend to off-topics arguments for prolonged periods of time. Everyone is involved, all opinions are heard and considered.
  4. Participants come prepared. Meetings do need some preparation: an idea is presented to receive feedback on it, working software demonstrated to reveal progress, or certain thinking tools are used to engage everyone. Quite often the main preparation is done by the facilitator, still, in great meetings different participants have already assigned themselves different topics on which they come well prepared.
  5. The right time. Yes, this is a difficult one. The time at which the meeting is scheduled affects the productivity of the meeting. Also, the day of the week and even the period of the year. Great meetings rarely  happen on Mondays mornings, at 8:00 am or on Fridays late in the evenings, not to mention 24th December or other public holidays. When working in international teams, the timezone difference creates a new challenge. A good strategy to approach it is to "share the pain": not perfect time for them, not perfect time for us, but OK for everyone.
  6. The right duration. Many  meetings sacrifice effectiveness for efficiency: many topics are put in that it becomes almost impossible to respect the schedule, not to mention having some breaks. Agile is proposing timeboxed meetings, meaning having a maximum duration, the meeting can be shorter but not longer. Being successful on it requires a whole new set of skills to be learned. Daily Scrums are the best ways to practice!  It becomes obvious the need to filter out the topics that do not require all the participants, to be concise and prepared etc.
  7. The location/The virtual communication environment. A great meeting usually happens in an appropriate space, having the needed facilities as a white board, working projector, good natural light, isolated from disturbing noises, good internet connection, coffee closely available etc. Sometimes, great meetings happen in spaces that are not common: like in the next cafeteria, in a conferences space or offsite. The unusual setting emphasizes in a subtle way the importance of the discussion and increases participants’ engagement. When it comes to online meetings, a short test of the communication tool and internet connection is needed before the meeting and clear demands for appropriate microphone/headsets and camera.
  8. The 3Es: Energy Engagement Enthusiasm of the participants. Great meetings have inspiring topics which stir enthusiasm and also bring novelty. Everyone feels involved, listened, appreciated, contributing to build something greater than one can build alone. That is why, there is a great positive energy in the room, which can be felt even afterwards.
  9. Fun. Great meetings have a spice of fun. Sometimes it is simply the character of the participants who can easily combine serious arguments with small jokes, it can be different amusing pictures that were prepared in advance or laughing together on silly mistakes.  No need to shy away from preparing the fun part: I recall a great trainer who kept us an intensive training for 3 days. He had prepared a funny short movie for us to watch every two hours. It worked, we all survived 24 hours of PowerPoints with a smile on our faces!
  10. The achieved results. Great meetings end with a big feeling of accomplishment. The results are superior of what any individual member could have done alone, it is fully agreed, it is something to be proud of.

Next time you attend a boring meeting, please empower yourself to break the cycle of similar meetings by proposing at the end a 5 minutes Retrospective on the meeting itself. Ask all participants to anonymously evaluate the meeting on these 10 criteria. Take the one with the smallest score and brainstorm for one improvement for your next meeting. A team member will volunteer to make that happen. We don’t have to tolerate bad meetings forever, we can transform them to what their purpose is: amazing opportunities for achievement, growth and joy through collaboration. Such improvements in our work life will keeps us going on the long run, full of enthusiasm saying “I love my job”, “I love my colleagues” or “I love Agile”.

If you are a constant learner interested in leadership skills, don’t miss out my free short videos on how to gain your team's respect and get your team winning. Now I am asking you: what are the biggest challenges you encounter in your daily Agile practice? Please let me know here.  Your answer is highly appreciated!

Do I need to know programming as an Agile Tester?

Photo by    Emily Morter    on    Unsplash

Photo by Emily Morter on Unsplash

Yesterday I was writing the blog Why team responsibility and common goal? Concrete example for tech and non-tech people in which I was making the point that the service to those who will use what you are creating becomes more important than doing what you are good at or doing what you enjoy the most, when I received this question from one of my LinkedIn connections. It is a great question! QA/Agile Testing is not exactly my deepest expertise area, but I will do what I preach and try to give you the best answer I can, as an Agile team member, Scrum Master and Agile Technology Manager, still inviting the other community members to provide their view.


Agile community point of view: This is a topic that creates a lot of debate in the Agile community. During an Agile Testing/QA conference, half of the participants considered that technical expertise is needed, half did not. The argument of not being technical is related to the power of Black-box testing which is a software testing method in which the tests are done without knowing the internal implementation of the item. This it very powerful, because it is indeed focused on testing from the user point of view, without knowing any constraints of the code base (because, hey, the user does not know nor care about the code base constraints). In my experience, this brings a huge value and has the power to uncover many errors that usually developers who know so well the code base cannot find. This is different from White Box testing and then the question could be should QA/Tester do the White-box testing also? Is Black-Box testing even possible anymore after you get to know the code details? Agile promotes T skilled profiles, but where is the boundary of general knowledge and specialization, hard to tell.


Team point of view: One good reason why there is no black or white answer is that so much depends of the context of the team and the project, and this tends to change in time. A team that did not have any systematic manual testing before, will probably need the Tester to focus on that full capacity. You could call it that the manual testing quality debt needs to be paid. In time, the more automated testing is added according to Agile principles and if the quality of the code is actively evolved, some Testers do see an increase of their spare time. Maybe a team who had a tester for 3 years can have a lower demand on Black-box manual testing and then, there is a spare capacity that the Tester can use to achieve the common goal of the Sprint. In order to do that, s/he may need some technical skills.

Organization point of view: Here it is always a matter of how you can bring the most value to your customer and the way you can contribute the most in your company for that. Supposing there is some spare time in your schedule inside your team, but the company lacks overall testing expertise, then the support needed from other teams has to be considered. Maybe your team is doing great on the testing side, how about the other teams? Sharing practices during a Testing Community of Practice and collaborating with other Testers to create a company systematic testing (especially when multiple teams work on the same product), are topics that need to be discussed with your Technology Manager. Then, it becomes a matter of priorities.  

Personal point of view: OK, there is so much “it depends” that it might confuse you even more. If I were in your shoes, I would take advantage of any opportunity to grow my skills. If the team/manager etc. thinks I should learn something more, I would go for it. If the team has a strong opinion on that topic, then it means that they are willing to support by peer coding or even other knowledge sharing sessions. If the manager considers that new skills are needed, then probably your will receive some support as training budget, time for self-learning etc. It is very possible that the manager who has the overview of all the teams to say it clear and loud that s/he prefers that you invest your learning efforts in deepening your Testing expertise, because the lack of deep expertise at company level is high.

If no one around you considers that this is valuable, me, I would still learn in my spare time as an investment in my future, a small experiment and out of curiosity. You can ask your team where to start to have already some short term contributions. One hour per week takes you far in one year. You see, overall, I think that on the long term it is better to have the ability to get involved in technical topics and then be flexible on when to use it. This way you create the opportunity to have a personal opinion on this topic based on your first-hand experience. 

I hope it helps. As I said in the beginning, I invite other Agile community colleagues to comment on this! Thank you for sharing your point of view!  I made 3 videos (shorter than 10 minutes) on how to "Win your team's respect", great for Scrum Masters. I received the feedback that any member of the Agile team would benefit from these advises, so check them out!

Why team responsibility and common goal? Concrete example for tech and non-tech people.

                                        Photo by    rawpixel    on    Unsplash

                                        Photo by rawpixel on Unsplash

Let’s take the following scenario: I am an entrepreneur who decided to have its own website. I found out that having it done by a freelancer will take him 3 months. So,  I decided to give it to few experts: one guy is great at all the server things, there is this lady great at making things look cool, I have a security expert for all the online payments and a content guy, who is better than me at explaining my business in words. Each one them tells me that they can complete my requirements  in 1 month, so I will have everything ready in 30 days. That’s great, exactly within my budget!

They start working on the assignment and after 1 week I have a call with them  to check the progress. Everyone did a great job: I see some nice logos and pictures, the security part works – payments with PayPal can be made, some content in Word is ready etc. I am happy with it! Second week, even more progress, I know exactly what everyone did. During the next week, something starts to bother me, but I don’t know what. I meet a friend who is eager to see how my website looks like so far, but I have nothing to show him, except some great pictures, some Word content and some payments he can make. On the third week, I raise this topic with the experts and their answer is that no one is good at creating a great landing page, nor the navigation part. Menus and not their thing. Plus, I made a contract with them to do what they are good at. They thought that was clear. They suggest that I contact a specialist in this area.

 For me, that is out of the question. My budget does not allow it to me, nor do I have time to search and make a contract with such a person now. I also realize that, even if the content is a state of art in Word, is completely useless for me until it is on my website. Same with the pictures and the payment part. After one month, everyone has completed their part, what they committed to, they declare success of the projects. They don’t understand my frustration that I don’t really have a functional website!

Specialization makes sense: one cannot do everything, so s/he needs to choose an area of expertise and get better at that. Not a bad idea in general. Clear personal responsibility and accountability, everyone works on what s/he is good at, what probably they enjoy the most, you know exactly who is not doing her/his part. And yes, sometimes you do need to contact that specialist. Still, when it comes to accomplishing something bigger than what one person can do alone, it usually leads to this: everyone is successful on his part, but the overall result is a huge failure.  This is not a surprise considering that our education system encouraged success on individual tasks, collaboration was not favored and in many times, was even penalized.

In order to avoid that, a mindset shift is needed.  The goal is not that everyone does well their part, the goal is that the overall result is a success. In my example, having a functional website. Even though expertise is hugely important (more in this blog), the goal is not to use the expertise, but to create the  most value for the users. And here is where common goal and team responsibility comes to play because it is almost impossible nowadays to anticipate the skills needed for accomplishing an end result that was not done before (as it is always the case in software development). Some anticipation of key skills is made and people are gathered on those skills. Still, their goal is not “to do what they are the best at”, but to do whatever it takes to accomplish common success. Because yes, it is possible to be super smart, hard working and very good at what you do, and still deliver a big disappointment for the user.

This requires a new mindset: for management, to delegate the responsibility to the team, instead to a single person and for team members to embrace flexibility, willingness to step outside the comfort zone, to do tasks outside the established expertise, even outside of what we like doing the most, desire to learn new things, a good foundation of general knowledge, eagerness to work closely with other people and to be evaluated according to the team’s result and a deep attitude of service. Service to those who will use what you are creating which becomes more important than doing what you are good at or doing what you enjoy the most.

Note: If this mindset shift is an interesting topic for you, feel free to  subscribe to my free webinar Scrum Master secrets on how to create success stories or enjoy the 3 videos on how to gain your team's respect and get your team winning.

Who are the leaders in Agile teams and WHY?

1449545907603.jpg

When I asked different Agile practitioners “who are the leaders in Agile teams and why?” I received very different answers:

  • someone considers that there are no leaders in the team

  • someone answered that the Product Owner is the leader of the team

  • someone thinks it is the most senior software developer of the team

  • someone answers that the Scrum Master is the Servant Leader of the team

  • someone admits that he does not know at all

  • someone tells me that the lead role is split between 2 guys, the most senior developers and that works well

  • someone says that the person who has the most experience in one domain, because s/he knows more and that is why other people listen

  • someone says that the most active person, the one who likes to tackle the problems directly

  • someone says that it depends on the task, the person who knows the most on that particular task  and that usually the people with more experience have more knowledge

  • someone says that there are no clear leaders, but people with different expertise

  • someone says that not leaders, but the most powerful opinions and influence in the decision making are the senior developers

  • someone says that the team should work together without thinking who is the leader

  • someone says that each person should act as a small leader in different areas

Wow! The leadership model in Agile is complex, for sure.

In my opinion, Agile teams are not leaderless, but the leadership model is a “shared” type of leadership. It means that there is no single absolute leader and that decision making is distributed inside the team. The leadership is based mostly on expertise (the Product Owner is the expert on what the customer needs, different developers have different areas of expertise and therefore share the technical leadership, the tester is the team’s expert on testing etc.). Expertise tends to accumulate with experience, still they are not the same.

In addition, Agile introduces a leadership based on volunteering. That is why, for each task, someone volunteers to be assigned as the “leader” of the task and this encourages people to step in to do things outside their area of expertise. That increases greatly the performance of the team in case a team member becomes a bottleneck for a short time. Let’s say that the team notices that during for a Sprint there is a higher testing effort that the tester can handle. Obviously, another person of the team needs to step in and volunteer to do some testing. The tester of the team will clearly guide that person, but s/he is now the main driver of that task.

Also, Agile emphasizes a collective ownership. It means that even if there is a leader on a certain area, the entire team is responsible of the end result. This is very important because it gives to each team member the right to question, understand and express opinions on everything in the team’s responsibility.

So, I agree that in Agile teams everyone is a leader on certain areas, it changes on different tasks and it is based mostly on expertise or volunteering. Still, at the end of the day, the entire team remains responsible for the overall result.

Note: I shared 3 videos on how to gain your team's respect and get your team winning. I will keep a webinar to share some Scrum Master secrets on how to create success stories. Subscribe with your email address, it is free for everyone willing to improve their people skills, highly recommended to passionate Scrum Masters.

Scrum Master, the boss of the team?

Photo by Olga Guryanova on Unsplash

Photo by Olga Guryanova on Unsplash

“I am not their boss. They won’t listen to me”. In my first days as Scrum Master I had a dilemma I did not dare to ask: if the Scrum Master is supposed to promote and support Scrum adoption, why isn’t s/he named the manager of the team? Then, being a manager and coach, many Scrum Masters asked me the same question. In fact, many companies give Scrum Masters this formal power. Then, why is it not crystal clear in the Scrum Guide that the Scrum Master is the manager/boss of the team? I spent nights thinking about it. The truth is that for the first time in the organizational history, some people are supposed to initiate change without a clear and formal authority. Oh! Here is the key word: authority. What is authority? Well, I will use it here as that type of power coming from the fact that someone can decide when you are in and when you are out of a company.  In 99% of the daily activities in a company this does not matter, but in those 1% when a firing decision is made, it has a huge impact on the life of a person and of the people around. People remember who has that power and who does not.

So then, the question comes back: why don’t Scrum Masters receive this type of authority? After researching this for quite some years, I realized that the Scrum Master role is at its core a change/transformational role, a role high on influence. The psychological mechanisms to respond to influence are compliance (in the case of authority use), identification and internalization. If the Scrum Master would have authority, that would result in many cases in compliance: people do what they are asked to do because they have to in order to avoid negative consequences that they are not ready to endure (like being fired). We have all been there. It is influence by fear. It is fast, it works, it is reliable. Still, it has a big problem (gladly!): it is easily reverted. We do what others want us to do despite our own will just as long as they have the punishing power over  us. Afterwards, we go back to doing things the way we want to, because, hey!  we are adults and free human beings.

I think that explains why Scrum Masters are not the managers of the team, at least not in the beginning of the Agile transformation. Anyways, I have seen this type of authority assigned to different other roles: the Product Owner, the Technical Lead, a human system manager etc.  In my experience, the most successful are the human system managers, applying Management 3.0 practices. And also, I noticed that the Scrum Masters are usually the most successful in becoming Managers 3.0. Being a Scrum Master is a great opportunity to lead without authority, to understand the misuse of power and build a light type of leadership that leaves enough space and air for the others to evolve their expertise. Therefore, to all the Scrum Masters asking this question: the lack of authority gives the chance to influence without power and fear. It is hard, it is a journey, it is an art. It is an amazing opportunity to grow within the leadership of the future, because the era of fear in companies is going down!

If you like my style, don't miss my tips on how to "Win your team's respect" 3 videos!