The Elastic Leadership Book



        RSS Feed

Latest Entries

First time here?


Ask Royo #1 - Team Leadership and Influence Edition

A new experiment I'm making. Twieet me questions about anything relating to leadership or software dev, and I'll try to answer as best I can if I have any knowledge in the area.

In this episode I answer the following questions:


  • How do you show the benefits of test first vs. test last?
  • When jobseeking, how do I look for places that are in chaos or survival mode?
  • How big should your team be before you need a team lead?
  • Examples of Team "Homework"
  • How to encourage devs to write unit tests
  • The role of designers and architects in agile. is tdd irrelevant?
  • Code reviews with remote teams





A Value System for Code Reviews, and How to Scale Them for a Large Project

One of my customers wanted my help is increasing their code quality.
When I spoke with the developers the following conversation happened several times:

Me: "Wow, this code... how many lines long is this method?"
Dev: "about 700. Yeah I know"
Me: "Have you tried to refactor some of it?"
Dev: "oh.. noooo."
Me: "What if we just extract this small part over here , these couple of lines, to a method with a good name?"
Dev: "Yeah, let's not.  If I do that then I have to do a code review on that, and that can take 24 hours to 3 days. The architects are so busy.. too much of a big deal. I'd rather focus on what I'm doing"

When I went to the architects I heard from them how overworked they were. They meant well, but 2 architects on 30 devs, with more of their own stuff to do as well.. it just didn't scale.

I went to the chief Architect and told him what I saw. I told him I felt that the way the code review process worked (reviews are done through a tool, and take very long) is actually deterring people from changing the code for the better. He was surprised to hear it. After all, they had instituted mandatory code reviews to increase code quality. So we talked about what we can do.

Here's the plan we setup in place:

We will organize a team meeting of all the architect where we will agree on some basic values of what we want from code reviews. I noted that the following values worked for me:

