By Rebecca Jones
In Episode 40 of The Board, we talk about:
Product owner’s guide to building a successful Scrum team
Gavin Coughlan: Hello, and welcome to episode 40 of “The Board.”
Kirstin Donaldson: I can’t believe we’ve done 40.
Gavin: We should do something…
Kirstin: Look how far we’ve come.
[laughter]
Gavin: I know. If I give it a once over, things have changed pretty dramatically.
Kirstin: We lost someone this week.
Gavin: Yeah, that’s right.
Kirstin: Not permanently. He’ll be back next time. That’s Jesse, who’s not really with us.
Gavin: Not deceased or anything like that.
Kirstin: [laughs] No, no. He’s looking after some stuff at home today. He has left us with a suggestion of what to talk about today. What we’re going to be talking about is developing cross-functional teams. Is that what you wrote on the description?
Gavin: Yes.
Kirstin: That’s accurate?
Gavin: Absolutely. We’re going to be talking about cross-functional teams. This is something that comes up quite a lot, not only with our work here at Boost with our own projects with clients, but also with a lot of companies that we go out to talk about, or to help them with their Agile process.
It’s something that we talk about in our training all the time. We always talk to people about cross-functional teams. It’s a very easy thing to say.
Kirstin: I think it’s easy for us, because that’s how we recruit people and that’s how we run here. Having a flat hierarchy, which for the most part we do have, makes it quite simple to have people do several roles within the team.
Gavin: We’re a small company and we were never a big waterfall shop. In waterfall shops you have people with some very defined roles. We never had that challenge to deal with. We’re really fortunate that way.
Kirstin: What was it like when you, I mean, because you’ve been here a really long time.
Gavin: Yes.
Kirstin: Let’s face it.
Gavin: Eight years, eight years.
Kirstin: Eight years, yeah. You were here when we were still doing projects in a waterfall way about five or six years ago, right?
Gavin: It wasn’t even waterfall.
Kirstin: What was it?
Gavin: It was ad hoc. I’d say ad hoc.
Kirstin: A lot of these processes are ad hoc.
Gavin: We did do all our design up front.
Kirstin: Tim said they used predefined roles.
Gavin: Yes.
Kirstin: I mean you yourself were a front end coder, right, originally?
Gavin: Yes.
Kirstin: How was the shift from having a job that you do, so you only did front end coding, to working within teams where you might be asked to take on different responsibilities at different times?
Gavin: On a personal level, it was actually fantastic to get the opportunity to do different things. To not just have one very defined role. Not everybody sees things in that way, but for me, it was a really good opportunity to branch out and try different things than to get a bit more involved in, I suppose, the nuts and bolts of things.
I was, I suppose, an I-shaped person, as they call them. I-shaped person being somebody who has a very specific depth of knowledge and technical skills and they don’t really have much knowledge outside of that. They really have one very defined role.
I became what you’d call a T-shaped person where I had one very defined depth of knowledge, and then I acquired a range of skills, so I was able to dip my toes into other things.
While I didn’t have the same depth of knowledge in every other field as I did in my specific, I suppose front end stuff, I was still able to help out if somebody wasn’t there. It didn’t mean that the project ground to a halt, because I was able to take up the slack a little bit.
Kirstin: You basically made yourself much more useful than you were before?
Gavin: Then I became a Project Manager, and…
Kirstin: It’s all over. [laughs]
Gavin: I know my skills are about six years old, which in this industry means very little unfortunately.
Kirstin: In the example of our organization, were there any issues with…I mean, obviously the team’s changed quite a bit since they actually in terms of people that are here, so I think we can talk about this without mentioning names obviously. Is there anyone that wasn’t happy with having to make a change from having that depth of knowledge to acquiring other skills?
Gavin: Certainly, there’s always going to be people who…for example, if you’re a developer, a lot of developers want to do that one thing. They might be the sort of person that wants to put on a set of headphones and do that one thing for the rest of the day, and not be bothered.
Kirstin: I’ve seen that.
Gavin: They loathe doing, for example, testing. That’s one of the biggest areas where we see the cross-functionality being difficult is when you have to find testers and you have to find developers.
Kirstin: Did we have to find testers back in the day?
Gavin: We never had to find testers.
Kirstin: Oh, OK.
Gavin: It’s always been expected that they would do it.
Kirstin: The evolution for us has been slightly different from say, for example, a large corporate where they hit those very defined roles.
Gavin: That’s where you see problems. Unfortunately, in a lot of companies that I see, testers aren’t considered to be at the same level as developers. They’re a little bit of a level down.
Kirstin: I didn’t know that. I was reading an article before we came in. I didn’t realize…I guess, we’ve been a bit shielded from these hierarchical-type structures that you see, they don’t consider it really, do you?
Gavin: Yes, yes definitely.
Kirstin: You’re saying that testers are considered to be [inaudible 05:06] than developers?
Gavin: Developers think they’re going to damage their own reputation if they become a tester, and if they start doing a lot of the testing stuff. They’re worried that they won’t be able to progress as a developer, and it might harm their career. They might not have the opportunity to learn other languages and really progress their skill base a little bit, because a lot of their time will be taken up with testing.
They’re worried that if they go for an interview in the next role, it’s not going to look that great that they were developers [inaudible 05:37] tester, rather than a very defined developer. Which actually isn’t the case at all.
Kirstin: Particularly not if they’re applying for a role in an agile company like ours. We love to hear that people have been doing testing as well as developing, particularly for things like TDD and BDD. Which I think can only increase a developer’s knowledge of code as well, if they’re doing thing like writing tests up-front and then writing code to satisfy.
Gavin: On the flip side it is a bit of a shame as some companies do have this sort of hierarchy and somebody might join as a tester. It’s only when they are considered to be, you know, good enough or reached a certain level then they can move on to become a developer, which I don’t really understand.
Do people think they have to be of a certain mindset to be a test and a certain mindset to be a developer and never the twain shall meet? That is not a situation that we see really.
Kirstin: I guess one of the keys any one of these more traditional companies take, I think cross-functional team, is making a change in structure.
Gavin: It is a dramatic change for a lot of people. Sometimes, the last change that I see people are really willing to make…
[crosstalk]
Kirstin: People are very, very afraid of losing status at work, whether it’s perceived or real. I guess if it’s changing from a management level then those fears can be alleviated somewhat.
Gavin: I mean, the risks of not doing that should be evident pretty quickly, and they are evident within every sprint because your sprint is turning into little many waterfalls, basically, where the developers work on their stories and they do the task that they need to do on that story. Only then can they be passed it on to the tester and then the testing can actually start.
Invariably, you’ll find that stories aren’t getting finished within a sprint and they can’t because the testers are waiting and possibly haven’t got huge amount to do until they actually get a story. They are going to do that testing nearly the end of the sprint and, of course, they are going to find some stuff.
Some bugs are going to come up and there is no time to actually go back and fix those bugs. They have a lot of stories they are actually going to finished at the end of the sprint and the developers might have said, “OK, that’s all, our task is done. Brent, we’re really happy with that. We’ve done fantastically well with the sprint and we ready to work and bring in another story. Pull that in and start working on some tasks there.”
Then you get to the end of the sprint and you’ve got a whole bunch of stories which aren’t actually finished and might look good in sprint because people are pulling in new stories. Still the stories that are actually higher in priority in the backlog are not done.
Kirstin: A few are working to [inaudible 08:45] that include test and signed off, then it’s probably going to be a bit of a situation. Of course, the optimal situation is if testers and developers are working together or taking on some of each others’ tasks.
Gavin: Absolutely. It was Jeff Sutherland who said he would rather dare developers go out and go surfing. We were talking about actual surfing, not [inaudible 09:07] [laughs] surfing the web rather than me writing unnecessary code. At least everybody is happy and they haven’t wasted money writing code that nobody actually needs.
Kirstin: That’s quite a radical view for a lot of people?
Gavin: Yes.
Kirstin: The idea that someone won’t stop working rather than producing something unnecessary…
[crosstalk]
Gavin: It’ll be particularly radical for people who leave in land-locked cities.
[laughter]
Kirstin: You know surfing could be anything. It’s just that the general attitude tends to be that if one should be working overtime for eight hours a day and not taking off for any reason.
Gavin: The most important thing is, Geoff Watts, I think we’ve mentioned him a few times because we are reading his book at the moment, “Scrum Master.” It’s a really good book.
He says, “A good scrum master encourages the team to share the skills, a great scrum master encourages the team to share responsibilities.” The team’s responsibility is to make sure that they are delivering value within the sprint and make sure they are finishing those high priority stories because those stories are the guidance that should be delivering that value.
Kirstin: That’s right. It’s more of a broad concept and that really is throwing it back to the team to figure out how they can all take responsibility other than saying, “You should be doing some testing…you should be doing some testing”.
Gavin: If a story isn’t finished at the end of the sprint and the product owner is disappointed, they don’t care whose fault it is that that story isn’t finished. They just care that that story isn’t finished.
Nobody within the team should care whose fault it is either, because it is the team’s responsibility to get that story finished. That’s the work they’ve committed to and that’s the item that has been decided by the product owner and probably a group behind the product owner that it is the priority and that’s what needs to be done first.
Kirstin: What’s the thing that teams do to build their skills in the areas that they don’t have a deep knowledge in? Things like pair programming?
Gavin: Pair programming, that’s something that we do here. That’s a really good way of getting new people on board and a really good way of sharing skills, and also creates really good team bond as well.
We also have our designers with developers a lot of the time to actually make a story progress, and it means there’s nobody’s waiting for somebody else to give the work to them. They’re actually working on something together.
It’s great. If you do have tester roles and developer roles to have those guys actually working together as well because the tester can help the developer write better code. The developer will be writing code that’s going to be a little more stable, and easier to test.
Kirstin: If you using to incite tester and development and behavior during development, a tester might start rushing those tests, and working in their way with their own final test. The developer writes a piece of code, so really working together, but then eventually there might be some cross over where the tester might start writing the code.
The developer might start rushing the final test because there’s no reason not to. The line becomes blurred on who’s the developer, and who’s the tester and doesn’t really matter.
Gavin: On pair programming, I’ve seen product owners who don’t like the idea of pair programming because they think two people on one story is a waste of money. Why doing it? Have different people with different computers.
Also some people who come to Boost, and they hear where pair programming just say, “Uh, uh, I’m not doing that. I don’t want to be sitting beside someone new when I’m doing my work.” They’re quite resistance to it, but once they actually getting involved with it they realized that…
A lot of people think that pair programming is one person doing the coding, and another person just sitting there just watching it, which is absolutely not the situation you’re meant to have. A driver is the person who’s actually at the keyboard and the navigator is the person who’s actually guiding what’s been written.
Kirstin: The view that some people might have that it’s putting two people on one job therefore costing twice the money to do that job is not seeing the bigger picture. The bigger picture is being the impact that it has on the future of the work or the code.
Having someone else be familiar with that area of coding where they might not have been before means that when we have things like illness or annual leave, someone else can still work on that code. We’re eliminating the delay on working on that piece of code by providing more knowledge around it.
Gavin: You’re right, and that’s also something that I just read today, it’s called the lotto factor. I can’t remember who came up with that quote, but it’s basically what happens if somebody wins the lotto, and decides to throw their job in.
Kirstin: I would not throw my job in. I’d totally come in the next day.
Gavin: Where?
Kirstin: No? [laughs]
Gavin: I’ll be out of here. I’ll be at Honolulu in like three hours.
Kirstin: Be back for the party right?
Gavin: We have to guard against things like that. We had a situation here at Boost where the server god and they knew everything about that, but nobody else knew anything about it. He went tramping which is hiking, what they call hiking here in New Zealand for a week completely out of cell phone range, and everything and…
Kirstin: What happened?
Gavin: Things didn’t go well, and when he came back we learnt that that’s an I shape person right. It ends up that he went in the server to do some work, bring another team member in and they help and that shared knowledge for…
[crosstalk]
Kirstin: I don’t remember quite correct that one year actually. Still working on up scaling…
[crosstalk]
Kristin: …structure. We have to keep working on that one.
Gavin: Absolutely it makes many things that we have to keep working on, and that’s the idea right? That’s part of the joy…
Kirstin: It’s interesting that we identified that some time ago, and I think we still haven’t got it covered. I’d say we’ve done really well in other areas in terms of having cross functional teams but actually still to be tackled.
Gavin: Cross functionality obviously really, really important. We’ve talked about one way to help foster a cross-functional team. What other ways are there?
Kirstin: Debbie had something to say about this. She was saying the only way to deal with effectively with turnover on teams, absences, et cetera, is for each member to be doing one thing, learning another, and teaching a third. Which I think is great advice. It’s really simple, but I think it would really work.
Obviously you can’t do all of those things at the same time, but as people during a sprint could maybe keep that in mind. It might help people to evolve in this way. I’m not sure we should say that, but we can certainly put that up on the…
[crosstalk]
Gavin: Everybody is doing one job.
Kirstin: Doing one job.
Gavin: Learning another, and teaching another.
Kirstin: Teaching another. You’re getting that constant exchange of skills. I think it’s a really good thing to remember. There can be a tendency for one team member to be the person who’s always teaching other people. That person can also think about the things they might need to learn then it excites more exchange of skills rather than opposed to one person always being the guide.
Gavin: I’ve also heard of people who impose work in progress limits, [inaudible 16:38] style on their swing board. There can never be say more than three things in test, or two things in test whenever. If that limit is reached and there’s a bit of a bottleneck everybody swarms around that problem.
Kirstin: That’s a great way of doing it. Sometimes people forget to sort of raise the hint and they forget that actually we should be pouring resource into achieving a close on stories.
Gavin: Sometimes I see teams and think everything’s great. Look everything’s in progress. Don’t you think everything’s progress in the scrum board is a…
Kirstin: Is a good thing.
Gavin: …is a positive thing, but it’s absolutely not. We’ve learnt ourselves, we’re still learning, and it’s difficult sometime you have to keep reminding yourselves that you really need to finish one thing, and move on to the next.
Kirstin: Start and finish, start and finish.
Gavin: It’s really beneficial to the team, and that’s really beneficial to the product owner to do things that way.
Kirstin: Absolutely, it’s alarming when you get past the scrum board, and everything is in progress.
Gavin: Yes, absolutely.
Kirstin: It’s great that we started these things, but is there any chance of finishing any of them?
Gavin: Yeah.
Kirstin: It’s kind of feel like saying when you get back to the top.
Gavin: Basically.
Kirstin: I guess it’s not about that. It’s about sitting down, and saying how could we possibly achieve some closure on this.
Gavin: It’s a little of like you said cross functional team it’s easier in small companies like ours, and when the Agile approach has been embraced from the top down and then the down up…
Kirstin: We haven’t always worked with Agile. It was the point that I said earlier. It is something that can be achieved making the shift from one thing to another, and it takes time.
Obviously it’s taken quite some time I think for this to become the kind of place where you’re a developer, you’re a designer, and there’s sort of nothing in between. You have a junior, the intermediate, or a tester. You are the person who does that role, and sometimes does other things.
Gavin: To take people out of their comfort zones, and that’s something that I see when I’m doing training quite a lot when I talk about cross-functional teams. I can see people aren’t comfortable with the idea.
Kirstin: Particularly people who don’t feel like they can identify or place themselves on the team. I’m talking particularly about business analysts. I think they find that their work is very specific and find it very tough to find a place where they might do other things.
We would always coach business analysts about, maybe taking on things like writing some behavior development tests, because they are after the people. They’re dealing with the requirements, and should know the outcomes they want to achieve. I guess it’s pointing out opportunities for them as well.
Gavin: If people are finding that they aren’t able to finish things within the sprint, they’ve got to look for add options. The square master really has to get involved there as well to help the team feel comfortable about that.
Also to make sure that the company is treating it well. We now have conversations, plus we have management and then have conversations with HR, and make sure that it’s done well, and that the team worth is supported.
Kirstin: You don’t want some manager coming along and say, “Well, why are you doing that? That’s not your job. You’re wasting your time doing that.” I can see how that might happen in a larger company if there was a lack of understanding for the reasons why. I guess that’s part of it.
Gavin: There is another approach that I heard or rather that I read today of one company doing, and they have initiation knowledge test. Each member of the team has to display that they have the capacity to complete a task in each and every area. It might be developing a certain feature. It might be doing some test automation.
Kirstin: For every sprint coming in.
Gavin: It might be doing some database stuff, so they display that they can complete a task in each of those fields.
Kirstin: Upfront in sprint planning, or during the…?
[crosstalk]
Gavin: No, while they’re working and during the sprint. Eventually, they get a deputy badge. If they have a skill that they are dedicated to learning, they get a sheriff badge. If they’ve got a really broad knowledge for that skill or really deep knowledge of that skill and can actually teach it to somebody, they get a deputy or a sheriff badge.
This initiation knowledge test is something they could also do in your hiring process to see if the person that you are actually bringing on the team has a broader range of skills as well.
Kirstin: To actually to see a task for each area that they might be asked to look at?
Gavin: Yeah.
Kirstin: That’s something to think that obviously we were recruiting at the moment. Fantastic.
Gavin: We had a team member here, because we don’t have testers and developers. We had a team member join here and their favorite system to testing.
Kirstin: Did we?
Gavin: Yes.
Kirstin: [laughs]
Gavin: They didn’t want to test. Said, “I am not a tester.” It was pretty black and white, and that was, obviously, problematic for us. The proof was in the pudding there, because once we start working, and work was going to the project owner with insufficient testing, is always coming back and is always…
Kirstin: It’s low quality, right?
Gavin: It’s low quality, and it’s always coming back, and it was a problem for the project owners, it was a problem for the team. It was a problem for the project at the end of the day. No better way to learn than to see that the impacts of not doing something.
Kirstin: The person in question is now testing their work, right?
Gavin: Yep. Absolutely.
Kirstin: Which I’m sure they’re seeing the benefits of them in terms of having a happy client for a start. That’s what we’re essentially after, is delivering good outcomes to the clients. Everyone wants to work with happy people that are pleased with work that’s going on.
Gavin: Reese had gone into to me and had a chat about testing and some of the, I suppose, best practices that come from extreme programmers. We talked about pair programming and acceptance test driven development and test driven development.
They’re starting to deep their toes into BDD at the moment. They’re getting a really positive approach from that, or a positive result from that, which is fantastic.
Kirstin: They’re using some software to help them with that, or…?
Gavin: They’re using Gherkin as the language to actually write their Behavior-Driven Development in.
Kirstin: …and Cucumber. People don’t only use that, don’t they?
Gavin: That’s working out really well for them. I’m hoping that it spreads out to the rest of the community. At the moment, they have no automated testing, and a lot of advice we give to people is to start with something small. Automate one small story, one small feature, and see how that works, and then hopefully, that will branch out a little bit, but they have started mob programming.
Kirstin: If it’s a particular problem?
Gavin: Well, a particular story, and another great way to get that cross functionality, and to make everybody understand each of those roles as well. When they have a big story that may be problematic, they all basically swarm around. You might swarm around one machine and have a lot of people doing different things.
Somebody might be doing some high level UI. Some people might actually be doing the coding. There’s a lot of advice, and it’s a bit of a hub of activity, but you really get something finished and actually done very successfully because it’s had very many sets of eyes on it.
Kirstin: The quality is definitely higher as well.
Gavin: The quality is definitely much higher. That’s a difficult sale sometimes, especially for us. They’re just working on their own internal stuff, which is fantastic. For us, I think that will be a difficult sale to clients.
Kirstin: Because everyone runs a different project.
Gavin: Yeah.
Kirstin: Even that particular company has only got one product, or one or two.
Gavin: I’d love to try though. I’d love to try mob programming, and hopefully we’ll get the opportunity to do that.
Kirstin: Maybe during an R&D session. I know that tomorrow is R&D. Two of the guys are getting together to do a prototype for a current project that we’re doing. They’ve been doing this independently with the client because they wanted to test something out.
There may be some opportunity for a number of people to work on that tomorrow afternoon to produce something really great to take the client. That could be interesting. I’ll mention that to people tomorrow.
Gavin: That’s cross functionality, the importance of it really, and some ideas about how you might be able to foster cross functionality in your own teams. We’re certainly trying to get better and better, so if anybody ever has any suggestions, please leave a comment.
Kirstin: We’d like to see. People are joining us to watch the show live. If they want to comment, we’d love to see some comments and answer those for next time.
Gavin: Even on YouTube when we throw it up there.
Kirstin: I’m happy to check further. I think next time we might be talking about image and design and why it works, and why it’s important. Unless we change our minds for the next two weeks. Otherwise, we’ll see you again in two weeks.
Gavin: OK, thank you.
Kirstin: Thank you.
