Sprint Zero, Working Agreements, Performance Testing and Backlog Grooming

Clayton Lengel‑Zigich: Welcome to another episode of the Agile Weekly Podcast. I’m Clayton Lengel‑Zigich…

Derek Neighbors: I’m Derek Neighbors.

Roy vandeWater: I’m Roy vandeWater.

Sprint Zero

Clayton: We’ve got a backlog of items today that we wanted to talk about. The first one is Sprint Zero.

Derek: Sprint zero.

Clayton: Derek, tell us your thoughts on Sprint Zero.

Derek: One of our regular contributors to Agile weekly, Brainslink, had posted something about Sprint Zero and the value of Sprint Zero. That those in scrum or in Agile tend to devalue Scrum Zero. In an enterprise environment, it is really necessary oftentimes to have a Sprint Zero.

Roy: Cowards, stop having enterprise environments.

[laughs]

No Architecture Is Irresponsible

Derek: [laughter] My general response back was pretty similar to cowards and stop having enterprise environments. Which was that I think his argument and the article tended to go around, it is irresponsible to have no architecture, to have no kind of plan going in.

Clayton: Right.

Derek: What happens is if you just hit the ground running Sprint One and do the quickest thing to get working come sprint four, five, six, something down the road, you realize that you’ve made this really horrible choice because you didn’t really think out the bigger picture and how it interfaces with other things. You end up having to undo a bunch of work and so it actually causes more problems then if you just violated these Scrum principles and did a Scrum zero.

My response back was I think that the danger in that is that it gives us false sense of security and that if we only spent an additional sprint before we did work to plan it then we won’t have any problems and everything’s going to be right. What I tend to find is when I’ve seen sprint zeros that all of the same problems happen in four or six weeks in, all of the decisions you made you…

Clayton: That’s true.

Derek: You found better decisions for them and you want to undo things so why bother with the first sprint zero to begin with.

Roy: I think that the thing that unifies them that the thing you find out in week four that causes you to regret the decisions you’ve made in week one are things you don’t know in week one.

Derek: Correct.

Roy: If you spend a week in week zero trying to set stuff up, you still don’t know what’s in week four no matter how much time you spend on sprint zero. If you have five sprint zeros you are still not going to discover what’s in sprint four until sprint four.

Clayton: There’s a concept in the book “Guided Object‑Oriented Software by Tests” that talks about having a walking skeleton which is kind of the idea of build something that you can deploy that actual exists. You can press deploy and it goes to production and it works.

So, would you recommend that if a team wanted to avoid a sprint zero and they actually wanted to deliver a value in the first sprint, would it be OK if they started with maybe bigger sprint than ‑ ‑ maybe they thought they would do two week sprints, but if we look at the work to get this whole entire thing working it has to be three weeks.

How should they handle that?

Roy: It shouldn’t take you that long to deliver that sense of value. [crosstalk]

Clayton: Say it does. Say it does.

Not Being Able To Start Is Real Issue

Roy: No, that’s bullshit. No, that’s your root problem. Assuming that you have one leg, how are you going to run this one meter sprint?

I think that is the bigger issue at hand, is that I think when you believe that you couldn’t put a bare skeleton out in under ‑ ‑ and so, it brings links, kind of, comment his thing was, I would never advocate a thirty day sprint zero, but I think a week or two sprint zero makes sense.

I think what they’re saying is, well we need this time to do this research. I don’t think they’re talking skeleton. I think they’re talking to do the research to even do the work.

I would argue that if you can’t do a skeleton within a sprint, a two week sprint, you have something wrong with your tool set, or your skill set, that probably needs adjusting much more than a Sprint Zero is ever going to fix you.

Derek: It’s going to hurt you in every single sprint. Not just the first sprint.

Roy: That is correct.

Performance Testing Is A Waste Of Time

Clayton: Alright, so we gotta move on. The next topic that I want to talk about, is performance testing. I think you should also call this a waste of time, because pretty much everyone seems to waste time when they do this.

Have you guys ever seen anyone do performance testing where it has been valuable?

Derek: Yes and no.

I’ve never seen anybody do performance testing beforehand be valuable. Meaning, usually when people do performance testing they don’t do it on their real environment. So, you know, all of these little things that are really the performance bottlenecks are never seen. It’s, you know, “We are worried about data reading rights so we are going to test the crap out of that.”

