How to wake up a team?

Question

I am a Scrum Master and work with a team of 7 developers + PO (also programmer). They are experienced and many of them have been work in this place for couple of years. It is a big company in a transition to SCRUM and I am their first SM (since 2 months). They are also productive, easy to work with, eager to learn and not picky about their tasks (the product is not very exciting). The thing is the "sleepy" atmosphere especially during the meetings. Only the PO is active - he speaks for 90% of time. When I asked him not to speak first (he is willing to change this state) there was silence and it was really hard to end our meetings with any conclusions. The guys are simply fine with everything. How do I wake them up? Or do I let them sleep and take only little actions in search for improvements? I am also working with another team in the same company and the latter is boiling with emotions! How do you think?

Answer 1

There are some clues in your question, which might explain why this is the case, but I will only mention them at the end of my answer, because I would say the most powerful tool at your disposal could be the Sprint Retrospective.

I assume if you're doing Scrum, then there is a Sprint Retrospective at the end of every sprint. If not, start doing them straight away. It's a mandatory part of Scrum. Set a timebox for the Sprint Retrospective. The Scrum Guide says this event should be timeboxed at a maximum of 3 hours (and usually less for Sprints of less than a month). In the first instance, consider allowing the maximum amount of time, with the understanding that it can finish much sooner once it has achieved its intended results. Read the Scrum Guide for more information on that event.

Research techniques on creating a safe environment in the retrospective. i.e. one where every member feels they can express their opinion, without fear of reprisals. At least in the first instance, explain to the entire team how you will treat the retrospective, and how you expect them to treat it. This could be establishing principles of there being "no right or wrong answers", and it being about "improving the environment, rather than apportioning blame"; ask members to be respectful of each other, and give them the chance to ask questions, before proceeding. Whilst it is good that teams can be transparent, if necessary, ask everyone if they will agree to keep the discussions of this particular meeting between just the Scrum Team. And of course, be honest about why you are running the retrospective in this way, whilst using language and terms that are respectful of all members of the team. All members of the Scrum Team (Development Team + Scrum Master + Product Owner) should be present and participate. No-one outside of the team should be present, and the meeting should be held where people are confident of not being overheard.

One method of Sprint Retrospective is to ask everyone to write down post-it notes about how they experienced the Sprint that is about to end (the post-its could reference an ongoing issue, or one that only affected them in that Sprint). Try to get the team to write at least one post-it of something good, one of something bad, and one of something interesting. Allow each team member to write their own post-its before allowing any discussion about the Sprint. This means everyone should have at least three (preferably more) opinions written down. Ask them to take turns to share one of their post-its (even if someone else already said the same thing). Ensure there is time to discuss the post-its, so that everyone's opinion is heard. Allow disagreements to take place, and only intervene to remind team members about the importance of making progress (i.e. keeping within the timebox), and the importance of being respectful of each other.

Subsequently, the team can work together to come up with solutions (perhaps out loud, perhaps initially with post-its) for the issues they've raised.

If this doesn't deliver instant results, consider trying it for 1 or 2 more Sprints. If it still doesn't deliver a change, or at least help you identify problems, consider other techniques to encourage team members to share their feelings. Perhaps an anonymous box for team members to drop in notes about things they want to raise, but don't want to mention in a retrospective. I would consider this option less desirable, because it discourages open discussion; but it might just be necessary.

Also, make it clear to the entire Scrum Team (and anyone outside the team) that you are someone they can go to in confidence about their ideas/feelings/comments (including criticism of you). Consider organising one-to-one private discussions with each team member if necessary.

---

So, the clues I've taken from your question:

PO is a programmer. Maybe this is the issue. It's not explicitly forbidden by Scrum, but it's not common, and represents some significant conflicts of interest that would need to be identified and managed carefully. I would be surprised if a PO can offer more to a team of that size as a programmer than as full-time PO. The Development Team is responsible for estimates and quality, and forecasting how much work they can deliver. The PO is responsible for optimizing value. The Development Team estimates Product Backlog items, and the PO should use those estimates to prioritize the backlog (along with other considerations, such as other feedback from Development Team about risks/dependencies/etc, and stakeholder concerns). Consider working with the Scrum Team and organization to get a full-time PO (either the current one, or a new person), and observe how things change. Change may not be immediate and if the PO ceases the role within the Development Team, ensure they don't attend the Daily Scrum (unless invited by the Development Team), and don't interfere with estimates, code, definition of "Done", and other domains that are the responsibility of the Development Team.

Organization is new to Scrum. Perhaps there's a culture (either current or recent) of "industrial thinking", not treating people with respect, not allowing Development Teams to self-organize, using Scrum in name only, and not buying in to the concept.