A code review is successful if:

  • The developer who wrote the code learned something new (even if small)
  • The code ends up being better  (even if slightly, even if it's just one character or a name change)
  • To achieve this, an effective code review has to be in person, not through a tool if possible. if not, then through a non text tool (visual+ audio)
  • It also has to occur quickly , or even immediately when the code is ready for check in
  • It increases the amount of people that can review code, or the amount of code they can review well


We decided to experiment for a couple of months with doing reviews this way:

  • When a developer needs a code review, they can just go to an architect and ask for it in person (not using a tool hopefully).
  • The architect will join the dev and review the code, while talking as much as possible about their thinking process, coaching in the process
  • A THIRD person will join (another dev) the review, sitting near and learning how to review the code.
  • The next time a review is requested, the learning dev (third person) will try and do the review while the architect sits back and sees how it goes, then goes over any missing things with the reviewer 
  • Developers will check in early and often so that code reviews are nice and short (a few minutes hopefully)


In this way we:

  1. Make the reviews more effective since they are in person
  2. Less bureaucratic since they happen very quickly
  3. This also  makes developers less afraid to change code and get feedback on it since it doesn't take a long time
  4. We make more developers able to be code reviewers, thus making the code review process more scalable. Anyone can review anyone's code within a couple of months.

I wrote more about code reviews in the face of horrible code quality here.




Scrum Master 2.0: A Scrum Master is Not

I'm a big fan of the idea that you should grow your team to be self organizing. I also used to hold the idea e that a Scrum master is just another word for "team coach", that should grow their team. I felt that people who say that Scrum masters should guard their teams from outside interference would be doing a disservice to their team, because they hold them back from learning and growing new skills needed. I felt that scrum masters who protect their teams become bottlenecks, and they do. 

But in the past couple of years I've had some interesting discussions with some of the original Scrum Folks (Especially Martin Devos) and what most of them seem to agree on is this: Scrum today, and the Scrum master role as it is taught, is very different, and less effective, than the original intent of the role.

This has been gestating in my head for a few months, but I think that now I see this weird role like this:

A Scrum Master is not:

  • A Team Leader
  • A Tech Leader
  • Permanent
  • A Coach


A Scrum Master should be:

  • A constant role that is temporarily held by a person (weekly or even daily basis) 
  • Fulfilled by all members of the team, in turn, in cycles, so that they learn to deal with outside interference and grow their skills of working within an organization
  • The person that does all the "dirty day to day minutia" that keeps the team from doing their stuff (paperwork, meetings etc)

Notice that the key factors for an effective scrum master are that they are not one fixed person, but a role shared and cycled through by all members of the team. This way you get the following benefits:


  • They are not a bottleneck, since each member of the team should be able to perform this function (or learn in the process of doing)
  • They save the team from unneeded red tape and delays by having one person take all the "heat" for a week, then moving to the next person.


So why is this so different than what many today say?

I'm not sure. I think somehwere the idea of "rotating" got lost and we were left with "fixed role". 

Then, many people, me included, tried to reconcile the notion of a self organizing team with a fixed scrum master (a bottleneck! a bus factor!), and the only way that made sense was if the scrum master was indeed taking the role of a coach or a team leader, growing and pushing the team out of its comfort zones. 

On top of that were all the extra "bonuses" of being in charge of the process and other weird business. I'm really not sure where that stuff came from, but it's really really weird. 

Funnily enough, if you go down the rabbit hole of a leader\coaching SM making themselves unnecessary, you might come in the end to the point of this post: That a Scrum Master will ask their team to do his/her job , weekly in cycles, so that they learn that set of skills.

So, my current way of thinking:

  1. If you are about to decide who will be the team SM, don't choose anyone. make them a all a SM, on a week by week basis. 
  2. If you are a fixed role Scum Master (that is, there is only one person assigned), you do need to become the coach, and get everyone to cycle through your role in dealing with red tape and outside interference.

A Scrum Master 2.0 is really the Scrum Master 0.1 in its most basic form. 


3 Reasons to stop solving other people's problems for them

If you re an expert in some field in your team (the DB guy, the UI gal, the search Guru.. you know), it also means you're a bottleneck, and people have to constantly wait for you to make decisions on important things.

Here are three reasons why you should stop solving other people's problems, and start pairing with them when they come to you with questions:

  1. You will be reducing the risk factor in the project. The risk is that you won't be there when you're needed and people will be stuck without you (also called the bus factor). Can the team handle you being a way for a couple weeks? if not, that is a huge risk.
  2. You will teach other people to solve their own problems, thus making them better at decision making. This will improve your status from "expert at X" to "Expert factory on X". You will have  force multiplier of sorts. Think world of warcraft and you getting one level up. You can start influencing more people and more decisions, by teaching them how to think like you. Now you're the person who you can bring into a team to make them better at doing X, instead of just solving X for the team. That might also mean a salary raise for you.
  3. You will have more free time to do the things you really want to do. Instead of solving the same boring problems for everyone, you now have time to focus on more interesting problems, research or dive into new areas. Delegation is free time. Now you get to become better too!

So what should you do?

  • Someone comes to you with a problem: "hey the build is failing and I don't know why. please fix it for me".
  • You: OK, come sit with me and we'll check this out together. I want you to try and do this with me so you won't have to wait for me next time this happens, or so that I won't be the only person here who knows how to solve it"
  • Them: "ugh, I don't have time for this now"
  • You: OK, so come to me later when you have time and we'll do this together. I have something I need to finish anyway.
  • OR you again: "So what if I wasn't here? that's a huge risk we can't afford. Let me teach you at least how to think about this problem and some common ideas to solve it. it will take five minutes"


Usually that breaks the ice enough. If not, keep at it for next time, but be PRO ACTIVE. No one will do it for you.


Signs you might be in survival mode

We had an interesting discussion in class on how one can detect you might be in survival mode. Here are some possible early warning signs:


  1. There is a perception or feeling of continuous urgency
  2. There is lack of context (why are we doing this? where are we heading? When is this expected? what are the expectations?)
  3. The team is forced into a state where they are always reacting to changes (key word here is forced because a self organizing team can choose to simply react with changes such as during  a continuous delivery flow). Not being able to choose whether to plan some things out.
  4. There is no time to reduce risk (technical debt, bus factors etc)
  5. The team is unable to deliver
  6. There is only time to take shortcuts
  7. A long period of stress
  8. Being non productive for a long period of time