Jade Meskill, Clayton Lengel-Zigich, Roy van de Water and Derek Neighbors discuss:
- Technical Scrum Masters
- Team Workspaces
- Working from Home
Jade: Hello, and welcome to another episode of the “Agile Weekly Podcast.” I’m Jade Meskill.
Roy van Water: I’m Roy van Water.
Derek: I’m Derek Neighbors.
Clayton: I’m Clayton Lengel‑Zigich.
Jade: Today, guys, we wanted to talk about how technical does your Scrum Master need to be?
Roy: Define technical.
Jade: Let’s say that your average software team…At what level of technical detail do you think it’s good for the Scrum Master to be aware of and maybe what’s too much?
If you had someone that used to be a developer on the team and then they got promoted to Scrum Master, theoretically, they are going to have about the same level of technical knowledge.
Roy: They should know how to turn on the computer and know how to use rally.
Roy: [inaudible 0:00:53] one that’s said Derek optional.
Derek: The second one is optional. OK, so you are talking software, hardware technical, not Scrum technical.
Jade: I’ll give you an example. Let’s say that I’m a Scrum Master on a team and the team is planning and they’re going through some implementation. They’re talking about it and I get the impression that they’re going off the deep end and they’re just going in circles but I don’t know enough about technical stuff to be able to tell if that’s true or not so I just keep my mouth shut.
Roy: I think I’ve heard Derrick say this before, where if you can’t, as a non‑technical Scrum Master, if you can’t understand what’s going on, during like a planning meeting for example, or even worse in a story workshop then it’s probably to implementation level for that type of ceremony. It’s something that should be talked about during pairing.
Derek: I guess for me, the way I would look at it is, that the Scrum Master should understand the work that needs to be done. They should not care how that work is done. If you’re talking about a self‑organizing team, I think the Scrum Master needs to understand what the product [inaudible 0:01:56] owner wants so that they can help facilitate the team to get there.
I don’t think they have to know anything about how the team is actually going so in some ways that actually cripples a scrum master because they get way too lost in the technical details instead of just looking at the signals, right?
If I’m an EMT, I don’t need to know how to do heart surgery, but I should be able to read any EKG reading right? I think the same thing…A Scrum Master should be able to take technical readings of what the data is telling them and burn‑downs and other things and stand‑ups and ceremonies and be able to say, “I’m worried”, but they shouldn’t care about the actual technical details.
Roy: In this particular case, you are talking about some kind of ceremony. I can’t remember if you said planning or…
Jade: I said planning yeah.
Roy: A planning session where they’re getting into details as a scrum master can’t understand, and I guess my attitude is, as a non‑technical scrum master if you can’t understand it, then it’s probably too technical to be discussed during planning, and it’s not a matter of the scrum master not having enough technical knowledge.
Jade: You’re right. I’m getting the impression that if I as the scrum master, rather than focusing on learning more about the technical stuff so that I could understand the problem better, which would be the EMT learning more about heart surgery, I should really focus on my facilitation skills and being able to pick up on those cues and triggers, better read the EKG.
Derek: I would say, “Why do you care how technical somebody is in a planning meeting? If people need to get very technical in a planning meeting, why should that be a problem?”. Usually the reason it’s a problem is because they’re taking forever planning because they’re getting into way too much detail.
If I know that, “Hey, we’ve got X amount of work to plan” or we’re going through planning, and people are taking forever to get something done, I could say, “It feels like we’re getting into a lot of detail. We’re taking an awful lot of time discussing implementation, maybe we need to step it up a little.”
I don’t need to know anything about what that implementation is. I just have to facilitate, “Hey, the energy in the room is completely dropping. There’s something wrong. Can we change it?”
Roy: That’s true and you’re right, because I’ve seen people that have absolutely no technical background still be able to tell like , “Hey guys, Isn’t this a little too in the details?”
Derek: I think having a technical background can help, but I think more often than not it tends to hurt more than help, because you try to use that technical knowledge to help your team.
Roy: It’s hard to be impartial when you have knowledge.
Jade: Yeah, you’re your own worst enemy at that point. Let’s talk about work space design, work space layout. How does the work space that you’re in affect the team itself and the work that you’re doing?
Roy: I personally feel like there’s two very important pieces to a good team environment from work space perspective, which is the ability to communicate freely between the team members directly, being able to see each other, and then also having the freedom to communicate loudly without bothering the people around you, if that makes sense.
I can see Clayton and talk to him directly if he’s on my team, but me talking to Clayton will not bother Derek who is on another team or working by himself. That to me, is a good work space.
Jade: I did an exercise with…I guess probably about forty people or so, and I had them draw their ideal work space. They all pretty much were the same, where they had a team area which describes kind of what Roy’s getting to where people could pretty much look at each other, and talk to each other very freely.
There was always a space for some kind of quiet thing, like you could get away from the team if you wanted to. There was some fun aspect where that would be like, you do work over here but then over here is where you have fun. There were some other things sprinkled in but those were the main themes.
I think almost all of them were framed in the concept of a bull pen, which I think was more just. That’s what the people who did the exercise were familiar with. They hadn’t experienced something like a gang plank which had a very open floor plan that was very sprawling. That’s kind of their mind set. They were in that box.
I like the idea of having the free and open communication with the team members and having an open space that you can feel safe talking in.
Derek: I think, I don’t know, probably circa 2006, 2007, Mike Cone made a really great blog post called “The Ideal At Work Space”. It had nine or ten qualities and I believe our innergram made a counter video to that.
They added two or three additional ones as well as showed some visual parts of the work space. I think all of those things are still absolutely relevant today. I think you guys hit on two of them. One which was every person on the team should be able to see the other person on the team, which I think, whether it’s a bull pen, whether it’s a wide open space, that you should be within visual contact of everyone on else on your team.
Another one was that there’s a place to have quiet meetings or what not. I think there’s something about visual pieces that the work is visualized somewhere within the space. There’s a number of things. Those are all great points.
The thing that is really difficult when I see a lot of teams struggle or organizations struggle is they say, “OK we’re willing to make the commitment to go to some more kind of open style. “But they have this whole inventory of this really crappy cubical furniture and so there’s this sunk cost of how do we get rid of this and disbelief that you could go to really light weight six foot tables that are upper end Ikea type of tables and put them on wheels.
That is so foreign to facilities like whoa…”but then how do you deal with power and how to you deal with Ethernet?” It cascades this panic within the organization of un‑possible.
Jade: Probably just like their software.
Derek: Yes. This is something we talked about with [inaudible 0:07:52] in Portland at Open Northwest, right? There’s cultural debt in the same way that there’s technical debt. When you build up these giant facilities department who has three hundred change orders who have to fill out to get an Ethernet moved in a day where 90% of people connect through wireless anyways.
It’s like when you can’t move your physical location from one cube to another, that’s an act of God. Imagine if you say, “We’re just going to get rid of all the cubes.” That is full on pandemonium like whoa. How will we track our assets if there’s not cubes that they belong to? Currently we use a Cube ID to track everything that happens.
Roy: For effective management. How do I know if Clayton is even working if he could be sitting and working from anywhere. I got to be able to stop by his cube at several points [inaudible 0:08:42] the day and make sure he actually shows up.
Jade: Let’s go down a tangent here on this one. Marissa Mayer just announced at Yahoo there is no longer a remote work policy.
Jade: I know, can you believe it? As of June, Yahoo employees either need to move to be physically near their headquarters or they no longer have work from home privileges. What do you guys think about that?
Derek: I think if we go buy those principles of what is a quality as a work space, one of things is you should be able to see all the people on your team.
Jade: I have Skype and I have G‑Chat.
Derek: Now that said, I think you can do close facsimiles of or proxy’s thereof those things.
Roy: [inaudible 0;09:26] keep with people who use the real thing?
Derek: The problem is that is it really difficult? If everybody is virtual, I think you stand a better chance than if only a few people are virtual.
If you have the choice between interacting with the real thing and a virtual thing, you will probably choose the real thing more often than not and so those people become ostracized as the virtual people.
If you’ve ever been on a phone call with a conference call calling in, and there’s eight people in the room and two people on the phone, it’s amazing how people will end the meeting without even saying goodbye to the people on the phone because they’re not even part of it.
Roy: We even observed this with Innergram when you were working from out of state, Jade.
Jade: Yeah. It was very hard to be part of the team. I’ve seen a lot of reactions to this announcement. The biggest thing I think of, when I see what people are writing is, this really comes down to the type of work that you’re doing.
If you’re doing very individualized work, it really doesn’t matter where you work from. It doesn’t matter,because your work, is your work, is your work, and you can do it wherever, whenever you want.
What I see, is people who value having team based, shared commitments, who are probably doing something that is more on the innovative, creative side than repetitive tasks, individually focused. They really struggle with being distributed. It’s much more difficult for them to do.
Derek: I saw a counter to that, in an article and I don’t know if I’ll be able to find it again. They said, “If you’re doing really raw, simple manufacturing type of tasks, then yeah, everybody should be together.
If you’re doing really complex work, you should be spread out, all over the place, because it requires really specialized people and you can’t find the best, specialized people on the same location.
If you are going to do a really complex thing, you’re going to have to get the best expert in the world, and they might be in Russia and the best expert in the world, on this other thing, is in Brazil, and the other person, is in San Francisco. It’s impossible to build teams that solve complex problems that are co‑collocated, because you can’t get the best people.
Roy: I don’t think I agree with that.
Clayton: Well, that’s always the argument. You see this a lot from programmers, who talk about, “Oh, this company…
Derek: …Ten times…
Clayton: …wants to hire this awesome…Yeah, exactly. “Ten times programmer.” People who think they are. “Oh, this company wants to hire these people that have this awesome resume but, they only want people to work in Nebraska.” Well, that’s bullshit because, I’m so awesome, but I want to live, wherever I want to live.
Personally, I don’t want to work on a team, with a whole bunch of awesome people that are all over the place. Give me the average people that can be a team. I’d rather work in a team environment.
Roy: If people think they’re so awesome, that they should be allowed to work from home, are probably not [inaudible 0:12:06] culture.
Jade: It again goes back to if I am doing something that is highly specialized, individualized, then yeah, that’s probably a true statement. I probably can’t find those people around my local area.
Derek: Well I think…
Roy: How many people are really doing something that’s that specialized?
Derek: I saw somewhere…
Jade: I think a lot people think they are.
Derek: I saw somewhere that somebody had summarized, well what I think my viewpoint on that in, that is, if you want to be the most efficient, probably work anywhere you want, anytime you want, however you want, is the best place to go.
If I work best from two o’clock in the morning, to six o’clock in the morning, if you want me to be the most efficient, you need to let me work at that time. If I worked the best with headphones, in the dark, in a basement, you should let me work that way, if you want me to be the most efficient.
Roy: I don’t think I agree with it.
Derek: I won’t necessarily be the most creative, and I won’t necessarily have the best solution, so the counter argument to that is, if you want people to be the most collaborative, the most creative, and solve the hardest problems, they actually have to be co‑collocated. You are suffering a little bit of efficiency gain, at the individual level, to have a better systems gain.
Clayton: Possibly a lot of efficiency.
Roy: In terms of efficiency though, that’s a lie too. People lie to themselves when they talk about how efficient they are when they work from home. If I were to not be honest with myself, I’d say, I could work from home, over the weekend.
Did you [inaudible 0:13:29] you turn me down?
Jade: Tell us how bad you are working from home.
Roy: I could see myself, I’d work the entire weekend, and I could work the entire time through, but in reality, if I was really honest, I’d probably end up working, maybe, two or three hours out of that, if that, and I’d probably be distracted a few hours. Reality doesn’t quite correlate with what it’s going to be like.
Jade: I think there’s a lot of studies that showed that people are more productive at home but then I always wonder, if you have a BS job, where you are pushing paper around all day, and you just do it from home. You are probably more productive because you don’t get interrupted by your stupid middle manager, who is a total waste of space too.
This whole thing is a foundation of lies. You are doing creative team based work. I just don’t buy it.
Derek: Well, I say this all the time. I am way more effective when I work from home. In doing the stuff that only I need to do. I can bust through my email box, get my to‑do list done, get all sorts of [inaudible 0:14:24] and I am way more effective at home doing that. Even if I only work two hours, opposed to six hours. The problem is, I am not effective at all because I’m not able to leverage the thing that I do best, which is, get people to work together to solve real problems.
Can I be more effective? Sure, in answering email. Can I be more efficient in answering email? Absolutely. Is that the most effective use of my time is answering email? Probably not.
Jade: I think the trouble is, you get distracted. Doing those things at work, with a whole bunch of other people, that you don’t even have time to focus on the creative stuff. We’re not valuing those things in the work that we’re doing.
Alright, well thanks for listening to the Agile weekly Podcast. We’ll catch you next time.