Not picky about tasks. Even if a product is not inherently interesting, it's alarming that teams don't seem to express an opinion on which to do first. Do they understand the value of what they're doing? Is the PO being a proper PO and understanding the most valuable items in the Product Backlog and communicating that information to the Development Team. Is the opinion of the Development Team heard/respected (not the same as being agreed with) when they do give an opinion? Does the Scrum Team hold a proper Sprint Review (Note: I deliberately didn't call it a demo), where the Development Team and Product Owner engage with stakeholders, so that everyone can understand why the Product Backlog is prioritized the way it is, and so the Development Team can understand what is important to the rest of the organization (and why).

Terms like "sleepy" / "wake up". Is this your assessment, or a commonly expressed opinion within the team/organization? Either way, if the Development Team is aware of this perception. That kind of language might be interpreted as disrespectful, and may be demotivating and erode trust.

Your assessment that the other team is boiling with emotions. Again are the Development Team(s) aware of this perception? The realization of how they're viewed may affect how they behave. How were the teams formed? Who decided who should be in each team, and why? Perhaps the personalities don't match. Is there opportunity to rearrange the teams? Perhaps combine the two teams together, perhaps create smaller teams, or just shuffle members (once, not regularly) between the "sleepy" and "boiling" teams. Whatever is done with teams, ensure the members of the Development Team know what the priorities of the business are, and trust them to self-organize into new teams of their own preferred structure. This might have a negative effect in the short-term, but perhaps it enables them to work more effectively in the future.

Answer 2

It sounds like the team is expecting the product owner to feed them ready-to-work tasks. It may be that the PO's technical background is actually a hindrance in this case. It is important to remember that the PO should be providing clarity on which feature needs are most important to provide and which problems are the most important to solve. The team decides how to implement those features or how to solve the problems. If this distinction is not there the team can get demotivated quickly.

Answer 3

One of the best things I was taught as a project manager is that no two team members are the same. We can't treat them all as one and expect them to come out of their shells. To each their own, and as a PM it's our challenge to learn about them and find what makes them tick.

Marc has made a comment about "introverts", and most teams have one, but when the entire team is feeling lethargic and uninvolved then that's something different. At the very least it doesn't hurt to switch things up a bit to make the workplace more exciting, but I'd say there's a lot to benefit from by doing what you're doing. I think it's great that you're paying attention to their signals and making an effort!

• If I was in a similar position, I'd start learning more about them as individuals to see what really excites them. Getting out as a team together is a great way to break the ice (not the silly Team Building exercises, but something relaxed and not to do with work), and doing some personal presentations about themselves (or Q/A) gets your team members to learn about each other. This more often than not brings surprises when one learns something interesting about another, like a similar hobby, or something interesting like building space rockets in their spare time = more to talk about and more in common
• It sounds like they're a great team who is adding a lot of benefit to your company. If this is the case, use this to buy them some "hack" time (half a day on Fridays, or a full day a month). Time where they get to try something new, new programming languages, solving new problems, something totally out of the ordinary. This, while is a bit expensive, often adds benefit to the organisation too, so it's not a big loss
• Get them to start peer programming with each other, or learning new functions that they're interested in

These are just a few ideas; I'm sure there's lots out there. It sounds like they're a great team, and them being a bit quiet is a good problem to have compared to most of what we hear about.

Good luck and feed back with what you tried/did!

Answer 4

The tools and solutions and time needed depend very much on what really is going on underneath the surface.

To create an overview, to see the differences and see better which tool to use for what situation, here a description of three scenarios, from bad to good. My estimate from your description is that "good" is the situation.

Bad (signs: uncomfortable silence, a silence of shock and fear, a silence of indignation and boiling fuming anger just under the surface) + a serious threat has visited the organization some time ago, created havoc, left the building but the behavioral results of the betrayal are still there, trust has been broken. An organization big and small loses the behavior that someone within that organization has punished.

When trust is lost, it's very hard to get it back, if ever. So has speaking up been punished some time before, by someone, anyone, currently or previously or maybe several years ago?

Public humiliation is punishment too, don't expect people to take that lightly, even if it happened a decade ago and the person who did that has been out of office for five years, the issue can still be alive in the minds. It's possible to repair but it will take a lot of time. "trust arrives walking and departs riding".

If someone has done that somewhere in the past, you'll have the unthankful job to do the repairs and can't expect gratefulness in return, these things go deep. This is the kind of damned if you do damned if you don't mess somebody else has left behind.

From your description this is NOT the case, which means you don't need to apply the tools for that kind of situation. This is important, don't use tools for a situation that isn't there. Let's move on to a less dramatic possibility.

Ugly but resolvable ( sign: a bored silence but non-threatening ) + the one talking has been taking up too much space for too long a time and or has a droning voice that induces sleep, so over time people have started to politely shut up around that person, letting the oracle speak as the eyes zone out and the mind wanders away to more interesting pastures.

A sudden change by making (=enforcing) the speaker to wait, creates an instant feeling of threat, a - where is the trap- feeling. The amygdala reacts on changes in patterns, to distinguish the tiger from the grass leaves. This instinct still applies to the streets of a modern city and to an office environment, because when such a sudden change happens, often there is some kind of danger, so people react alerted and reserved. This is natural.

