Fixing Scrum (2019)
riskfirst.org
riskfirst.org
> If the thesis that “90% of everything is waste” then Planning Poker is also a waste, and we should devise a planning process to avoid this.
> In the next article we’ll look at how we might do that.
Cost estimates only are valuable if a) the amount of time involved is relatively large, b) you expect to learn nothing during that time, and c) the expected-value estimates are precise enough that you can calculate a narrow ROI range.
Instead, the way I prefer to work is with continuous delivery and small units of work. If you are releasing daily or more often in a context where you can learn a lot via experiments and user tests, then estimates cease to be valuable.
Another way to look at this is in terms of push systems versus pull systems. Scrum was made for push systems, where executives push large idea lumps through a plan/design/build/release process. In that world, estimates are valuable, if only because executives like to appear in control and need signals to tell them when to yell at people.
But in a pull system, you have small, cross-functional teams observing user behavior, developing problem and solution hypotheses. There, delivery is used mainly to test hypotheses, which are then revised based on new data. In this context, batch estimates are generally wasteful because new data and new hypotheses change the basis for estimation too often. There's rarely sense in estimating a month of work when every day you're learning things that change what you'll do and how you do it.
This article focuses on the Timebox issue. I'll be posting the follow up in a couple of weeks, will post on HN... although there's plenty of other content on this site that covers where I'll be going with that solution.
Apologies if it didn't cover everything you wanted - but I find that long articles tend to lose the readers too easily, and I'm trying to keep to a single main point-per-article in my writing as a matter of discipline.
I'll look forward to your thoughts on the next one.
I tried to read it, but "page does not exist".
----
Edit for clarification: First link in first paragraph after "10X" section header. About "visited the terrain before".
"But actually, we’re now three degrees away from the original problem of trying to build the right thing. The team is focused on figuring out how much they can get done in a Sprint, not whether they are building the right thing. Scrum purists might argue that this is the purpose of the Sprint Goal, which should be agreed in advance.. but actually this is usually just a bunch of items from the backlog, shoe-horned into a sprint-sized chunk of time."
However, I am pleased that people seem to agree with this article's diagnosis of the problem.
The next article will build upon this one (and others in the series). Hopefully it will be equally well considered on HN, I am interested to see how it goes down.
They have something in common:
- Full-time software engineering managers? 0%
- Full-time product managers? 0%
- Full-time project managers? 0%
- Committed engineers focusing in implementation working on flexible time schedules: 100%
The true inefficiencies that managers spend their careers looking for, are right there in front of the mirror.
Some open source projects are sponsored or backed by foundations, and contributors do get paid.
Here are my stand up updates: I worked on the same shit as yesterday mostly, I’ll let whoever needs to know something know something. No roadblocks.
Jira seems to help stakeholders and product owners conceptualize the work and timelines but I see zero productivity gains from continuously evaluating and tweaking Jira.
Developers just want to know what they're supposed to be working on. Managerial types want to know what people are working on, when things will be done, and goodness knows what else. You obviously need to give developers the room and time to get actual development done. But at the same time, unless you work for a truly tiny company, there's always going to be some level of crap reporting that feels useless to most developers, but is important to someone else.
It's hard to strike a balance that works for everyone.
a previous team i was on used github issues with a labeling system then switched to jira when we wanted to "get serious". my est is that we had a 50% decrease in issue quality and it shifted from 50% -> 90% of issues written by PMs and managers vs ICs who had a finer grained understanding of high leverage (impact/effort) tasks. i really do blame 1) the shittyness (er... "complexity", er... "power") of the UI and 2) the strict sprint-gaming behavior it encourages. i love a strong PM/EM for directing the team towards business value, but less so for enumerating and prioritizing the micro-tactics to get there.
edit/disclaimer: i admit i'm super biased, but i've thought about this a lot working on a competitor of sorts.
Source: I am a developer like you that has the exact same instinctual attitude about it. Here is why it's wrong.
Project managers need to build schedules so they could coordinate dependent features across multiple teams.
Marketing needs to orchestrate launch announcements and fixed activities that are not quite as inflexible as printing millions of CD-ROMs, but still require dates.
And managers, ultimately, are held responsible for a project delivery, so they need to track it's progress, understand what things are ahead (lol) or behind (yup), which areas need help from more people, more seniority, or less scope.
All of this needs to come together for any successful project of any reasonable complexity.
None of this is new, or news to you, of course. Here's the part you're missing: The way things USED to work was that PMs, Marketing, Sales, and Managers would come up with processes that worked for them, and forced it on development teams, regardless of how it made the devs feel.
Agile was an attempt for the developers to take ownership of their process bottoms-up. Planning poker, standups, sprints, all these ideas were invented by developers to make their lives EASIER not harder. And none of it was supposed to be panacea - the only way to do things. Each team is supposed to figure out the right balance of what works for them.
So don't be apathetic. You are an active contributor to this process. Take pride in the fact that you have a lot of autonomy about how to define your project structure in an agile environment. Change what you don't like, and figure out what works the best for your team.*
* Giant fucking asterix: I understand plenty of companies are extremely top-down and inflexible about "AGILE" development processes. They paid some consultants millions of dollars to define a process, and they're going to force their development teams to follow it regardless of what the front line devs want. If that is what is happening at your org, I'm sorry, that is truly unfortunate. But by and large, I find that even at companies where the devs have plenty of autonomy to define their process, they still grump about the very idea of having be forced to provide status updates or work in atomic chunks of effort and keep their software constantly releasable.
If you want to know more about the why of the standup, and what is the idea behind it, read Borland's tell: https://www.scruminc.com/origins-daily-standup/
Ever heard of a "morning sales meeting"? They've existed for decades - short, to the point, 15-20 min. No one's ever heard of scrum in sales meetings. This kind of thing exists in hundreds of other businesses as well.
Much like everything else in scrum, they are just trying to take credit for something people already did - so they can package it and sell it back to people as if it were a novel idea.
There's nothing new or special about scrum - except a reduction in productivity because of the additional overhead and meetings.
Also, it's for "our own good" and "we should own the process ourselves". While saner interpretations of AM are to be strictly verboten.
Only time I've seen such meetings not devolve into a status meeting, is when PM actively sought to cast light on potential issues and inquired about who need information, etc. This was effectively rooted out when SAFe came and eliminated PM-role entirely, while hiding discovery and decisionmaking processes, keeping them secret.
Of course, past poster child examples have nothing to do with Attention- and Selection bias either.
I can’t play this semantics game. I don’t care how you want to measure it.
Business: But now we know where the spikes come from
Gotta be smart about this devs, this ain’t rigged to your favor. Truck along, give your points and user stories, but if you want to be measured on a bullshit scale it’s at your own folly. Game it.
Planning poker is useful for exposing different interpretations of a task from the perspective of multiple developers while trying to avoid group pressure or prejudiced outcomes. Spikes are tools that allow developers to explore a problem space and gain information about whether a proposed approach to a bigger problem is feasible and how much work might be involved. And story points are there to help the development team understand how much work they are able to get through in a period of time, to help improve estimates or targets that are useful for themselves and other parts of the business.
I'm really sorry if you've had a bad time with this stuff, but none of it is unreasonable or particularly outlandish – and personally everything you've highlighted has been extremely useful to me as a developer. Like all tools they can be abused; the problem there is a broken organisation, and not a broken tool.
Most likely the new dev will lie under pressure and give a lower estimate. This is what really happens in real life. These mechanisms are so unrealistic. It’s ritual at this point.
Typically you'll either find some rats nest of complexity that the low-pointers hadn't thought about/didn't know about: result? Go with the high estimate and the low pointers learn something. Or, you'll find that the high-pointer assumed something was in-scope that isn't: result? Go with the lower estimate and tighten up the story spec with some non-goals and maybe a link to pre-existing done-work.
I've seen the version you describe, but only in dysfunctional companies. There's no helping those people but Scrum isn't the problem per se.
In the situation you describe, there are three possibilities: either the new dev makes a reasonable estimate and everybody else is wrong; the new dev is overestimating and more experienced devs are able to see that; or the new dev is not yet familiar with the point scale in use.
In the first case, great! We expose some hidden complexity in a system that might be taken for granted by the existing developers, and this helps refine an estimate for the new team structure. In the second and more likely case, we can respond by tightening up the scope and specification of a task to make it clear what is in and out of scope. And in the third, we can work to make sure the new team member gets a feel for the sizing system in use, which tends to take a little bit of time when changing team makeup.
These are not rituals and they are not unrealistic. They are specific tools aimed at solving real problems. It’s no surprise you have a bad experience if you are this aggressively dismissive of them.
Cost-benefit analysis scenario:
Request: We need to know how long it will take to build X so we can decide if we want to build it.
Response: What is the maximum amount of time to build X, such that if it took any longer, you wouldn't have us build it?
Rationale: Estimating whether a project will be over/under a time given frame is more likely to be accurate than estimating a specific span of time.
Dependencies scenario:
Request: We need to know how long it will take to build X because marketing needs to know when to start preparing.
Response: What is the amount of time marketing needs to prepare?
Rationale: Estimating that development is some amount of time away from completing is more likely to be accurate than estimating the entire project.
----
Underlying most arguments for estimates from development is an unwillingness by those doing the asking to do their own estimation.
And honestly I'd rather blame numbers rather than people, the impersonality of bad numbers allows you retro without personal attacks and defensiveness, which allows more rapid improvement.
1 - their stories are likely smaller than yours.
2 - you estimate TOGETHER, in a shared common estimation system
3 - what is meant to be tracked is the total collective TEAM velocity, not the velocity of an individual team member
User stories are only a way to gather requirements for a feature and set a definition of done. They have nothing to do with productivity.
Working with you might be as painful for others as working with agile is for you...
All these things (scrum, agile, etc.) are just mechanisms for working effectively as a group. Like all tools, some work better in certain situations than others, and they should be adopted deliberately with an understanding of the tradeoffs. This is traditionally where "management" falls short. It doesn't have to be this way. Accept that there are no silver bullets or always-correct methodologies, just a hodgepodge of techniques for helping people work better together.
The Scaled Agile (SAFe) approach is dramatically better here. You plan 8-12 weeks at a time across all teams and invest heavily in planning for 2-3 days of that entire time period. The planning time is synced up for all dev teams so they can communicate and work out cross dependencies.
The other perk here is that you’re goal is to commit to the 12 weeks and not every 2 weeks. That allows for more ups and downs and there’s a built in 1.5 week buffer at the end specifically to account for overrun.
You end up with a clear picture of what’s coming in the next quarter or so without flavor of the week course changes outside of a significant emergency.
What it does stop is all of the planning meetings crammed in every 2 week time period while also giving a forum for planning between all of your other teams.
There’s no advantage of scrum that is denied with SAFe. It just gets rid of most of the problems that I’ve experienced with it in the last 10-15 years.
That assertion is clearly false. Just because a Sprint is x weeks that does not mean that planning needs to focus exclusively on what you can do in x weeks. The x weeks is only relevant to establish a target for deliverables, but naturally those deliverables can and more often than not are indeed aligned with multi-sprint goals.
Heck, even in the Agile buzzword universe there is the concept of epics and spikes.
Agile does not mean the development process needs to be a 2 week circus where planners have the memory of a goldfish. It's a framework to get all stakeholders on the same page and establish operations to accommodate changes.
mostly agree with the premise though, and I'll add that "sprint" is insane nomenclature for something that you do continuously week-in and week out.
my question for the author (and ya'll) is how to reconcile the time-waste of estimating with the fact that you do indeed need some estimate of how long something is going to take in order to decide whether you should prioritize doing it (we like RICE [0]). as the designer on a startup team, i'm not going to push for designing / building some crazy VR UI no matter how much we hear a customer asking for it, but i'll definitely design some 3d button transform hover states or other small finesse if the front-end eng says it's easy to implement. i'm sure i can think of a less extreme example, but not today.
[0]: https://www.intercom.com/blog/rice-simple-prioritization-for...
Author here. Yes, another comment made the same point. But I'm glad you feel what I covered was eloquent. Often, diagnosing exactly what the problem is takes you a long way towards solving it.
As I said in the other reply, I will post the follow-up to this article in a few weeks which will outline where I am going with this: I'm building a multi-part series looking at estimating in software development, so Sprints are an important aspect.
PM: Let's go through our prioritized features. First we would like Feature A.
Team: That's probably easy, we can do it in a day or so.
PM: Great. Next we need Feature B. I know this one looks a little more complicated.
Team: Yeah, that's more like a week.
PM: That probably isn't worth it to me. We can probably push this feature back a couple releases, and maybe take out part of it.
Team: Would it help if we just did Part X? That seems like it would give you most of the value and it would be much easier.
And so on. The constant cost-benefit analysis, reprioritization, and rescoping was a great lever and made the team very productive.
The other 4 things, all related I think, that made us effective were:
• Everyone sitting together. I could go ask the designer or PM a clarifying question at any time.
• TDD. I would constantly start to write a test and realize that something didn't make sense—some assumptions were conflicting, or we needed to do another story before the one I was working, etc.
• Pairing. Many times I'd have written the test, had cleared my plan with the PM, and my pairing partner would point out a different perspective or catch one of the things I described above.
• Frequent releases, about quarterly at first and down to bi-weekly at one point.
In all cases, what we were really doing is optimizing the value of NOT doing things. We were helping the PM understand her costs, but we were also helping her eliminate huge chunks of wasteful work, e.g. building things users didn't want, things that didn't integrate well, and so on. Estimating was a piece of it, but it was really the buy-in from the business to accept our estimates and more importantly to trust us as partners in the scoping and planning process, and doing that process fluidly, that made us successful.
Make sure you're hiring the right product people?
I've never "built the wrong thing"; I -have- been told to solve the wrong problem, or been given incorrect information, or been left with unresolvable ambiguities from product that I've just had to arbitrarily pick between.
That may seem like a picky distinction, but it matters. I've never gone back and said "Huh, yeah, you defined the problem really well, then were super responsive with my following up with you, but I somehow wrote code that did something completely different to what we specced out together". Invariably it's been product not knowing what they actually want, or being hellbent to build something stupid (massive amounts of effort for no revenue impact, etc).
in my limited experience, good product builders exploit leverage points that in order to solve customer problems / test assumptions quickly. for example, usually the product people don't know how flow X is really easy to restructure like Y and solve the same problem. kind of related, but pushing all the speccing responsibility to product is also kind of boring for me as an IC.
I had an immediate histamine reaction to this statement. With a site title like Risk First, it’s like he’s standing right next to the solution but looking the other way. I suppose we’ll see in the next article if he’s being coy setting up a scenario so he can make a dramatic turn or not. I’m worried he’s instead being sincere.
But that question? It’s so much the wrong question. We know from surveys that couching questions the wrong way invites certain answers and precludes others. So I have some questions of my own, that are biased toward my agenda.
Who cares if you built the wrong thing? Or more informatively, why do you care that you built the wrong thing? Is it because you were wrong? Oh boo boo. This is a trap intellectuals set for themselves all the time.
You want to know the stuff I recall from school? It’s often the stuff I got wrong on the test. I get it. It’s a bad feeling. But bad feelings aren’t automatically bad. There are worse things in life and software than bad feelings. Like hollowness. A grey heckscape of empty mediocrity teaches you almost nothing and doesn’t even leave you with a story to tell. Nothing happened at all, and it was horrible.
How do we, as software developers, minimise our investment (time, energy, mindshare) in building the wrong thing? That’s a much better question. And some times it means steering toward the stupid, or the crazy, instead of just being averse. Steering past it, not away from it.
I don't have the slightest idea of what I've just read in your comment.
Easy. Not having your way does not mean that you're building the wrong thing, and feeling bad because your idea didn't prevailed is not a technical problem nor a sign that everyone else is incompetent or that the process is faulty. In fact, it just mean that the complainer is unprofessional and immature.
We spend so much time claiming to fight against perfectionism, and then we invite it right back in by framing important questions badly.
Go, be wrong, and then be less wrong as quickly as you can.
Life (and software) should be about taking risks - I've written a bunch of articles about this on the site[1] about how development is about making bets.
I hate blaming others, it's hard to enact productive solutions when battling against people you need to work with, I like blaming lack of processes.
How do we as engineers guide the most efficient solutions for the business problems, and in turn make our product development effective, nimble, less wasteful.
I for one have really focused on developing process around design and engineering communications.
It seems harder to make an impact between dev and product or design and product, often there is an imbalance of power and that branch is the executive and can order some really dumb and wasteful decisions if they don't have proper consult with and respect towards the other branches.
Software is an iterative process and it takes some trial and error to get it in a good state.
I always expect product to be wrong about something so it is my job to help identify issues early and plan for the specs to change.
Personally I’d say that I don’t care who’s fault it is if the product ends out bad, no one wins anything from playing the blame game, either you fix the process or you repeat the mistakes. This is why I want fast release cycles validating assumptions with end-users. Of cause there’s going to be problems in specs, don’t sit back and claim that you never had any bugs in your code ever! But the question is how do you push forwards knowing for sure that some assumptions are wrong, and that some are unneeded. Well it’s not a huge surprise, you test! Release feature incrementally with minimal work put in. Then you iterate on that. Your reviews are unit-tests for stakeholders and releases are integration tests into end-users.
Doing a big waterfall product only to then stand back from a huge tire fire saying “yea, but the root problem was that the users asked for the wrong thing in the requirements”. That’s just not me.
Those processes exist for the benefit of the team and for the team to 'run' itself. There is no reason for management to be there. Stop doing that.
I think the main problem here is a lot of companies do this weird hybrid where Scrum processes are somewhat followed, but managers keep managing the team and sometimes even taking the role of product owner and/or scrum master as well, and that just doesn't work.
Based on my experience, Scrum is introduced to re-assure managers and senior management that teams are self-organised in the "right" way.
Do you have a source for that? I personally have never experienced that. In contrast, I have experienced that the best work emerges when true trust is ingrained in the organization/culture, meaning a) mutual respect on all levels and b) and willingness to criticize the work of others. These two points are not related to any levels. Senior management can deliver great value to their teams. It very much depends on how they are involved in the work.
Also note that no team can exist outside of the organization that it funds. A dev team of 5-7 devs + PM + UX will cost a company roughly 500-700k EUR/USD per year depending on location. If you want to work on your own ideas with your team and no management interference then go and found a startup.
I am not arguing that teams should work on their own ideas. I am arguing that there are many ways a team can deliver on the requests of senior management without using Scrum. Scrum is very dogmatic and this goes against the principles set out in the Agile manifesto.
Have you heard about Shape Up by Basecamp? Would love to get some experience accounts on that method.
said slightly more succinctly:
managers deciding that you will do daily stand ups, retrospectives and 2 week sprints is the EXACT OPPOSITE of team self-management