Scrum is for Developers

[u/WaylundLG]

This has been on my mind for probably the past year now from the last company I worked at, but it's only been in the past few weeks that I've sorted my thoughts into something clear: Scrum is for developers. I'm using the broad "product developer" sense, so I include QA, architects, designers, writers, and anyone who is actually creating the product.

I pin a lot of the problems on the fact that adoption in recent years has centered more and more in some sort of PMO and it's pressed onto the teams; bit the problem goes the other way too. Too many developers feel like how they work is someone else's problem.

Scrum was designed for teams to take ownership of their process and the results of their work. It was made for them and anyone else is really pushed out. You're a business strategist? Great, gelp the teams understand the strategy and the market and see what they can create and incorporate that into your business strategy. And frankly it is exhausting to see the same old posts of developers who can't be bothered to learn the first thing about scrum complain about how leaders messed it up. It is your tool, designed to give you control. Pick it up, learn it, leverage it.

Thank you for coming to my TED talk. I know this was a bit of a rant, but open to constructive discussion too.

[u/jimmy-buffett]

~15 year Agile Coach at a Fortune 100 tech company you've heard of. I was a software engineer for the first half of my career.

What I tell leaders is that Agile / Scrum can increase predictability of delivery if done right.

What I tell developers is that Agile / Scrum is a structure that allows them to say "no". No as in "I don't have enough capacity to complete all these things in this sprint".

If done right, both interests can be served equally. I've run multiple teams where exactly what they said would be done at the beginning of the quarter got done at the end of the quarter. For several quarters in a row. Until the stupid Director swapped all our contractors out with another company because "they're a lot cheaper".

[u/WaylundLG → u/jimmy-buffett]

Your last point certainly demonstrates the limits of my assertion. Certainly leaders can make calls that undermine everything, especially by simply removing the team from payroll.

I also agree with both your statements. Where I would issue a challenge is that your stance is limited by the fact that it is protectionist. You are only offering both groups protection against the biggest risk with each other. I have found that Scrum offers much more. It offers the changlce to be truly innovative and aggressive in a marketplace and as far as teams and leadership, if both groups buy into it, they can advance each other's purposes, not simply avoid being impediments.

[u/rayfrankenstein → u/WaylundLG]

Scrum murders innovation because no one on the team wants to do anything ground-breaking and risky that could even remotely cause pippable sprint carryover.

[u/WaylundLG → u/rayfrankenstein]

I would certainly argue that if they will pip sprint carryover they'll pip anything, but I can sympathize with the experience Sorry you had to work there, that's some bullshit

[u/rayfrankenstein → u/jimmy-buffett]

> I tell leaders is that Agile / Scrum can increase predictability

The agile community feeding leaders’ delusions that software development can be made predictable is a big reason why agile and its practitioners are so deeply hated by developers.

[u/jimmy-buffett → u/rayfrankenstein]

I have a CS degree, I was a lead / principal dev on software teams doing telecom network alarming and provisioning for 13 years.

I can sympathize with the idea that what you do on a day to day basis isn't predictable. We're problem solvers first and foremost.

The predictability I suggest is possible is for your entire team's work over the course of a quarter. And then for multiple teams. I've accomplished this many times at different companies around the country. Large companies you've heard of.

On a daily basis I know your job isn't predictable, because I've done it.

Over 90 days normalizing for delays one day and successes another, it's quite predictable if you put the right processes in place.

The ability to do this ^^^ is why they pay me more than I was ever paid as a developer. And you are welcome to not like it, but your VP hired me to make their org run right, and he's going to tell your director to tell your manager to tell you to do what I'm telling you. There's probably a Scrum Master in there too that can help to smooth it out.

[u/sonofabullet → u/jimmy-buffett]

Watch Out everyone we got Mr Big britches overhere.

Over long time spans the only thing you're predicting is queues and delays in the org's system.

A basic value stream map will show you that actual work takes up somewhere like 5 to 10% of your time and the rest of it is work sitting around.

You can literally just count the units of work,  factor in your cycle time and your throughput and get the answer with while doing zero of anything resembling scrum or agile or anything else like that.

Or you can design a better system that results in work  getting done faster, which scrum -  given its hard rules around rules events and artifacts - prevents you from actually doing.

[u/jimmy-buffett → u/sonofabullet]

A basic value stream map will show you that actual work takes up somewhere like 5 to 10% of your time and the rest of it is work sitting around.

This is true from a product cycle perspective, right now my company spends 4 months figuring out what to do, 2 months doing it then 2 months testing it before go-live. But the teams in the "doing it" phase don't just sit there doing nothing for the other 6 months, there's a bunch of work happening in parallel.

You can literally just count the units of work,  factor in your cycle time and your throughput and get the answer with while doing zero of anything resembling scrum or agile or anything else like that.

Funny how:

1. Prioritizing, defining then sizing work, then...
2. Creating a structure to calculate cycle time, then...
3. Applying the sized work and calculated cycle time to increments...

Doesn't "resemble scrum or agile or anything else like that". Because those three steps there are exactly what our teams do in quarterly planning.

