I feel like YAGNI is similarly abused, I don't know how many times I've said "You know what, while we're at it we should...." only to be overridden with "YAGNI!", only to be proven right 3 months later, only now the cost of refactoring > value of the feature, and saying I told you so isn't being a "team player", so no one ever learns.
I very often wonder if I am the only one that feels this way.
That was my first introduction to uppercase A for Agile.
Ultimately the wider business never changes in terms of it wants predictable delivery and deadline forecasts, but internally they have to then wedge some version of lowercase a for agile into that because the benefits day to day are there so you have this clunky enterprise friendly version that poorly tries to get best of both.
One way I've seen it used was as a way to justify organizing meetings as a means to solve an increase in defect regressions rather than allocating extra work on automated tests.
The former was "individuals and interactions" and the latter was tools and processes. I thought it was a reasonable interpretation and also wrong.
I'm wondering because I have had places bring up metrics like average story points completed per sprint in performance reviews. Which kind of confused me when numbers for our team seemed to be doing fine, and it seemed like my work was going well based off of previous conversations with management.
I would be curious in hearing how people judge dev productivity as well, it's something that I don't like to just use a number, though there may be some benefit in having that being a small part of the judgement.
You can just time kanban tickets vs estimated size (all the forecasting, tracking, etc, should be done by a manager, without wasting the team's time) combined with pulling from the right hand side and vigorous action towards blockers. Optimise for throughput.
During the best version of this, as I experienced, we spent about 5 minutes in the morning as a team, and occasionally visited the board throughout the day (not as a team, sometimes as a pair, to discuss something and add/move tickets). My manager at the time spent some time at the end of each week by himself collecting cards and doing the tracking to make the higher-ups happy.
I'm curious about a few things, if you don't mind answering.
When do tickets get broken down into manageable chunks? Who does the breakdown?
When is a rough cut of effort put on a ticket? S/M/L often matters when making priority decisions.
So far I have not found an exception to this. Thing is that means everyone is doing Scrumbut (we do Scrum, but...) Which means you have to relearn or reargue with every single team about the exact same concerns. It’s gotten old.
Agreed. Don't forget to throw daily standups in their. My current project spends 2.5 person hours per day on the daily standup.
Finish and deliver don’t have to be the same thing. Especially when features depend on each other.
A group of unaffiliated contractors slipped kanban into Boeing in part because we never said what we were doing. But every time there was a hiccup we proposed another kanban process. WIP limits took a while but saved a lot of headaches. If we are over the limit and you finish a story you had to help someone else or get a special dispensation for the leads (sometimes we had stories that depended on other teams and the next story was straightforward).
It is by far the biggest silent conspiracy to do good that I ever participated in.
Unfortunately after we got reported into a sustaining team there was some peer to our manager who would not shut up about Scrum. If you’ve done Kanban, Scrum is like when your parents make you hang out with your kid brother’s friends.
It was a really simple and effective approach, but where it broke down was: there's a lot of people/roles/depts who have no idea how to work incrementally. UX "needs to work ahead", product "needs the whole backlog", Ops "have their own backlog", etc.
Scrum didn't work with everyone hawking over a few engineers - then it just becomes task tracking bullshit.
Days 1-3: Walking, talking, and enjoying life.
Days 4-7: Jogging. You climb some minor hills and get a little out of breath, but life is still good. You've got this.
Day 8: Big hill day! You eat an energy gel and start on up. You expect to be exhausted at the top, but you'll have two more days to relax a bit afterward.
Day 9: Dark night of the soul. You ran all night but got lost in the night. You're way off course, further down the hill, and the entire hillside is on fire. It's all you can do to just find the course again.
Day 10: Intent on staying on course, you slowly slog on up. You get burned a bit from the raging fires around you. Life sucks. The job sucks.
Day 10+1: You aren't quite sure how or when you agreed to this, but your Saturday is shot as you try to climb up the final stretch.
Day 10+2: You're there! Everyone else is there and you're all exhausted, but proud of your accomplishment. Sure your Sunday was shot, but it's a one time thing. You tell yourself you'll never over commit again.
....
Days 1-3: Walking, talking, and enjoying life....
A lot of these analogies were not well thought through. I will wager the methodology merchants behind scrum were neither runners nor rugby players ever.
I think I'm supportive of the idea on removing it. Seems the goal is ultimately to find ways in rhetoric and action to align the teams in working to the end goal. Which, often, might require tradeoffs to reach a timely delivery. And timing is a requirement.
It can keep teams from collaborating because of a need to finish their commitments first, effectively blocking the other teams and delaying actual delivery of the product. You can see the same issues in customer support requests. The second that somebody decides to measure completed sprint commitments, you are in deeeeeep trouble because it forces people to low ball to hit that number. It removes your ability to pivot.
The entire concept of sprint commitments in a moderately sized team is borderline destructive.
This change is the best news about software development I’ve read in YEARS.
Like all of us, he's just human
I once worked at a company where the powers that be decided to go all Scrum. They hired a PM to convert all project, inc ongoing ones, to Scrum. It turned an enjoyable job in to a miserable one.
It's sometimes a more efficient way of building stuff where, for a particular task, you need a whole bunch of knowledge or information that's currently living in somebody else's head.
Also, if I'm having one of those days when I feel sluggish having another person there kickstarts me a bit...
Defaulting to pair programming for every task - especially when the conditions above are not met is a super inefficient and overbearing way of developing though.
source: used to think pair programming was odd until I gave it a proper go.
