Stop Doing “Agile” and Start Being Agile

A couple of weeks ago, I had a chance to speak with Lauri Hofherr, Head of Product at Oranj. Lauri is a former agile coach and uses her knowledge daily to improve product delivery and accountability at Oranj. My goal in talking to her was to understand why companies have such a hard time being agile and learn what they could do to improve. Speaking with her gave me a look into the mind of someone who lives and breathes agile, and I hope you get as much out of reading this interview as I did from giving it.

NOTE: This conversation has been edited for conciseness and clarity.

Oleg: First thing I wanted to ask about has nothing to do with product management. It’s the Chicago Product Management Association so I have to ask Chicago-related questions.

Lauri: Sure.

O: So first one: Cubs or White Sox?

L: Whoever is playing.

O: Perfect answer, you didn’t alienate half of our potential readership.

L: *Laughs*

O: Next Question: New York-style pizza or Chicago-style pizza?

L: Oh my god, Chicago for sure.

O: Alright. That’s the right answer. Thoughts on ketchup on a hot dog?

L: What?!

O: Yes.

L: No no no no. That is so wrong on so many levels. It’s almost like, I don’t know, I don’t even know what the equivalent is. It’s like mayonnaise on pizza. Who does that? Actually, the English do.

O: That doesn’t sound that bad, actually…

Alright, now that we’re all warmed up, let’s get to the meat of things. How does an idea go from inception to production here at Oranj? What’s the process that you follow?

L: Usually we’re trying to solve a problem — that’s what product managers do. “Oh! Give me a nice juicy problem to pull apart and I can fix it.” But when you’re talking about a product it can be coming from any number of places. It can be an operational issue, it can be a business issue. It can even be a technical issue. We run into those all the time.

O: Of course.

L: The idea is there’s a hypothesis and we have to prove it out. Usually if we decide we’re going to do something, what happens is I will start the process of making sure that we completely understand the business case, the general direction of what we’re trying to accomplish from a technical implementation perspective, and then also start the design process as well — I like to at least have sketches.

For instance, we’re doing this big integration, so I looked everywhere for videos of the app we’re going to integrate with, and came up with conceptually how we’re going to integrate with them. Then we had a lunch-and-learn, and I talked about the business case for why we’re doing this — all the pros and cons, what I can find from other companies that have done integrations. Then we looked into their product and talked about what it’s gonna look like for our clients to be jumping from our application to the other application — the user experience around that. This drove questions like: Are we really ready for this? What do we want to change in our app to make this a seamless interaction?

Once everyone understands the overall initiative, the team does an inception meeting where it is much more grounded in details of the actual integration, the actual design work, the actual user experience.

O: You mentioned hypothesis testing. What I’ve seen is that a lot of companies and a lot of people start coming up with solutions way too early, before they’ve validated that it’s a problem that they can even solve, or that it’s a problem that’s even worth solving.

L: Well, usually when you don’t do the due diligence up front, you end up having to do some sort of a pivot or change later, and it’s usually very expensive, very painful, and very embarrassing. I’ve been embarrassed enough in my life by going, “That’s a great idea!” and then realizing that it was not such a great idea.

O: What do you do to validate your hypotheses?

L: There’s a couple ways. One is, you can try to talk to your clients. That’s ideal but sometimes that’s not the easiest thing to do, so sometimes it can be just socializing the idea with your team. You go to a whiteboard to talk about it. I actually had a great idea just yesterday. I was talking about it when George, one of our product managers, goes, “Well why would we do that?” and tells me his idea. And I realized, “Yeah, his idea is probably the simplest thing possible”. The question is not only, “Is this a good idea, and does it makes sense from a user’s perspective?” but, “Is this truly the simplest thing?” because you still want to get it out there as soon as possible with the least amount of invested effort for customer feedback.

O: In that process, what’s your method of documenting? Do you do less documentation because everyone’s involved?

L: I’m a big believer of communication over documentation but communication includes documentation. My theory on documentation is that you do whatever you need to suit your purpose. If your purpose is to socialize and get buy-in on something, that’s completely different from trying to do technical documentation. You can start with a wiki page, and edit it, and that can be kind of your strawman; throw it out there. But it has to describe, “Here’s what we wanna do, here’s the options we looked at, here’s the pros and cons of each, and if we were to implement it, these are the kinds of things we’d have to think about.”

O: So when you say, “strawman” in this context, can you elaborate on that?