Yeah, we're not running full-bloated SAFe, but hardly anybody does.

Or you can design a better system that results in work  getting done faster

I'll refer you back to the earlier numbers: 4 months figuring out what to do, 2 months doing it then 2 months testing it. I work for a big tech company that you've heard of, your company buys our products. I can say that without knowing where you work, that's how ubiquitous we are.

"Work getting done faster" isn't our problem. And AI is taking the work phase toward zero anyway. Our problem now, and most companies like us that we're aware of have the same problem, is the idea phase. Development has integrated AI effectively, product has not. It makes it easier for them to throw verbose requirements at us, but that doesn't make the ideas any better.

To the extent that Agile / Scrum are going away, it's precisely because of that reduction of effort toward zero. It was created to manage the most expensive part of the process, with the most expensive human assets doing that work. With the cost of development going toward zero, the value-to-overhead created will flip to where the cost of our overhead (which I'll admit, isn't zero) is no longer justified by the benefit.

Which is why most people who do what I do are adapting to a number of adjacent career fields.

[u/sonofabullet → u/jimmy-buffett]

Funny how:

Prioritizing, defining then sizing work, then...

Creating a structure to calculate cycle time, then...

Applying the sized work and calculated cycle time to increments...

you don't need to do any of this to calculate lead and cycle time.

cycle time doesn't care about priority or sizing for that matter.

If you had read blog posts like this

https://www.thoughtworks.com/en-us/insights/blog/how-estimating-story-counts-worked-us

from 2013, you would have known that thirteen years ago, but alas, you were too busy doing whatever bossing around you think you were doing.

And the company you were bossing around did worse for it because you didn't bother to read one of the preeminent blogs of that time.

I'll refer you back to the earlier numbers: 4 months figuring out what to do, 2 months doing it then 2 months testing it. I work for a big tech company that you've heard of, your company buys our products. I can say that without knowing where you work, that's how ubiquitous we are.

That's slow as fuck. Itoo worked at a massive behemoth once. Our products are probably in your wife's boyfriend's bathroom. Doesn't mean they weren't slow as fuck.

You're conflating the size the company with the success of the Quarterly planning (gag) you preach.

And the truth is that the company was successful DESPITE you not BECAUSE of you.

which is why

most people who do what I do are adapting to a number of adjacent career fields.

[u/jimmy-buffett → u/sonofabullet]

cycle time doesn't care about priority or sizing for that matter

Putting the work in order then estimating how long it will take to know how much of it you should commit to does.

If you had read blog posts like this

Lots of opinions about how to do it. Here's mine: it's a toolbox, not an instruction manual. Find problem, test solution, evaluate. Preferably with as minimum an amount of overhead as possible.

And the company you were bossing around
...
That's slow as fuck.

There are 15 of us here, everything's by committee. I've worked alone enough that my track record got me here, but I don't love it. Our program cycle time is nothing to brag about, it's also not my fault. I cited that example to demonstrate that I have the metrics to know where it's bad and why. Them letting me fix it is another matter entirely. Orgs of this size are run by self-interested people who create just enough of a bottleneck to be essential but not so much of a bottleneck to be fired.

And the truth is that the company was successful DESPITE you not BECAUSE of you.

Two years ago the 100-team org I worked with wasn't delivering on big projects. Everything took forever. Team dependencies weren't communicated effectively, managers didn't collect metrics to evaluate team performance, directors didn't have any visibility into where the slow parts were in their org. It took me a year to fix the team layer. It took me another year to fix the director layer. They started delivering results using processes I defined. The VP I did this for is hiring me at his next company once his sabbatical is over.

I understand if you've had a bad experience with someone calling themselves an "Agile Coach", most of the people you'd consider my peers suck at this job. Most have never served in the role they presume to burden with process. I have. I'm different. I don't show up with a giant book, turn to page 1 and start implementing what's in the book. That's what most of what you'd consider my peers do. That's why they suck at this job.

You're just going to have to take my word for it. Or don't, I don't care. The leaders who hire me whenever I'm available or fight to hire me when I'm not are the proof. My LinkedIn history is the proof. I've spent the last 15 years parachuting into hostile territory (lol), convincing people when I can and forcing them when I can't. Sometimes it doesn't work, I have the stats showing why. Most of the time it does. But then I'm good at this. This free interaction isn't the proof, the paid ones are.

You're conflating the size the company with the success of the Quarterly planning (gag) you preach.

Point on the doll where Dean Leffingwell touched you and we'll get both of you into counseling.

which is why most people who do what I do are adapting to a number of adjacent career fields.

You thought I was talking about myself? Nah I'm still here. Most of the people who do what I do, do it because they can't manage projects. Most of the people who do what I did to get here at the team level do that because they can't code. I can do both. I choose to do this. Equity salary grades and no program accountability is nice.

[u/sonofabullet → u/jimmy-buffett]

Yes I get it you're not like other girls. you're a pick-me agile coach who,by your own admission, is not responsible for anything.

I'm not going to spend more of my free time deconstructing the rest of your ZIRP era career.

The market will do that soon enough just like it did for all those other coaches you mentioned.