RSS Feed

Latest Entries


First time 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.

Thursday
Mar272014

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

 

Sunday
Nov032013

Technical Disobedience

Rachel's Suffering

In one of my first jobs as a programmer I joined a team working on a governmental project. The team was sitting at the code shop, not at the governmental place.

The coding shop I was working for as a coder at that time had some really good people working there. Many of them were suffering silently.

I remember this one specific coder working there. I'll call her Rachel because that's not her real name. Rachel was in her 40s, and she was an expert database person. She mastered SQL syntax, stored procedure optimizations, index optimizations and partitioning like nobody else at that office.

I remember the first time I came up to Rachel's desk to ask her something. She was hunched over the screen, like Golum staring at his precious ring. Her nose almost touching the screen.

I turned my face at the screen to see what was so interesting. For half a second, I didn't understand what I was seeing. It looked like very small, dead black ants, on a white background, all over her screen.

I squinted (I must have been 25 at the time) to try and see better. These were words.

"SELECT * FROM…"

There were well over a hundred lines of SQL code, in a tiny, oh so tiny font, all made to fit the small 15" screen.

"What the…" I muttered. Rachel smiled with pride. "Yeah, I know". She was proud of having been able to work on such a small screen with such a large amount of data.

She accepted the smallness of the screen as a god given commandment, and was just trying to do her best. She wasn't unhappy, or at least unaware of how unhappy she was.

I could not understand what she was smiling about. She has been working there for at least five years before I stepped through the door, and I tried to imagine her life as a developer, hunched over the code, trying to get just enough real-estate to be able to do their job. Focusing her eyes so many hours a day at such small text must not have made much good.

It was madness.

I looked around, and everyone around me had 15" monitors. A 15 inch monitor was not unheard of at the time, but most developers had at home nothing less than a 17" monitor, and some had 19". These were the old, bloated CRT screens, not the nice thin ones like we have today.

Breaking the Screen Rules

I had a 17" screen. Well, not at first. I started out with a 15" screen, but having had a 17" screen at home, I knew I couldn't go back to working on a 15" for long.

I asked my team leader if I could get a 17" screen. I heard back that there was a line of seniority to receive the screens. There were at least six people ahead of me. Rachel was number 8 on that list. New screen would arrive only when an older screen had broke, which was every couple of months.

I couldn't stand it. I just couldn't accept it. I had just finished reading "Mythical Man Month" and "The Pragmatic Programmer" and was all riled up about having good developer environments and tools that help rather than hurt.

So I took my 17" screen from home and brought it to work. I would work at home with a 15" and work at work with 17". So one morning I just showed up at the office with a big box containing a 17" screen and connected it to my computer. As I walked down the corridor I had to explain to everyone that I got it from home, so that nobody will feel like I cheated my way up to a 17" screen. How silly is it to have a screen size measure your "seniority" anyway?

I was cheating, though. I didn't go by the rules. I went around the rules, and made up my own rules. Nobody got hurt. But I got to work in an environment that was better than I had, and it helped me do better at my work.

I didn't care that it wasn't "my job" to take care of the tooling I was working on. Because it is my job to worry about the tools I work with.

If you don't worry about your technical environment, nobody else won't either, probably.

A year later I got my new screen, but it was old news. I had already been working with such a screen for a year, so I gave up my turn and gave it to the next in line after me.

The Creeping Whiteboard

As I reach back into my mind, I had behaved like this in other technical projects. Always trying to find a way to shorten, simplify or simply work around things that bother me.

In a recent (again, governmental) project, we had to use TFS to manage the tasks. It was a team of 7 developers. And the testers were using Mercury tools to manage their own tasks.

I was coaching the Scrum Master at the time and suggested that we also use a whiteboard to "you know, manage just the weekly tasks". This task board became more and more sophisticated, and the product owner liked it as well.

Soon, all work would revolve around the task board and its notes. People started to forget to put tasks in TFS, and nothing happened.

When I left the project six months later, the product owner asked me:

"Hey, am I crazy, or do we not really need TFS to manage our tasks anymore? we seem to be doing just fine with the whiteboard."

"Exactly" - I replied.

Win for common sense over company bureaucracy. The only reason this worked is because people felt it working. It's not enough to just discuss something and try to convince people. Show them what it feels like.

Technical Disobedience

I never had a name for this behavior that I seem to be repeating over and over again at various places. I do know that it helps move things and get shit done.