L: This is the initial documentation of a proposed solution to the problem so others can react to it — positively or negatively. It’s a way to engage your team, get the collaboration started. Again, your idea is still a hypothesis until you get out in front of users and can actually prove it. Only when you’ve actually proven it has solved the problem you’re trying to address, is it actually then a great idea.

O: Are you saying that before you do any development, you make sure to get user feedback?

L: No. Not necessarily users, because that is a very tricky thing to do unless you’re a huge company that can burn through a few thousand people and get some feedback. We don’t have that luxury. Our user base is smaller, and we have to be very careful about how and when we go to that pool. Our initial source of feedback is internal stakeholders, you know, “the friendlies.” We actually get a lot of opinions from our development team and from our client facing folks. They have a lot of experience with this stuff. I think I know something, but usually I put something in front of them and get really valuable feedback.

Everybody loves to say, “well, just ask your users.” There’s a cost to asking your users, and it’s not just the money and time and effort to do it. It’s also, how often can you go and ask your users before they’re like, “I don’t care what you do, just quit asking questions.”

O: It affects your reputation. You’re asking so many questions, and they start wondering whether you actually know what you’re doing.

L. Yes. “Stop asking me how much I like your app.” That’s kind of the problem with some of the mindless customer satisfaction programs that are run. Everyone just gets sick of them. Nobody pays any attention to them anymore.

O: So, OK. You had a hypothesis, you’ve proven it out as much as you can before you actually develop it. How does your development process work?

L: So, we start with the kickoff, we do inception. We actually follow the model of the guild. So we have a back-end guild and we have a front-end guild. Are you familiar with guilds?

O: I’m actually not familiar with them.

L: So the guild thing, it’s an internal group of individuals from all disciplines who get together, much like a meetup, and the idea is, “Hey, let’s establish best practices. Let’s talk about big decisions. If there’s something new to learn, let’s share that knowledge.” Sometimes we do code reviews at these things. Sometimes we’re doing infrastructure reviews. We’re small enough that we don’t have a formal operational readiness program but our guilds act as that kind of check on initiatives. The guild meets and we say,, “let’s talk about this, let’s make sure we’re all in agreement that this is what we should do.” The CTO is involved in those decisions. But that’s not for everything, that’s only for big initiatives. Sometimes we just kick off a new feature and just talk about what it is. We deliberately talk about what the handoffs are, what the integration points are, what’s the testing strategy. We’re really trying to think about the entire software development process while we’re doing this.

O: What does development look like from a day-to-day perspective? How do your product managers interact with your developers?

L: I think probably the best way to answer it is, we are very much a small squads operation, three to four developers — four is optimal, half a QA, a little bit of design. We share the other resources as best as possible so the teams are very much self-contained, and the product manager can be the scrum master — it’s just a role and anyone can do it. We have one week sprints, planning meetings are a half hour, backlog grooming is a half hour, daily stand-ups are 5 to 10 minutes. We’re very good so it’s very close, and it doesn’t require heavy administration of the process. If the product manager is sitting right next to the developers, and they hear them talking — they’re questioning, they’re not understanding — they can immediately turn around and go, “oh my gosh, let me help you out here.” So you can see *gestures to the working area in front of us*, there’s lots of activity going on here. We don’t hesitate to get up and to talk to one another. If we see something that’s lagging it’s like, “what’s going on there? How do we help you?” Swarm on it. We do a lot of that, especially getting closer to the end of the week. At the end of the sprint, let’s say, we got three things that never got picked up, that’s fine. Everyone swarms on what’s out there right now. The teams also run their own tests.

O: And you push to production weekly?

L: Yeah.

O: Do you ever decide not to push a given week because of the amount of bugs you have? Do you ever just say, “Wait a minute. We can’t push this to production”?

L: The bus is gonna leave the station, and if something’s not ready to go, we don’t take it on-board. But the product managers and the development teams are having those conversations the whole time, especially as they get towards the end of a sprint. There are some things that developers try to push through like, “I’m almost done, it’s in review.” and we’re 2 hours away from cutting the release branch, and the PM needs to say, “Yeah, no, that’s not going. Forget it. I want more testing on that. I know you feel good about your code but I want to make sure that we get all the right testing done.” It’s that tension between product and dev, and how you manage it. That’s the methodology piece of it.

O: Speaking of methodology, someone who’s new to or been poorly introduced to the idea of being agile might scoff at that and say, “We’re agile, and we might even be more agile than you. We’re so fast that we’re just building things on the fly. We push to production every two to three days, sometimes even quicker. We’re pushing new features so fast that we often don’t even estimate! And because we’re always pushing to production — quality code over documentation — that’s one of the things in the agile manifesto — we are super agile.” What would you say to someone who thinks this sort of ad hoc lack of process is really in the spirit of agile. How would you respond to that kind of thinking?

