RSS Feed

Latest Entries


First time here?


Monday
Nov032014

Dangers of Survival Mode

I have just finished teaching a two day elastic leadership class in Denmark. One of the exercises I ask leaders to do is to try and finish a time based LEGO building exercises while the world if crumbling around them (lots of factors that create chaos).

The goal of that exercise, where I play the customer, is to win by delivering to the customer what they expect to be delivered.

This does not mean that what was initially discussed as the requested building is what will be delivered. Team leaders are expected to negotiate and try to change their surrounding "reality" by discussing and explaining to the customer what they can and cannot deliver, and negotiate on time, feature scope, or amount of people they can work with to achieve the task.

It's always a very interesting experiment to see how people handle the stress associated with Survival mode.

Survival mode is that awful place where you are over committed and have no time to learn, so you are left only "reacting"; fixing fires, cutting corners, and never really proud of your work.

Many times it is a spiral, since lack of time to do things "right" leads to much more messy fixes, and slower release cycles, since everyone has very little confidence in whatever it is they are building.

So, how do people, even leaders with experience, react under this situation? In a very human way. The most common reactions are:

  • Give up almost immediately. As a customer, I tell them they have x minutes to finish, and not even a hint of trying to negotiate, or saying that this time frame doesn't fit the work. Many accept this time limit as a given even without asking simple things about the scope such as "how big is this LEGO bridge supposed to be" or "which color does it need to be?"
  • Forget to show demos along the way so they can see if they are doing the right thing. Then failure ensues as what I requested and envisioned in my head is very different that what they envisioned.
  • During the work, fail to notice any team bottlenecks. For example people with disruptive behavior.
  • If helping out as part of the team, forget to look at the big picture, such as how much time is left, showing demos, or are there any inherent problems in the way of work.

As a result, many teams fails to give what the customer expected in the time negotiated. And many teams fail to even negotiate a reasonable amount of time, or even notice they are building the wrong thing in time, or at all.

You might say "It's just LEGO." But lots of the same symptoms arise in real life software development (and other types of teams).How many projects have you been to where, on the first day of the project, you knew it was going go fail?

There is a certain release in knowing something like this. It helps you shed any responsibility to the well being of a project, and you feel less accountable.

Here's the problem with that approach, though. Many team leaders are "thrown" into a dire situation, thinking that the whole situation is "a given". A fact of life that cannot be changed. Doomed project? Guess we're screwed then. Nothing left to do but twiddle your thumbs.

No. You are paid to change the situation you're in, and do good professional work. If that's not what you are paid to do, I think you should leave your job. Most software team leaders have options if they started looking, and there are plenty of companies out there looking for people who want to be proactive bout making things right.

So, what are those things that people think are "given" that aren't really most of the time?

  • The time you have to finish the project is not really a given. It is a direct factor of the estimates that you give at the beginning, and as time progresses you can and should ask for more time/ change of scope or adding team members (although that might make the project even later in some cases)
  • The low quality is not a given. You can change the low quality (at least for new work) by demanding it from your team. Don't have time? make time. Re-estimate. Is that scary to do? Guess what, part of being a leader is doing things that are uncomfortable.
  • People's behavior in your team is not a given. You can influence and help change unproductive behavior. Sometimes leaders avoid directly talking to people in their team about unproductive (problematic) behavior. Part of the work. You don't have to be an asshole about it, but you can be direct without being hurtful. People need to know that there are consequences for problematic behavior. You can even ask people to stop contributing, or ask for people to be replaced. Though usually you should try and work on the problem instead of getting rid of people. It will do good for you as well to try and jump into such a challenge, and you will learn a lot from it.
Monday
Nov032014

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

 

 

 

Thursday
Sep182014

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 perso
  2. Less buerocratic 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.

 

 

Tuesday
Jul222014

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. 

Saturday
May242014

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.