Special Episode: Scrum For Authoring Content and Curriculum

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly podcast. I’m Clayton Lengel‑Zigich. Joining me today we’ve got a special group here, and I’ll let them go round and introduce themselves real quick.

Laura: I’m Laura.

Nancy: I’m Nancy.

Catherine: I’m Catherine.

Mary: I’m Mary.

Starting With Scrum

Clayton: Laura, Nancy, Catherine and Mary are a Scrum team. The first question I have is, what’s your experience with Scrum? I think you guys were all working here before they adopted Scrum, with the exception of maybe Catherine.

What’s the background? How did you guys get into Scrum? Is it something that the company decided to do, and you went along with it?

Mary: The company decided to do it, but it wasn’t implemented evenly. Some groups were doing it, and some were doing it half‑heartedly. I took part in two different groups and had two different experiences, but most recently I found it to be very rewarding.

Clayton: What about you Catherine? I think you’re relatively new compared to the group. Is this your first experience working with something like this?

Catherine: Yes, first experience working with Scrum. I really like it, I think there are so many benefits to working as a team using Scrum. Working as a team is hard, and I think it helps solve a lot of team issues and team problems.

Scrum Outside Software

Clayton: One that’s unique about your group is you guys obviously aren’t…Not obvious to the listeners, but to me obviously, you’re not doing software. One of the big questions in the Scrum community over the last few years is, does Scrum work outside of software? It sounds like from what you’re saying maybe it does, is that right?

[pause]

Clayton: Lots of nodding of heads.

Nancy: Yes it does, in that it gets us out of our own little silos that we’ve been in previously. We’re able to communicate to other groups, which contributes greatly to how we function as a group.

Mary: There are times, I think, when we need to adapt it somewhat for our content development. For instance, in one of my projects we use the Kanban board, and that was helpful there.

Clayton: You thought that worked better than what you were trying to do with Scrum before?

Mary: For the tasks we needed for that particular thing, they were very sequential and it involved different teams. It’s nice to still have the Agile process and the Scrum meetings, but the Kanban board allowed us to proceed on something a little more scheduled.

Scrum Ceremonies

Clayton: You had mentioned the Agile meetings, or the Scrum ceremonies. Do you guys think that the stand‑up and retrospective and planning meeting, are those generally helpful or are those some kind of pain points?

[laughter]

Catherine: For me, I think they are what your team makes them. I think if your team really buys into it and it is more like a ceremony, then it’s much more meaningful, and important, and useful. If you’re just going through the motions, I don’t think it is very helpful. It’s that buy‑in that makes it work for the team, makes it useful.

Clayton: You get out what you put in?

Catherine: Yeah.

Physical Vs Digital Board

Clayton: A change that we had made, based on most of the team’s feedback, was going to using a physical board instead of a digital tool to manage your work. That seems like you guys are pretty happy with that, but can you describe that experience?

There’s a lot of teams out there that probably use digital tools that might not like them, and would want to use the physical board. What would you say to someone on a team like that?

Mary: You feel more ownership when you’re able to go up and grab a piece of paper and take it back to your cube, which I really like about it.

Clayton: Compared to clicking around in the software somewhere?

Mary: Exactly.

Clayton: What else other than ownership is it? Do you guys feel like it’s more visible to what’s happening?

Mary: Absolutely. I think you get credit for the work you do. People look up there and see all those tasks that you’ve performed, and it can be very impressive. It gives you a feeling of accomplishment.

Hourly Burndown Chart

Clayton: One thing that I was doing with the hourly burn‑down chart was taking the capacity of the team on a daily basis. Then stair‑stepping down where the commitment should have been burned down. The joke became that you don’t want to see any red on that chart.

What is it about the red when you guys get behind? Maybe there is an unexpected meeting, and it takes up a few hours. You don’t burn down all the hours that you technically should have, and then the red comes up on the board. Is that stressful, or do you just brush it off?

Mary: It just reminds me back in school, when you get back the papers and they have red all over it. [laughs] Maybe if it was just a different color it wouldn’t be so horrible.

[laughter]

Nancy: We’re in the blue zone!

[laughter]

Clayton: That’s interesting, I guess I had never really thought about that. That’s a good one though.

Collaborating With Other Teams

Mary, you had mentioned collaborating with other teams. Does it seem like the process that you guys are using is helpful to collaborate with other teams? Or is it in the way? How would you describe that?

Mary: If you’re still talking about the physical board, I think that’s opened up some conversations we didn’t expect. Sometimes a manager or someone else will be passing by as we have our stand‑up, and they might have a question for us or a comment. It’s been really good for dialogue.

Clayton: In terms of the work that you’re doing, you have to interact with some software developers. The ceremonies that you’re using, the stand‑up and those kinds of things, have they made it easier to interact with those people, or harder? How do you feel about those?

Nancy: It’s much easier, because when you see people on a more regular basis, it’s easier to work with them [inaudible 06:27] problems as they arise, or build each other up. The demos I find very interesting too, because that gives us the big picture. I think it’s important to stay focused on the big picture too, so the overall product, not just our own little part of it.

Mary: We’ve learned a lot by working with the other teams.

Clayton: Nancy, right up to the sprint review or the demo, there seems to be some kind of trouble with integrating the work that you’re doing, since it’s not software‑based, into the demo. Have you guys found that to be difficult, or is that more of an external thing?

Nancy: It’s external, but I’ve always held that without content, no matter what technology does, if the content isn’t good, the technology doesn’t matter.

[laughter]

Mary: Content rules.