But its late in the latency that really kicks their ass and so know that because their local network has no latency, but when they put it up in the cloud, the cloud has latency, or vice versa. You know, things like that.

I think the Lean Startup methodology has really started to push towards ‑ get it in customer’s hands as soon as humanly possible.

If you are worried about scaling limited number of users that are allowed to use it and open it up as you go until you hit a bottleneck, and then go in and start to test around some of that. I think you can do some things ahead of time to potentially give you some best practices, whether that’s tools like New Relic that or like Jamie standard things that you can run that will give you once of it. But I think going hog wild and creating all sorts of harnessing and everything else, is just a waste.

Roy: If you are talking to your communicating effectively with your users, they are going to tell you really early on, two things you should be doing is talking to your users and be able to deploy really quickly, and so you get feedback really quick if your performance is going to be an issue.

I’ve had a project I’ve worked on in the past where we had reports from users saying ‘When we perform this action it is taken unacceptable at that time and we are not going to be able to use this tool because of it.’ and what we are able to do is go run a performance test which is exercise a particular punctuality that wasn’t working right, and then had it hit it 5,000 times in a second and see how long the response was, and we’re able to do a binary search for the problem. It was based off of replicating actual production environment. We knew exactly what was going on.

Non Functional Requirements

Clayton: Is there a place for non‑functional requirements where if you were a product interviewer you could say that ‘These actions should support this much thru‑put and this much latency’

Derek: I think that it’s totally OK to do constraints like that. I think that you have to realize if that is not your current customer standard you run the risk of doing a lot of waste. If you say ‘I’ve got this app that’s got a thousand users’ I’m going to make the constraints, but say that it’s going to do with two million concurrent users or I’m not going to accept the story. The truth is, if you don’t really have two million concurrent users on a regular bases, you’re probably wasting your time trying to write stories that have that as a constraint.

Clayton: Even if your constraint needs to be able to handle a thousand concurrent users and you’re a product owner, often times I’m hoping that most of the time the product owner is looking at the story before it goes into production. That means you have to write a performance test on every single feature that you write?

Derek: My thing would be that if you really had two million concurrent users on a regular bases you probably have testing frameworks in place to test that stuff already. You’re not having to go build all this…

[crosstalk]

Derek: I think the problem is when you’re going to release a feature right away and you have no idea how many people are going to use it, you go and spend all of the time doing performance testing, I think that’s foolish. I think when you hit performance constraints you start to build those tools and then you can continue to use those tools as your software evolves and as your base evolves.

Team Working Agreements

Clayton: Moving on to working agreements. This is something that can be very powerful to teams, but we had a situation recently where a team made a working agreement around how other teams interacted with them. Is that really fair to call that a working agreement?

Derek: I think it’s fair to make a working agreement on how that team reacts to other people interacting with them. For example, if I have a team that is constantly getting interrupted by… [crosstalk] …sure, and we had a problem where some of our team members will give in to it, and we’ll go and help them out, and hurt our sprint because of it, I could totally see us having a working agreement within the team saying ‘If we get interrupted, you need to bring it up with the entire team, you can’t just make the call on your own to go and spend the time helping that stake holder.’ The fact that it needs to be discussed with the entire team, I think that’s a totally fair working agreement. That would affect how you interact with outside people.

Roy: To me this is largely about how things are communicated. If the three of us are all on a team and we agree that we all don’t like interruptions, we want to do xyz, do little flags, or do something that we’re busy, and if somebody comes in‑ If we’re going about our work, we put our flag up, and somebody comes in, and I say ‘I’m sorry, we’re going to have to tell you in 15 minutes that we will deal with your problem, but right now we need to stay focused on this.’ then we have a working agreement. What we’re doing is signaling to somebody else ‘ We can’t help you right now’ and if they question it ‘ We’ve got this internal working agreement that we’ve agreed up on this’ that would be really great when the three of us say ‘We’re going to have a working agreement that works like this.’ and we’re going to send it out to everyone in the company and say ‘By the way, when you work with us, this is exactly what you’re going to do, and you’re going to like it. This is our new working agreement.’ Us collectively, that’s bullshit.