I know that I teach it in my book for software team leaders, to never accept the status quo for what it is and to realize you always have things you can do.

Then the phrase "Technical Disobedience" finally clicked into place when I saw this short film about Cuba and the "Technological Disobedience" the cubans had to come up with to survive in a society that had choked out any input of mechanical parts, new technology and new science.

The cubans had to deal with being in a very closed bubble, and had to make their own luck and their own innovations with the things they already had. So they reinvented old ideas, and gave them a twist. Old ventilator engines became bicycle engines, freezer engines. Cars and Bicycle would be combines to create half breed mutants that did what they couldn't do with the things they already had. get around.

And what about us developers?

We take so many things for granted, when we could be going so much farther and faster with just a little more courage to break and remake the small rules that govern our technical life.

We are all locked in our own little technical world; A technical kingdom with DOs and DON'Ts. From startups to "enterprise software houses" — we are all bound by some rules.

Those rules can be as simple as "we don't have the budget to do this", as annoying as "approving a budget for this will take three months", as frustrating as being unable to have test or staging environments due to oblivious "security restrictions" and as down right stupid as "we'd rather spend $20,000 on the wrong thing rather than get the right thing for $1000 because that's where the budgets are".

If you just accept it, you're stuck just like everybody else. If you realize that you can actually do small hacks in the way the system works, you can get things done that none in that organization ever thought possible.

Sometimes you just have to say "screw it" and try out something.
It's better to try than to continue to fail and sometimes it's better to ask forgiveness than permission.

It's actually pretty easy once you try it. Here are some other examples.

The Test Machine(s)

A project I was consulting for wanted to get things just right. The team even got an OK from management to try this new Kanban and Continuous Integration they have been hearing so much about.

So I introduced the team to the idea of Shipping Skeleton. You start with a shipping "hello world" application that gets deployed to test, staging and production with the click of a button, while also passing all the tests. then you start working on the actual code.

Great idea? Only in theory for that team. They tried, but they didn't even have test machines to deploy to and show a demo. To get new virtual test machines would take a month, and they wanted to start as quickly as possible without compromising on their new values. You had to go through a whole system of things to get something as precious as that, and the people responsible were always so damn busy, and in a totally different country.

This is a classic case of management saying one thing, and the system fully designed to say a totally different thing ("screw you, you ain't going nowhere so quickly").

So I went to management as asked their permission to stop using the company that was providing the virtualization services for that team. They were happy and said "go ahead. try other things. it will give us leverage with that 3rd party company come negotiations day. " So I urged the team to try and look into amazon EC2 or Azure machines. No such luck. Security would not let something as simple as that work. Too many loopholes.

So I went to master architect at the company asked him if there are any machines lying around that we could use for internal test and demo machines. He pointed me at the machine we had then used to show demos on the big screen TV, and that as long as it is not in use, it should be ok to use it. Bam, we had a machine under our control that we could at least do automated deploys and demos on. Better than nothing.

The unplanned team room and hardware

Me and a team once took over a non used project room along with a bunch of non used machines from an abandoned project. We had 4 test machines for load testing. it was a good project.

Summary

In software, it is far to easy to accept the system around you as status quo. It is harder to realize that software is soft, and that systems can be soft as well. There are many small rules you can try and hack around to get things done.

Innovation is part of your job, even if the system directs you otherwise. If you are not going to quit your job, do what you can to innovate in your own boundaries, and get things done by changing the rules just enough. That is why I write about continuous experimentation as part of your role as a team leader in the team leader manifesto.

Sunday
Oct202013

Definition: Survival Mode

A team is in "Survival" mode if they do not have time to learn and slowly practice new skills. Such a team is usually over committed and is too busy chasing fires instead of having enough time to hone and practice the skills that prevent the root cause of the fires in the first place.

For example, a team may be too busy fixing all the bugs that keep popping up, that they do not have time to learn and slowly practice design,  refactoring and automated testing of the code to prevent future occurrences.

Another example: A team is too busy deploying things manually and preparing for a release instead of spending the time to create a release and build chain.

Survival mode is usually patterned as a downward spiral. The less time you have to fix the root causes, the more time you will need to fix the fires that are caused, and then you have even less time to fix the root causes.

To get out of survival mode the team needs to:

  1. Remove over commitments
  2. Change current estimates to include quality in the estimates (usually an increase estimates on current work by 100%-500% is needed)

By taking these actions you can create a positive loop in which you fix root causes and then have less fires to fix so you have more time to fix more root causes etc.