How to guide a team to be self-organizing?

Question

I can see that a Scrum Master has two important role out of many; namely building a self-organised Team and removing impediments.

Apart from teaching, mentoring and coaching, what else does one need to do to make a self-organised Team?

Answer 1

The question is general to management roles and speaks about "building people up".

Just Googling these 3 words lands countless views and advice — please avoid theoretical and commercial docs, focus on real-world blogs and talks by real people speaking in their own name or their company's (i.e. take advice from those who've already succeeded at what you seek). Or read actual books (a few links in this post).

I'd like to quickly brief, then frame for the SE domain. (Disclaiming, this is my personal/anecdotal exp., so take it with salt, sugar, pepper too, and maybe some vinegar.)

---

Short Brief

Building people up is sometimes termed the real value of management: the 'benefit' for all parties lasts longer than their involvement (you come back home with it; while the company keeps it too, as culture). It's also contagious by nature (someone 'built up' tends to build up others quite naturally).

You need to:

• Remove limiting thoughts towards a "growth mindset", as Carol S. Dweck puts it (of all theories, I can confirm this one is true; reading this book literally changes lives). Basically the idea that success/failure is the result of work, effort, actions, and certainly not a judgement on ourselves: you wrote bad code today, doesn't mean you're a bad programmer, just that you botched that task and need to put more effort on this one.

• Lead by example. Period. It's just the only sustainable form of leadership: you eat your own (manager)dog food. Your own advice, you don't preach it, you don't even voice it much, you simply do / apply it yourself, for yourself but for all to see, and let others observe and, if your ways are good, slowly convince themselves that they should imitate you.

• Use only positive reinforcement (rewards) as feedback. Generally, everything else is moot or counterproductive (notably punishment, shaming, etc.), a necessary evil, last-resort can't-avoid-it kinda situation. Make your positive reinforcement "fair": praise always when it's "not bad" (positive even just above neutral), but moderate the intensity accordingly. The key concept is that others feel "recognized", "acknowledged" for their efforts (it's not about making them feeling like the best always, but more intimately feeling that they are seen, that they exist in the team. Like, "I know. I know that you show up and you really try. This has value for both of us, I see that." can't be said only once or in not-so-clear words).

• As you've guessed by now, it's an empathic process much more than a technical task.

About the growth mindset: it's the one thing you wish to focus on, if you win this you win life, period. (grains of salt and everything)

Its beauty is to nurture a genuine appreciation — all the way up to love — for work and effort because these solve our problems. It's always very positive but never undeserved or entitled or random: we stick to the dumb facts and go from there each step of the way. But ultimately, step by step, you can really get there, wherever "there" is.