The reason it’s bullshit is because you didn’t ask of the other people that are coming to interrupt you to say that ‘When you interrupt us it really bothers us, and we would like to come up with a way to do that‑ how would it work best for you?’ I don’t think that the internal working agreement is a bad thing, but if you go out and you sell it as ‘This is how we’re now doing business, here’s the memo, read it, and abide by it by law.’ and then call it a shared working agreement among everybody, that’s bullshit. If you say ‘This is our working agreement that we’ve agreed upon, and we ask that you please respect that with us.’ I think that’s a little bit different.

Backlog Grooming

Clayton: Next up, back log gardening. Backlog grooming. Is this something that is avoided, or people don’t do enough and you do a certain workshop and generate a whole bunch of stories and you sit there and think you’re just going to work on them?

Derek: Grooming on backlog is done in the middle of planning, right? While you’re trying to give your team stories.

Clayton: Typically by the book, it’s more done before hand where you’re going through making sure things are prioritized, and…

Derek: So you’re saying you shouldn’t spend the first hand on planning or reorganizing everything.

Clayton: That’s probably a sign that you’re not doing any kind of gardening, right?

Roy: That means you’re Advil, if you do that.

Derek: That’s true.

Clayton: That’s right. At the drop of a hat, you can reorganize everything.

Roy: The reason I said gardening instead of grooming is, when I look at grooming, that’s cutting the hair, that’s picking the nits out of…the lice off of your head, et cetera. I think that that’s how most people view backlog grooming, which is most people have the problem of I’ve got an enormous amount of crap or features that I want to deliver, and most of my effort is trying to pull stuff out that they don’t really want to do or to get more details to clean up and prettify and get it ready.

But I think that a lot of organizations on existing products, they have a much different problem. Their problem is one of we don’t know what features to actually be adding. We don’t know how to talk to our customers.

We’re just adding crap that doesn’t matter, so what happens is this is like, “Oh, I’m not really sure,” it’s like, “Who called this last? What were they pissed off about? Let’s throw that into the product,” instead of actually saying, “Hmm, have we already plowed that field before, and is it going to fallow if we keep planting on it? What kind of vegetables do we think people are going to…”

If you take more of the gardener’s approach of, “Hey, let’s be strategic about what we’re planting and the cycles of it,” I think it’s a little bit deeper than just saying, “Hey, we’ve got more stuff in the backlog than we can see. Let’s trim the fat.” I think it’s about really doing…it is about trimming the fat, but it is also about what you’re planting, what you’re putting in, all of that tending to it. It’s hard work.

Clayton: Interesting. I think, from a perspective of…if it’s a new product, you obviously you’re going to have the problem of you buy up a bunch of stuff, and then you have to change things, like you said. I do like the idea of saying there are different cycles, different seasons. You might plant different things.

Is it maybe that it takes too long to sow the seeds for things to sprout before you realize them, and those are the things that get crushed in the garden? Some new feature the next person yells a lot, so you say, “Oh, we need to dig that stuff up,” even though it’s barely even got started.

Roy: I think some of it too is, if you look at maintenance, maintenance on existing products are like weeds. They start to choke out new growth. People get totally bogged down in the maintenance of things instead of being able to do things. But I think a lot of it is really hard work, and most product owners are not dedicated 100 percent, full‑time, to their project, or they’ve got other duties that they’ve got to do beyond that.

It’s very difficult for them to work with the team as well as work with the customer to do demands, as well as work with the business to say, financially, how are these things working.

So, usually, what we’ll see is somebody does one of those things really well ‑‑ either they work really fabulously with the teams, but they’re falling down on listening to customer demand or doing the business side, or they do really fabulously with the business, but the team hates their guts and they’re not listening to the customer, or they listen to the customer, but they don’t understand the financial decisions that they’re making, and they don’t get along with the team because they’re never present.

I think it’s very difficult to manage all three of those hats as a product owner, so, usually, whatever is my strong suit, I’m going to gravitate to it, and I’m going to throw the other ones by the wayside unless somebody forces me to deal with them.

Cross-functional Teams

Clayton: All right. Next step: cross‑functional teams. It seems like something that people started saying a while ago and that’s stuck, but I don’t know that everyone really agrees on this or knows what it really means.