Nancy: Really the content is the meat of everything. Sometimes people get so wrapped up in the technology, they forget about the content.

By having the demos, Curriculum is able to show things from a content point of view, which is a little different than the technical point of view. It’s important for the technical people to remember that they are delivering content.

Demos Help Show The Whole Picture

Clayton: That’s a good point. In the situation where the organization has some teams that are doing Scrum for software, and some that are doing Scrum for content, to keep that big picture in mind, you really need to have both of those groups involved in the demo, right?

Mary: Mm‑hmm.

Nancy: Mm‑hmm.

Self-Organizing Teams

Clayton: If someone’s listening and they’re part of a Scrum team that maybe they’re in the similar situation. Their company adopted Agile, and they were told to use Scrum, meaning they want to use a physical board, or they maybe want to make changes to the stand‑up.

You guys have done a pretty good job of embracing the idea of self‑organizing teams and trying to guide your own future. What are some roadblocks that you’ve run into in that regard?

Nancy: Lack of technical support when we need it.

Clayton: Maybe you want to go down a certain path, but you need some collaboration from the technical side of things?

Nancy: Yes.

Clayton: Have you had any trouble in terms of wanting to do something, but maybe it was off‑limits to a manager, or because other teams weren’t doing it, you couldn’t do it? Have you seen anything like that?

Nancy: I haven’t particularly. I don’t think there’s anything that’s come up that has been an important issue that hasn’t met with some resolution.

Sometimes we get told “No,” but that’s different from not being able to meet and told “No.”

Women Under Represented

Clayton: One of the things that popped into this podcast, Laura, was you had mentioned that a lot of the other podcasts that you listened to have…I’m sure you went back and listened to all of them…

Laura: I did.

Clayton: …the Agile Weekly Podcasts.

Laura: All 60 of them. [laughs]

Clayton: You had mentioned that there weren’t too many women on the podcasts. As far as this organization is concerned, it seems like there is a fair mix of men and women in whatever roles, but from an IT perspective there aren’t too many women.

Is that something that you’ve experienced in other jobs that you’ve had? Do you think that’s an issue contributing to how the teams interact, the difference between men and women on certain teams?

Laura: Definitely. Yeah. [laughs]

Clayton: How does that manifest itself?

Laura: I don’t know. I don’t think it’s something you can quantify so easily. It’s more just a feeling that I’ve gotten. I don’t know. What about you guys?

Mary: Well sometimes we have to translate between the technical teams and our team. Nancy is sort of our intermediary there, she understands a lot of their terms. But it can be challenging.

Clayton: Do you think the difference in gender has anything to do with that, or is it a generational thing? What are some things that make that collaboration have some more friction than maybe it should? Or that you’d like it to?

Different Perspectives Require Translation and Empathy

Nancy: I just think there’s different perspectives from the different groups, and how they view what’s happening. Sometimes Curriculum has a particular way they want something delivered, and the technical folks will say “Why can’t you do it this way?” and the reason you can’t is because educationally you would do it this way.

The programming sometimes has to bend more I think, because of the Curriculum need. Or they would rather do it a different way, because it’s more expedient perhaps.

Clayton: Do you think those problems are easy to solve using a Scrum framework, or some Agile method where there’s more smaller cycles? More feedback, that kind of thing? You think it’s easier that way?

Nancy: I do think it’s easier. It’s easier than to really discuss the issues that come up as you’re doing the process. Because there’s always those variables, those unseens. You don’t when you dig in, and suddenly you’re faced with something that has to be a certain way, and we have to compromise.

Clayton: Is there anything that each of you can share with us that you would change about the process that you have now, or maybe change about the Scrum framework in general? That you think you would be better off if you did something differently, or didn’t do something at all? Or added something?

Effective Process Requires Buy In From Everyone

Laura: I think, just to piggyback on what Catherine said at the very beginning, is you have to have buy‑in from everybody. Being able to at least trust your team. I don’t know how you can implement that, but I feel that way with this team. We all are in it in the same way, 100 percent.

Clayton: You feel committed?

Laura: Yeah, and I think that’s made us a really solid, good team.

Catherine: I think that the expectation has to be set from the company itself, that “This is the way we want to run our company,” and they expect success. I think if, “Oh, we’re just going to give this a try and see how it goes. Maybe it won’t work for our company,” then people don’t have that buy‑in. It’s not important to them.

If the company is leading it and directing it, and they expect it to be successful, they see it as part of their future, then it’s a different kind of feeling for the people that work for that company. It’s easier for them to transition from the way they’ve always done things into something new.

Clayton: Nancy, Mary, anything that you would change or add to the process?

Nancy: I just keep thinking that it’s a work in progress. We’re still refining the process. The company, in some ways, does back it very well.

For instance, we’re doing our performance reviews and setting goals and things for the year, and they’ve mentioned they’d like us to include our Agile efforts in continuing to improve the process.

Agile Transitioning Tips

Clayton: If you guys had a tip to give somebody that’s on a Scrum team that you think would help them out, and they could be more successful, what would that be?

Catherine: Don’t be afraid to take a risk.

Clayton: Take some chances, and see what happens?

Nancy: Be ready to be flexible.

Clayton: Embrace change?

Mary: Yes.

Nancy: Communicate openly.

Mary: Have fun.

Nancy: Yes.

[laughter]

Clayton: That’s a good one. Having fun, be flexible, and enjoy your work, those kind of things. I think we’re about out of time, so I’d like to say thanks for joining us today, and I really appreciate you taking the time to do this.

Group: Thank you.