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.
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.
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.
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.
I did my first CSM course with Ken Schwaber. I did another recently with someone else. The recent course was all process. Ken's course was mostly "why".
Jeff Sutherland said there are three things that must be true for a team to be a Scrum team:
1. It must be self-governing.
2. The team members must be on the team 100%
3. The team members must stay for the duration.
With the exception of start-ups, I've seen maybe one team which met these criteria. But they all had sprints. And of course, they were all held to their commitment. Scrum is now a tool for management to death march people.
Think of all these metrics that management measures scrum teams on. Can you imagine any of these teams turning around and saying, "We're going to measure how many of your bullshit wishlist items meet the definition of an actionable story when presented in sprint planning, and how many hours are wasted?" Of course not. Management can't abide a team that meets rule 1. "I'm a manager! I must manage! What is my job if my teams are self managing?!"
Scrum, as Ken Schwaber describes it, is a fantastic way to develop product. Unfortunately, if you are in an organization that would truly let you do Scrum, then you probably don't need it. You are already qualified, experienced and empowered. If its a hundred twenty-year-olds being told to "do scrum", it probably ain't Scrum.
Clear responsibilities, accountability and personal autonomy are so much, so much, better arrangement then self governing team.
* edit: provably
You're not. One of the bigger issues I've seen with Scrum is not being able to shoe horn in work that needs to be done because business didn't identify it as a "story".
I believe development is there to serve business and any processes used to facilitate this serving should be defined by development. I don't dictate how a general contractor satisfies my requirements for my home build, I leave that to them. I just expect my requirements to be met at or near budget.
A lot of these software process issues boil down to managements never ending quest to commoditize developers.
Scrum is, at heart, designed precisely to stop the behavior you're demanding - that is, the endless stream of "small" interruptions and constantly shifting priorities. The raisins.
Why are you trying to "shoe horn in work" for this iteration that you weren't aware was even an issue when the iteration planning happened? Is production down? Is it a hair-on-fire emergency that threatens the business? Or is it just "important". FUCK important. If it's so important, put it in the story backlog and have it done in the next iteration.
If it's important enough to disrupt the iteration, it's important enough to cancel the iteration, toss all that iteration's unfinished work onto the backlog, and start over. That's how Scrum is supposed to work, but never does, because someone wants raisins at the last minute and thinks it's not a big deal.
Do you realize your argument is based on an assumption that is not necessarily true? If Scrum is as good as advertised, it shouldn't require untruths to justify it.
I know a "walk" is yet just another physical analogy for a software production process (which the analogies don't always work), but maybe it is more of a cultural mindset to value longterm team health without it becoming just a "slacking" week?
> a time-box of one month or less during which a "Done", useable, and potentially releasable product Increment is created. Sprints have consistent durations throughout a development effort. A new Sprint starts immediately after the conclusion of the previous Sprint.
(http://www.scrumguides.org/scrum-guide.html#events-sprint)
There's nothing that says you need to "sprint" through your sprints, quite the contrary it's supposed to be a way of measuring your team's steady-state output by making the feedback loop short.
If people are really hearing the word "sprint" and thinking "ah, Scum is telling me to work at 110% all the time without stopping", then I put forth that no methodology or change of terminology is going to save them from themselves. However, I suspect there's something about the timebox structure that makes short-term thinking the default unless discipline is applied, and discipline is hard.
Or to go on to the next sprint with the same task. But here lies the problem in many cases. The sprint is taken not as a time box but as a deadline. A sprint should meen: "You can work 2 weeks, 5 days a week, 8 hours a day on this. Then you stop to think."
Want to know the correct answer to this agreement? Sometimes YAGNI is good, sometimes it's bad. Anyone who doesn't realize this is not qualified to decide which case a team finds itself in.
Back when I first started building a startup, I thought "Thank Dog I no longer have to deal with stupid compromised software, and can start writing everything right!" By the time I was getting anywhere, I was well into toss-over-wall methodology. I did things that I knew full well were compromised and would hurt me later, because the work needed done, and needed to "be done". It was a real education.
I actually have a lightning talk in mind on this subject, called "Why software sucks", that argues that suckage is the nature of software development, and that "barely works" is the best we can realistically ask for - or even should ask for.