Roy: I think that the question that most people have is, what does it mean? Some people, cross‑functional team means anybody on the team can do absolutely anything. Usually, the detractors that are against cross‑functional teams say, “Oh, that’s the fastest way to mediocrity. You can’t be a jack‑of‑all‑trades and master of none.

“You get a bunch of people that know everything, but they only know that at surface level, so you never get the awesome gain of the super specialized stud muffin of a team member.”

Derek: Those guys write the best code, by the way.

Clayton: Yeah.

Roy: I think more pragmatic viewpoints of what cross‑functional are, are the people are going to have things that they are better at than they’re not better at. If I’m on a team, it’s not seen as I can do absolutely everything at the same levels everybody else on the team.

But, if push came to shove, if we said we had to push this feature, I wouldn’t throw my hands up in the air and go, “Not my job. I don’t know how to do it. We have to wait for Stevie to come back in order to do it.” I might say, “This is going to take me 100 times longer than Stevie, but I’m full‑bore willing to get in.”

I think it’s a lot more about collective code ownership, and, if you took that beyond to product, its collective product ownership, is what I think you’re really saying when your cross‑functional team is we’re all contributors to this team, we all succeed or fail together. I don’t think it’s somebody can be better at database and somebody be better at design, or whatever. I think that that’s a trap that people fall into when they get too into cross‑functional.

Clayton: Yeah. I guess you don’t want silos, but you wouldn’t want to stump out the specialization. You would benefit from having someone who knows a lot about SQL, maybe, or your team, but you wouldn’t necessarily structure the work or the product in “these are the SQL stories.”

Roy: “I can’t do the work because I’m not the SQL guy.” I don’t think you’d want that. You’d say, “I’ll gladly take this story or this work, but I might go see Clayton, because he’s the SQL guy. This is really complex stuff, and I would really like to pair with him so that it’s faster and it’s done better and then we’re spreading the knowledge of how this stuff works.”

Clayton: I think collective code ownership is a big part of that, everyone having to share responsibility for the entire thing.

Derek: Right, and being able to deal with the full stack. You and I were talking about that yesterday. It was like debugging a problem that went all over to client to server to the database, involved everything. In the past, I don’t know how…because the team we were working with then used to be cross‑functional.

You used to have segregated responsibilities, so you have a SQL guy, a front‑end guy, a back‑end guy, and all of that. I can’t imagine how you would have solved this problem. You would have had to have all three people working together, which I know they didn’t do, so how would that problem have ever gotten solved? And that happens all the time.

Clayton: Very slowly. [laughs]

Roy: Yeah. I think we see this a lot in silo teams, where it’s like a problem comes in, it looks like it’s a visual problem, so the front‑end guy gets it. He pushes the pixels around a little bit and goes, “This is not a front‑end problem. This is a back‑end problem. I’m making all the right calls, doing all the right everything. The back‑end’s got to be the problem.”

When the back‑end guy gets it, he pushes some things around and says, “Oh yeah, they’re sending me the right thing, but then we’re sending it off to the database and the database thing.” So we call her up, and she says, “Nope. All the SQL things are handed back, but we handed to this other third‑party vendor, and they must be screwing up. “What happens is you get this chain, where this thing takes six weeks to deal with, because it’s going…

Clayton: Right. And it’s going to cascade back and forth. “I’ll fix it.” “I’ll fix it.” “I’ll fix it.” and all the way back.

Roy: Right. It ultimately goes to the whole cycle, and it’s really nobody’s fault. But, in reality, it’s a little bit of everybody’s fault, because…

Clayton: No one cares whose fault it is, right?

Roy: No, but it’s easy to bunch it up and say, “This isn’t my problem. Hand it to the next guy,” because it’s a really hard, complicated thing that’s hard to shoot, so it’s easier for me to go like, “Nope. I’m accepting the connections, so it’s not my fault. It’s somebody else’s fault.”

Then that person gets it and goes, “Yeah, but you have given me the wrong thing,” so you play the hot‑potato game, whereas, if you are a cross‑functional team, it’s like, “Hey, I’ve got to deal with this no matter what. We’re going to deal with it.”

Clayton: All right. That wraps it up for today. Thanks guys.

Roy: Thanks.

Derek: Bye‑bye.