One take away is that you become able to "love what you do" (whatever you do) and not feel restricted to "(only) do what you love" (because that's unreal and out of your control anyway).

Most importantly, you cease to think or say things like "I am" (I am a good/bad programmer, I am a good/bad communicator) and become more factual, more "in the now" (I did a good/bad job on this programming task, I did or did not communicate my problems well). Hence, there's always room for improvement, next time.

---

Building people up in Software Engineering

You'll face the 3 demons:

1. Imposter syndrome or related lack of self-confidence.

   This freezes initiative, offers to help, communication. It's worse for the team than the individual itself. A team that behaves as a whole like an imposter has lost before they even begin.

   That's the toughest part, because spoiler: you can't change people. This is why we "hire a person, not a profile": you can always train someone to meet a job profile but you can't change a person unless they want to.

   Honestly, my best shot at it is to have people read the book "Mindset" by Carol Dweck. That's what cured me of imposter syndrome and I think it works for many, maybe most people.

2. Silence. Lack of communication. Silos, sub-groups, divisions.

   There is a great book on organizations called "Tribal Leadership" by Dave Logan, John King & Halee Fischer-Wright. I think it's a tremendous read for anyone looking to manage any kind and size of team(s).

   In SE it's even worse than other fields for more or less obvious reasons. Be flexible with meetings but have at least 1 full team meeting per week (no longer than it should, show respect for people's time); one-on-one's also need to happen regularly and cannot be substituted. The spirit should always be that of transparency, and people be made certain that revealing their mistakes will not ever turn on them: you use everyone's mistakes as stepping stones to build the team, the culture.

   How? Well here's a typical situation:

   • Someone makes a mistake and some bug makes it to final build (in the hands of your "customer", whoever eats your code next).
   • First of all, you thank that person for making the mistake and sharing it (everyone makes mistakes, human beings, if it were not that person it would have been someone else eventually, and that includes you: emphasize that publicly).
   • Then you work with the whole team to find out how we can prevent such a mistake leading to this outcome, how can we intercept or avoid the mistake in the first place (that's the real problem to solve here).
   • First, let them shoot ideas, don't interrupt or judge anything right away (have everyone do the same, fire ideas, no response/judgement yet).
   • Only then, when ideas get dry, review propositions and select/mix the best (maybe we both can lint it out and write/improve a test unit).
   • Positive feedback (good job everyone! have a cookie) then move on.

   What you just did in this example is:

   • Reassure someone, make them feel safe that their mistake isn't reflecting bad on them, rather the team takes it as "we've shipped something buggy". So that someone feels free to speak, and you've eased everyone else's concerns too because they've just seen it happen. "Oh, we can make mistakes and admit them here, it's visibly OK".
   • Allow a mistake to be revealed and thus identify a weak point in your process. That's how we solve problems, as opposed to burying our heads in the sand.
   • Take this opportunity (problem) to engage in teamwork. Note that the non-judgemental "free ideas" first step is critical to quality.
   • Effectively solved forever this particular mistake, it won't ever make it to final again. The team really can thank that person, because now we're better for it: beyond 'resilience' (means recovering to your initial state after a hit), you become "antifragile" as Nassem Nicholas Taleb words it (problems make you grow, you become stronger the more difficulty you face, building a culture able to tackle ever-bigger problems).
   • Reinforced that this is the way to go.

   Note that it's long to write and properly explain, in real life such informal talks about mistake X can happen in all of 2-10 minutes. This approach is directly inspired from accidentology, the study of the causes of accidents, and subsequent elaboration of methods and processes to ensure safety e.g. in air transportation or medical care).

   Other good tools are:

   • pair programming (senior with junior makes for fast progress for the latter; more on-par duos are good to trounce through work like star players). Let people associate freely, also do some matchmaking if you feel like it.
   • pair peer review (people review each other's code in pairs, sometimes the same functional bit, just to compare and bounce ideas on problems)
   • one-on-ones with your guys, take 5 (minutes!) every day or so. Your invaluable vantage position lets you guide them with relevance, because you know where others are at. Always come off as "hey how's it going, what can I do for you", offer this space where others feel safe. Here's a great book if you want to train your interpersonal skills: "Crucial Conversations" by Kerry Patterson, Joseph Grenny, Ron McMillan, Al Switzler.

   Basically anything in groups of 2-3 is great to reinforce communication. Lone wolves usually have their own way of dealing with it; don't force anyone, just be open and transparent about what you expect — like it's OK to pretty much reveal the whole "from making individual mistakes to growing stronger as a team" process, be totally transparent how that works, people can then own it and use it in whatever they do with whomever (like your pair progs hehe). [It's also great for educating children]

3. Lack of trust.

   Now that's my way. It builds up on everything above and then some, of course. But basically in practice, day-to-day, it comes to this:

   • Begin with your customer, see them, who's the direct customer of your team? (probably some other team who takes your work and goes from there). Now make it clear we work to satisfy these people, our customer, whoever eats the food we cook. Forget about the 'end' customer as a team manager, let the higher-ups do the global cohesion (it's their job), focus on your team, these are your guys.
   • Your guys, your crew, your partners-in-crime, your merry gang of nerds or whatever. This isn't about being friends (that part is out of your control), it's about feeling for each other in very professional/technical ways: acknowledge and ease the pain points, train the weaknesses and strengths, share interest in getting something out of it, etc. See how it builds on 1. and 2. above.

   • Be a servant leader of a servant team. Not 'boss' (petty) but 'How can I help you?' 'How can I facilitate whatever it is you have to do?' 'Can you help me help you rise higher or easier?' That's your job.
     Then, only then will people talk to you: when they feel you're with them. Goes true against your hierarchy: you protect your guys, you don't throw blame at them, you suck it up and own the team's successes and failures all the same.

     Because remember, even if someone's subpar and made more mistakes and eventually needs to go, it was the team's failure all along that we shipped buggy. Your team must trust you speak as one, and take the hits. Your best guy too needs to feel free to speak and admit their mistakes, especially your best, so it's not "oh it's OK now but I'll throw you under the HR bus next time though": it's OK forever or never).

     And because you serve them, they'll reciprocate by serving you too and work to avoid more 'hits', to ship 'better', to succeed. Not for you, dear master, but with you, as one. Then can you claim 'mastery' at orchestration, organization. ;-)

   The take away is that you want to break these damn walls that people — legitimately — erect around themselves to allow 'trust' to 'flow'. Like a river. Trust is a flow, it doesn't really stop, only grows or shrinks in time. Trust never burns, it heals: people want to trust but are afraid to, and by showing them real tangible examples of situations where they could trust you and each other, fear will subside.

   Also, you hear stuff like "trust is earned, not given". It's a bit vague, forget about such pop-philo. Trust, according to psy studies, is built by sharing circumstances, i.e. being in the same boat enough with someone (implying they're on your side, did not turn on you). So don't fret it. It'll come, it's one of these genuine things of the heart than no 'system' can hurry. But you can see how it all contributes (the team meetings, the openness in a "safe zone" kind of setting, the pairs, the one-ness of you taking the shots outside this 'sanctuary')...