L: Well I would say, “How do you know that you’re doing the best you can?” If you’re not doing storypointing, for example, then how do you know if week over week you’re delivering a consistent amount of code or consistent value to the business? Because that’s what it’s all about. The whole reason Waterfall developed is because the business didn’t understand what value was being delivered. “I don’t know what you’re doing. I’m shelling out all this money. What are you actually delivering to me?” So there was this war and arms race of documentation and commitment that just became so big. If you do it that way like, “we’re always pushing,” at some point someone is gonna go, “Yeah, but why? What are you pushing into production, and how do you give me any sort of assurances on what you are delivering and that you are providing consistent value for what we’re paying?”

O: That person would likely respond with, “Well yeah, but agile isn’t about accountability. Accountability slows things down. Agile is about developing quickly.”

L: Well that’s bullshit. It is all about accountability. I’ve never been at any company that didn’t always look to push on technology budgets, sometimes by looking for ways of achieving the value without building it all out. People who don’t think that those kinds of conversations are happening on a regular basis aren’t close enough to the business.

O: So do you think that one of the remedies to making people like understand that ad hoc is destructive is to expose them to the business aspect of it?

L: Yeah, why not?

O: Well there is an aversion in a lot of companies to expose the developers to the business. I’ve heard this more times than I can count, “The developers don’t need to know why. They just need to know what to do, and that’s it.”

L: Until things go wrong, and then it’s the developers with the smoking gun in their hands. Agile was created by developers for developers because of that smoking gun problem. If you can’t explain why things haven’t been delivered, or you can’t explain why things are broken, or you can’t explain how your technology is being applied in solving a business problem, then you’ve got a smoking gun in your hand. Anyone who understands shareholder value knows that if the shareholder is not getting more by investing in your company than they could by doing something else with that money, then you’re destroying shareholder value, and that’s always the CEO’s main focus.

O: That makes sense. It’s the problem of people who are just unfamiliar with it not realizing that you can be fast, but you’re not necessarily useful. On the opposite end of the spectrum, there are a lot of companies that I’m sure you’ve dealt with that go through the motions of things that are considered agile and then they say, “well, um, agile — ”

L: “Doesn’t work”

O: Yep. How do you, one, show them what’s not working right for them and that it has nothing to do with being agile? How do you get them moving in the right direction? What is some advice you can give them? They’re trying to go through the motions, it isn’t working for them, and they say, “I’m open to hear how we can improve this.”

L: Usually it’s because there’s a partial commitment. The ones where they go through the motions and they try to do all the right things, what they’re doing is they’re padding agile with a whole lot of bureaucracy and a whole lot of process, and a number of people need to be involved in it. If you look at true agile teams, they’re slim; an agile team will not carry dead weight easily. It just doesn’t happen. So if you aren’t getting there, look at the dead weight. If your stand-ups are a report to a project manager who is ticking things off, that’s not a stand-up. In fact, those people shouldn’t be there if that’s what’s happening. A stand-up is for developers to touch base with one another and to report on what they’re doing so other developers can hear what they’re doing. “Wait, you’re doing this, I’m doing that, let’s make sure we’re talking, let’s make sure this happens.” The nature of development is to be heads down and it can be very isolating. The stand up is to force everyone to communicate as a very quick touch-base. If you are doing this for a product manager or a project manager or scrum master, then that’s not a stand-up. Why bother? That’s stupid. Then you’re feeding the beast which is the JIRA. You’re just checking marks in JIRA.

O: I like that. “Feeding the beast”.

L: Somebody is getting rewarded for making sure you have a stand-up, rather than developers understanding the value of them hearing each other, and the value is them being able to head off any problems and any unforeseen or unintended consequences. That’s what stand-ups are all about. These companies that are doing this, they’re going through the motions but they’re not really understanding the intent of it.

O: So what could companies do to move away from, like you said, padding agile with that extra bureaucracy and process?

L: They have to trust. There’s control and there’s trust. You can’t have both. So if you don’t trust your development teams and product and if you don’t trust the process, regardless of what that process is, then what are you going to do? You’re gonna request reports, you’re gonna request statuses, you’re gonna request to be present, you’re gonna request documentation, you’re gonna request all kinds of things. Meetings, meetings, meetings, right?

O: You should only have as much process as you need to get the end result.