A structural approach is needed and more patience and careful do not inadvertently scare people or make people lose face with an inappropriate choice of words. What these words are is very context dependent. However be very careful with words that associate with any kind of "dumb", people generally don't like being called stupid, "sleepy" is already in the danger zone, even if that would be an accurate description of the situation. Don't ever say that to them into their faces, or let it be known to them via tone of voice or through your body language. People know how to read those and will react strongly to that.

The time needed depends on the exact nature and severity of the issue. If the speaker is well respected by the team, but just has a boring droning nasal voice, then the problem can quickly be fixed. Speak for shorter times or let somebody with a better voice do the talking. If there is more going on, personal issues of any kind, it just will take a bit more time, but it will still be resolvable and the team will be thankful for it.

If this is not the case either, then this is good because it would lead to scenario three:

Good and can be improved (sign: silence but the mood feels o.k. a comfortable silence ) + differences in temperament (for example introvert vs extravert / expressive emotions vs less expressive people) If one team consists of people from Norway and Finland and the other team consists of people from Italy and Mexico, there is a high chance that you'll see differences in body language and tone of voice. In that case there is no real problem, in which the appropriate approach is, don't fix a problem that isn't there, because a lot of damage could be done in the process.

Instead enjoy the positive starting point and aim for further improvements: there are ways make the meeting more dynamic and interesting, without forcing introverts to tap-dance on the marketplace because that's awkward and mean. You don't force extraverts to join a tour of the Italian historical archives searching in silence for ancient scrolls either, because that would be torture for extraverts.

In this situation quick fixes are possible and fun, it's a creative search for what fits best for the team members. If you manage that, the team will be very grateful and remember you positively for it for years to come.

My estimate and my hope is that scenario three is going on, because this can lead to many improvements in a short time with fun along the ride for everyone.

(side note: an example from the world of sports of a less expressive versus a more expressive person you can see in the video of the Fedor Emelianenko versus Brett Rogers 2009 Strike force event, two accomplished athletes,
different ways of facial expression, Fedor looks stoic, Brett very expressive )

Hope this helps and good luck!

Answer 5

There's a lot of untapped knowledge and ideas. Notwithstanding individual personalities, something in your culture is rewarding this specific team to remain quiet. As a facilitator, it's on you to figure out how to tap into this team and harness what it is they have to offer. If your current meeting structure and facilitation methods yield nothing, then change it up. Split the team in half, maybe in quarters, and conduct a different type of work meeting. Maybe even consider breaking the team up and introduce new talent. Introducing even one individual could dramatically change up the dynamic.

If this were me, I would likely disband the team and rebuild it. There's risk to this action in that you may cause some morale drop, performance drop, and some stakeholder grief; however, I opine that, after a bit of time, performance will again increase and, with the changes, you'll harness more intellectual thought and critical thinking that are now dormant. And that win will pay for the immediate costs and risks you will assume with this dramatic change, IMHO.

Answer 6

I was in your exact position, but I was on the "quiet" side of the crowd. Let me explain why with time I preferred to be there.

I started working for a company, which had 4 or 5 years old legacy code. The code had no tests, moreover was written on a singleton-only framework, with static methods being unreasonably overused (which actually made the code untestable). Another thing, the code had different modules, which partly stopped being used with time. I mean, there was a newer module tracking products, but a couple of methods were statically called from the old one. The old developers just decided to leave it there and not rewrite it.

So, the code was awful and it did physically hurt me to work with it.

But when I was interviewing the company (that's right, I'm so skilled, I interview companies, not the other way around, haha!), the CTO told me they want to do heavy refactoring, rewrite the database structure (which was also a "masterpiece of ...") and set up proper staging and CI. So I agreed.

The reality was a bit different. The product manager and the network support leader (I still don't know why in Nine Hells of Baator he was meddling in our affairs) were pushing the CEO and the CTO to develop mainly features and even though they promised to leave at least 20% of time (which is 8 hours a week per developer!), in the end the developers were working with unreadable ugly code, adding more unreadable ugly code, all 100% of the time. Yup, no refactoring, no rewriting, no nothing.

So, what does it have to do with being quiet at meetings? Easy. First, I was active and innovative, trying to improve the state of affairs. But then I realized, that however hard I try to improve the situation in the company, nobody there actually wants any improvements. The people "above" focus on making money, the people beyond (clients, support department, etc.) just want a working application. And your IT department is between the hammer and the anvil: you can't improve things, because it means the development will slow down and everyone will be angry. And you can't develop at the moment, only type in some code and hope it works. And if there're bugs (there're always bugs), everyone's angry again. I am so glad I dropped the company shortly.

My advice to you: look around. If your state of affairs is completely the same, then, if you really wish to change the situation and "wake up" the team, you should go change the perception of development of everyone else in the company. If you succeed, then you will get a very active and trusting team.