---

There's this book whose title says it all I think: "Sometimes We Win, Sometimes We Fail Learn". If you can make someone genuinely agree to that, you'll do great at managing teams in Agile environments (the fundamental premise of Agile and streamlining such as DevOps is to take "a little hit on initial quality" to "massively increase total throughput"; so you really need at least resilient and at best anti-fragile mindsets, and systems, to work under such paradigms. Basically, get ready to make mistakes and fix stuff).

I get that's a lot to take in, honestly that's more like a plan for the next 5 years, you'll probably change jobs twice or more on the way to mastering these things. Which is why I included down-to-earth examples, simple things to do. Compound effect: you do a little here, a little there, but every single day, and it builds up to mountains in time.

Notice I didn't use much words like "self-organizing" and "initiative". That's because you can't really "require" or "suggest" these things — merely show by example but then again, it's part of a larger frame. You rather elicit, or nurture, such behaviors by

• removing barriers (like allowing mistakes and even making it valuable to reveal them, building trust, etc)
• facilitating, helping (you seem on point with this, coaching etc)
• making it clear the collective and individual rewards are on the other side of "us" doing great, thus each and everyone being a team player to help, facilitate other's jobs — at which point, they imitate you, they becomes masters, you've elevated them or rather enabled them to evelate themselves, from within.

Once you get it, you can't really do "wrong" as a team lead but only learn/grow: making mistakes is also something you can do, and if you just reveal and fix them asap, as you go, and as a team too (maybe with your guys, maybe with your hierarchy too), you'll earn this even-higher level of trust called "respect" — for being fair as a leader who self-judges themselves, and behaves, according to the very standards they seek to promote onto others.

Answer 2

Scrum Master

The Scrum Master is one of three roles defined within the Scrum methodology. As part of the Scrum Team and acting as a servant leader, its primary responsibility is to help the team follow the Scrum process.

Unlike a project manager in a waterfall approach, Scrum Master is not responsible for planning, it is done by the product owner and the team. Nor does it manage the team members, nor is it responsible for product quality, this is done by the team.

As you said and right, Scrum Master is responsible for ensuring that the team follows the process as well as being a facilitator who removes obstacles from the team. These responsibilities translate into:

• Facilitate daily Scrum
• Help the team maintain the burndown chart
• Organize planning sessions, sprint reviews and retrospectives
• Protect team from disruption during sprint
• Remove obstacles that may harm the team
• Encourage Development Team - Product Owner collaboration

The necessary dedication to the project

Some projects require a 100% dedicated Scrum Master. In other projects, he / she accumulates his / her role as team member. At first, this job tends to be full-time. However, after a few sprints the processes will tend to systematize. That way the workload will drop and he / she can actively contribute to Sprint Goal.

Answer 3

In all my work as a Scrum Master and Agile Coach the one thing that always always impedes teams from becoming self-organising is meddling third parties:

e.g. 1: a manager that wants to micro-manage individuals on the team - this totally blocks any self-organisation happening e.g. engineering manager, architect

e.g. 2: a command and control product owner that assigns work to team members and wants to control how the solution is engineered - self-organisation will be very slow if not impossible with this situation

What I would recommend is that you build strong relationships with all the people outside the team who are very close to the team and then start coaching them on how it is important that they don't meddle with the team.

e.g. 3: a command and control or micro-managing team leader or technical lead within the team - this is more of an internal role, but still has the same effect.

Answer 4

It should be continuous coaching process for the team, to transition and grow Product Mindset in all members of the team. Development team should share ownership of product and understand what is the most important for business at the moment and why. During Sprint planning it is a good idea just to setup the high level goal(what has to be achieved and why) and let the team to drive process of breaking tasks and defining what and how will be built. Ideally to define ownership during this event.