L: Which is teeny. It should be very small, and the more agile a team is, the less process they actually need. I’ve been on teams where the stand-up was really simple. Our planning meetings were quick and short, and for the most part; things just start percolating along. At the very beginning, maybe you don’t have that kind of second-brainness with each other, but true agile teams have even less process than you would think.

O: For teams that are trying to get there, how can they measure their progress towards agility? What things, if you had to give a head of product at a different company, or a CEO some advice and they said, “look we’re trying. We wanna be agile, we wanna deliver code faster, we wanna deliver value faster. I have a good team, I have no reason not to trust them. How do I know that I’m moving in the right direction? How do I know that I’m moving there and not having this false sense of confidence that I’m being agile because we have these processes in place?”

L: Is there satisfaction? Are you feeling as if the team is reacting appropriately? Are they engaged? Like I said, over here you can see everyone’s engaged. There’s no one who’s not working at full tilt while we’re here, and that is because that’s the environment that we’ve created for ourselves. This is our choice. We want to have this. I used to be an agile coach, and I used to get questions like, “What would you do in order to make our teams more agile?” and I’d be like, “Well I don’t know, what’s going on with your team? What do they need to do to become more agile?” It is very personal to the team, and there’s no one set formula. Sometimes it’s that they do need to get more strict with the actual artifacts and ceremonies and maybe they need to get strict with it until it becomes something that they can short-hand for themselves. It’s not about imposing agility from the outside in, it’s by developers for developers, and it has to be that way. They have to embrace this, and they’ll embrace it once they see that it helps protect them from this, “Well you’re not working hard enough. You’re not delivering what you said you would deliver. What are you doing all day? You playing video games?” Don’t you love that, I don’t know if you’ve ever heard that one. “Always watching YouTube!” Back to your question, though, the answer is that agile as a software development methodology has to be embraced by the developers. Because if it’s not, it won’t work. And you can throw as many scrum masters as you want at it, that’s not gonna get it to work.

O: So your advice for any agile evangelizers is to get buy-in at every level of the organization and to really understand what it is they’re trying to get everyone to buy-in to.

L: It’s supposed to be a better way of developing software by better addressing the risks. Risk one, business priorities are gonna change and by the time you’re done, you’ve missed the mark and nobody cares. Number two is all the unknowns that creep in, especially when bringing a whole bunch of pieces together into a coherent whole.

Speaking a bit more broadly, time is a multiplier of risk. It’s easy to understand this in terms of interest rates and mortgage loans. The 30-year is gonna be more expensive than the 15-year. Why? Because there’s less certainty 30 years from now than there is 15 years from now. So in software, if we can reduce the time between our cycles of going “Hey are we alright, have we done good? Hey have we done good?” Then we reduce our risk of getting off track.

Everyone knows about the developer who digs a rabbit hole. That’s hugely expensive and can be very destructive to what you’re trying to do. If you’re checking in every day, you can see that rabbit hole’s getting dug and go “Hey, come back here!” How about those developers that go, “We’re gonna rewrite this whole thing! ’Cause I started refactoring and now it’s 3 days later and I haven’t delivered my story, but I refactored!”

O: *Laughs*

L: So how do you mitigate that? Well how about you touch base every day? How about you shorten the cycle of when you say what you’re gonna do to when you deliver? That’s what everyone has to buy into.

O: So we have a couple more minutes. The last thing I wanted to ask you is, where did you learn your agile knowledge from?

L: Well, it was from some folks that were early early agile adopters and in fact founders of this kind of thing because they were so fed up with the Waterfall. I had experience being on the other side of it, trying to be a business person in charge of technology projects and I was completely frustrated by it. What I hated more than anything was the animosity between development and the business. It was so not me. I’m kind of a friendly person and I didn’t like it.

O: You are definitely a friendly person.

L: Also, agile really appealed to me because at the same time I had just bought a four-flat in Bucktown, and I’m doing a gut rehab, but because I have no money, I’m living in it at the same time. The way I looked at it when I heard about agile software development, I’m like, “Oh my god, that’s how I’m doing my house.” I’m doing this one piece of it because it’s foundational and I have to get it out of the way. If I don’t do it now, I can’t do it later. What can I do now because I only have so much time? What’s my next project? What’s the one after that? I literally did rehab agile and it is completely relatable back to developing software.

O: So that’s all the questions I really had. Are there any last words you want to say on the topic?

L: Nope

O: Thanks for your time!

L: Thank you.

Lauri’s LinkedIn profile can be found here, and she’s a frequent attendee of ChiPMA meetings.

If you liked this article and wanted to be notified whenever we post something new, follow the Chicago Product Management Association Publication.