I’ve become extremely apathetic towards Agile. Whatever, this how a company needs to manage it, fine. I’m not wasting time wrapping my head around it. Tshirt size or point poker stuff or ‘As a developer, I would like to’ stories, like seriously, whatever. It’s not going anywhere and doesn’t always make sense, so I just suck it up and truck along.
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 is hell. There are now multiple boards, issues cloned from one board to another, and tons of lanes. We'll probably add more because documenting every detail is now the goal. We are a small team that is spending many hours per week having discussions on process. We even hired a consultant to come in and evaluate things.
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.
Jira is just a tool. Blame the players, not the game. Or, in this case; the users, not the tool.
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.
blaming the user does not feel like a winning strategy, idk. totally agree that it's a bad tool.
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.
Before the Agile manifesto, before Scrum/XP/Lean became popular, I had my own way of delivering software which basically was: meet with users/stakeholders, talk about what they need, build a first version in 2 to 4 weeks, release, test, adjust, repeat. For me it makes so much sense agile that I don't get why some devs don't understand the beauty and simplicity of it.
Being Agile has often little to do with being agile. True "agile" development has nothing to do with story points, daily stand up, bi-weekly planning poker sessions, retrospectives, spikes, scrum masters, etc, etc
The origin of the "standup" is just a regular daily coordination meeting - like thousands of organizations have always had.
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.
So it's a copy of a copy (Borland team), of something entirely unrelated (rugby).
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.
So in response, I’ll reiterate. I know it’s not all about me, so I shut up, tshirt size (point poker? - what is a cute an analogy? How about it’s not getting done this week? Okay not so cute. Maybe I need to think about it? What is the cute analogy there? A spike. What’s that? ‘It’s when an asshole can’t just do the simple get shit done thing and wants to .. ah fuck it, it’s a spike, cost of business, accept the user story).
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.
I don't even really understand your objections here. You're describing various tools that are useful in some situations to get the various developer and business outcomes you want.
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.
We can drill down. Let’s take moronic point poker. Let’s say I want to give a task to a new developer. He decides it’s tough and gives a high estimate. The rest of the devs give a lower estimate. Ok, what got achieved? We just pressured the new dev into what exactly? He gave his estimate. I don’t know, you’re all brilliant so fill me in.
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.
So in this situation what the team learned is that the new developer isn't confident making the change and that if they pick up the task they should expect to help them get up to speed. This outcome is preferable to someone else estimating the task from on high and handing it over to someone who then spins their wheels and feels pressured to do it in an unrealistic amount of time. It's about visibility. It's also an opportunity to clarify what is expected-often different estimates come down to different interpretations of what the story is asking for!
What's supposed to happen is that you explore why some people think it's a low point task and others think it's a high point task.
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.
Again, this means you have a broken team and not a broken tool.
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.
Furthermore, and I find it odd that us smarty pants math people keep forgetting this. Numbers make decisions easily justifiable. Those story points, those days tracking roadblocks. All that data, weather it's wrong or right, allows people to make decisions where they would otherwise have to justify with nebulous reasoning. The down side is, our point keep doesn't explain the reasoning behind delays and other bad numbers. Hopefully, we get better at quantizing this shit, but it's not going to go away. Their is something like a gravitational force in accountability. Those who can shirk it, to others or to numbers, must shirk it to have more power.
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.
So here’s a question for you. I notice that during our sprint planning, some team members create almost 50 user stories. I probably create 1/6 of that. Do you think it would bode well for me to create more user stories so that I can mark it as ‘done’, so when the numbers are rolled up I can look great and avoid the mass culling that seems to be a forgone conclusion given the system that encourages this kinda nonsense?
> 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.
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 problem is that is now how Scrum is sold. If you claim Scrum doesn't work for your particular team/project, the usual answer is that you are not implementing Scrum correctly.
In case anybody wants an answer to that, here's mine:
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.
Author here. Sorry you think that. I see the article title has been changed, although I wrote this about 3 weeks ago so I'm not sure why it's been labelled as (2019).
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.
The ending is your actual point, which is excellent. With scrum being so oversold in companies, it's a hard sell though. So an article starting out with this premise would perhaps gain better traction:
"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."
Author here. Yes, the overall feeling I'm getting from the responses is a disappointment that I didn't get to this. Initially that had been my intent, but as I wrote it I realised I was trying to crowbar too much into a single article.
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.
The issue with Scrum is everything revolving around 2 week sprints. That doesn’t allow for much in terms of variability, longer term scheduling, or planning dependencies across multiple teams. Plus, in order to try to make the commitment/forecast accurate you have to invest a hefty amount of planning time every 2 weeks.
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.
To be honest when I saw the diagram for scaled agile https://www.scaledagileframework.com/ the first my BS meter went off big time :). It definitely doesn’t deserve the word “agile” in it. It feels more like the management pipe dream of the perfectly predictable machine for software development.
Yup. And the OP did nothing to dissuade me from that. 12 weeks instead of 2 isn't actually helpful; the whole goal of the 2 week sprint was to find a balance between minimal amount of time needed to recognize 'we're going to take longer than anticipated', and actually being able to deliver something useful. Going to 12 just means that you won't recognize things are slipping until the quarter is up.
You still break things into 2 week iterations over the 8-12 weeks. You still check in on things, get feedback and determine if changes or pivoting is needed. Nothing stops that.
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.
> The issue with Scrum is everything revolving around 2 week sprints. That doesn’t allow for much in terms of variability, longer term scheduling, or planning dependencies across multiple teams.
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.
Every real scrum environment I’ve been in or heard of in my career has turned into “sprint at a time” planning. Perhaps short sided management is at fault?
I’ve been thinking what if we did six week cycles like back in grade school. Five weeks for dev work, 1 light week for sprint retro and sprint planning. I could sneak it in cus it’s a multiple of 2.
ended with a cliffhanger! OP eloquently picked apart the predominant system without a clear alternative :)
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.
> ended with a cliffhanger! OP eloquently picked apart the predominant system without a clear alternative :)
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.
My most recent team ran a version of XP, and I found IPM (iteration planning meeting) to be one of the most effective and important things we did. We had a very good back and forth with our Product Manager, with conversations usually going something like this:
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.
'How can we, as software developers, minimise the chance of building the wrong thing?'
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).
Honestly, Project/Product/Program staff, BAs, and Testers perform an important function when properly aligned and cooperating with development staff. When done well, they keep pesky 'business side's owners out of the way so the technical workers can get on with development work.
never have i ever been involved with a _successful_ software project where product decisions were made entirely by product people and handed off to design/eng.
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.
Yes, people have to work together and all roles have something important to contribute. I have been in plenty of situations where product managers and users tried to solve a problem and I could guide the discussion towards solutions that made sense development wise and also satisfied the users. Having customers or product people defining solutions alone is a surefire recipe for misdesigned systems.
> “How can we, as software developers, minimise the chance of building the wrong thing?”
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.
Author here: nice comment. Absolutely the way to success isn't about avoiding all risk. As you point out, this is the way to mediocrity and tedium.
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.
The triangle relationship between product Design <-> Product <-> Engineering seems so hard to get right and maintain. You need experts that can straddle these lines and make sure each branch is on the same page and their concerns are appropriatly attended to, regarding the needs of a business.
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.
Sounds like you saying that the wrong thing has indeed been built in a project where you where doing the building, but you are in a great position to blame someone else for any bad products that resulted since they asked for the wrong thing or where vague.
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.
The only way you can fix scrum is by burning it on the stake. One of the core principles of Agile is to recognize that the best work emerges from self-organized teams. however, most scrum methodologies completely ignore this and put control back in the hands of senior management by introducing heavy handed processes (daily stand ups, retrospective, bi-weekly planning sessions, scrum masters, etc). You know you are in trouble when a team introduces a definition of done and you are in deep trouble when senior management starts discussion burn down rate charts of completely made up story points.
I've done scrum for years and have very rarely had a manager involved in any of those processes, and I have certainly never had senior management involved.
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 agree. Scrum is about self-organized teams. Managers are not part of the Scrum team, in fact, they are not allowed to speak in any of those meetings (if they choose to assist at all).
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.
You are talking about processes. Who did you think dictates those processes ? Why does Scrum dictate these processes have to be the same for every single team to 'run' itself ?
Based on my experience, Scrum is introduced to re-assure managers and senior management that teams are self-organised in the "right" way.
You've missed the point. I'm not talking about processes at all. I'm talking about the relationship and trust between company management and the team. That is the core problem here. If management want to play Command and Control the whole time and your team is happy to be treated like children, then no, you can't do scrum in any meaningful way, and yes it will suck.
> One of the core principles of Agile is to recognize that the best work emerges from self-organized teams.
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.
73 comments
[ 3.5 ms ] story [ 147 ms ] threadHere 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.
> 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.
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.
[1] - https://riskfirst.org/Coding-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.
https://basecamp.com/shapeup
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
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.
https://youtu.be/rQKis2Cfpeo?t=114
Some open source projects are sponsored or backed by foundations, and contributors do get paid.