When process kills progress - a story about Scrum

Hello and welcome back to the video. I'm your host, John Fontaine. And on today's episode we're gonna talk about proof. I'm usually product. So when things aren't going to be able to do that. But I think it's a very good thing. Business and in tech, we've overindexed on process. I remember working in a You know, partnership management role early in my career. And I worked for a company that was very big on Lean Six Sigma and optimizing processes.

And it always struck me as weird because I always wondered like what if you're optimizing the wrong process? What if what if there's a fundamental flaw in the process to begin with, should you be optimizing it? Right? I if the total maximum output at Six Sigma is You know, ninety, but a different process would give you a thousand.

Then why would you optimize to ninety when the other process unoptimized could probably get you like five or six hundred, right? And so it it never made a ton of sense to me. to over index on process because it It presupposes you have the right process to begin with. And I'll give you an example from a recent employment experience that I had. where the organization was very, very process driven. Like many, many meetings a week about process across the organization for different purposes.

It was a lot.

But in terms of product development, the engineering org was very focused on scrum. They were scrum disciples, man, I tell ya. And just like people that, you know, are are strong Marty Kagan disciples or agile or whatever, you know, this this company was, you know, scrum to the hilt. And so I went with it. I'd never worked in a pure scrum shop before that was very dogmatic about scrum.

So I thought it'd be an interesting experience. There were things that they did that I, you know, would hear and see people talking about online that I had never experienced. And so like, oh, okay, cool. I'll I'll get to experience what this is like. And I I tried to come in with an open mind. Even though there was a little bit of interesting uh conversation in the the recruitment and hiring process. But going in with an open mine.

I w I wanted to see how this played out in practice without me trying to change the process from the beginning. Trying not to throw the baby out with the bathwater, right? But as we got going, we had this major acquisition that the company made to bring a certain product offering to market that would integrate with our core systems, our core ERP, right? It's kind of a legacy business.

in a legacy industry. And as we got going, we had this looming deadline to get this integration done with this this platform. And I kept noticing a trend in our our sprints, right? We we had, you know, rigid two week sprints and again it was very by the book scrum. Where if a sprint started you couldn't add new work to it. If a sprint didn't or if a ticket didn't have an estimate or a story point, it couldn't be included in the sprint. Like it was very by the book.

And so I noticed this interesting trend where we were starting to fall behind on our timelines and our our pace and our velocity. Because we were in new territory. We were doing an integration with a system that was new to the business. Right. There was inherently a lot of unknown. So we would have many sprints that would have research tasks that we needed to accomplish.

and and finished to be in a position to estimate the actual work that needed to be done. But since we couldn't estimate the work that needed to be done, we'd kick it to the next sprint until the research was done. Which on on its face sounds okay, but when you have a tight deadline and it may only take you a day or two to do the research before you can do the work.

A sprint is two weeks long. If you spend the first two days doing research, you have many days where you could actually be doing the work versus arbitrarily waiting until the next sprint starts. And so I I I I was concerned, so I brought it up at a leadership meeting that I I thought we were falling behind, we were at risk of hitting our timelines, and the reason for it was because we were too rigidly following Scrum.

And I think the the initial reaction was a little bit of a gasp, like, oh no, the process is great. But as I began to articulate what was happening and the process of how it was playing out in practice, I think common sense prevailed. And it did. There was a realization that no, the most important work needs to be done first.

So, you know, w we kind of reconfigured the process to where we were still quote unquote following Scrum, but we were able to pull in um tickets into the sprint after the research was done and and reprioritized kind of on the fly, which to me speaks to being more agile than, you know, the rigid if it didn't make it in time it's not getting in kind of kind of mentality.

So I was fortunate that we had a leadership team that was open to listening and hearing me out. on why the process was failing us. But not everyone's so lucky. And so if you're one of those leaders Who are listening and you follow a very rigid process and someone comes to you and can clearly articulate a problem with the process, hear them out. You might You might have an opportunity to educate them. Maybe they misunderstood the process. Maybe they're following it incorrectly.

Um, you know, but if if you hear them out, you might actually learn that there is something flawed in the process or there's a situation that's unique that doesn't allow the process to work the way it was intended. And if you're somebody who's stuck in a process where you feel like it's not working, go at it with an open mind. Try to execute it to the best of your ability under the current paradigm that you're stuck with.

And if you still can't make it work, document what's happening and go humbly to your leadership and just explain to them, we are trying to do this, and this is the negative outcomes that we're facing because of it. What can we do to fix this? Or go with a recommendation. I think if we did it this way,

it would work better, right? But go with an open open mind into it. And if it's not working and you can't get it to work, document what's happening and then share it. And I think the rest of your organization will be better for it. So I I hope this lesson in product management is helpful for you. Um I know it was helpful for me, kind of going into a first-time environment where running a different type of agile product.

And fortunately, I think I handled it pretty well, and the outcome was pretty positive. So I hope I hope the same for you if if this resonates and you're kind of. a suboptimal situation. I hope this advice and this this story and this lesson will benefit you. So thanks for joining me today and I'll see you next time in another lesson in product management.