41–50 of 93 posts
I still think it ironic that when looking at the actual Agile manifesto at http://agilemanifesto.org/ (which is short and uncomplicated), that the first line is "Individuals and interactions over processes and tools" and these days practicing agile, at least in a big-house corporate environment feels like anything but.
My team moved from scrum to a kanban style process a couple years ago. The benefits were immediate. We no longer have drawn out sprint planning meetings where we discuss requirements of features that we never end up working on in that sprint. We don’t waste time debating complexity of features. Everything is now just ad hoc. When we need more requirements definitions, we pull the necessary members of the team togethe…
Can we deprecate scrum in 2018?
Earlier quoted context omitted.
I'm confused, doesn't your statement mean the analogy is good? You can neither "sprint" at work continuously nor constantly sprint in reality.
Let's say you do 2 week sprints as part of your process. You do a sprint, finish it, and then do another sprint immediately after. How is that viable? Effectively it means that you never stop sprinting. I don't think it's sustainable.
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?
I still think it ironic that when looking at the actual Agile manifesto at http://agilemanifesto.org/ (which is short and uncomplicated), that the first line is "Individuals and interactions over processes and tools" and these days practicing agile, at least in a big-house corporate environment feels like anything but.
Now I would suggest to deprecate "sprint". It is not healthy to sprint continuously. Sane software development is much more like a marathon.
I don't know if this is meant to be facetious, but I actually fully agree. "Sprint" is a terrible analogy because in reality it is impossible to be sprinting all the time. I usually just say "iteration".
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....
I still think it ironic that when looking at the actual Agile manifesto at http://agilemanifesto.org/ (which is short and uncomplicated), that the first line is "Individuals and interactions over processes and tools" and these days practicing agile, at least in a big-house corporate environment feels like anything but.
Now I would suggest to deprecate "sprint". It is not healthy to sprint continuously. Sane software development is much more like a marathon.
Running a marathon is not the healthiest thing to do either. Even "marching" has a bad connotation in this context.
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 still think it ironic that when looking at the actual Agile manifesto at http://agilemanifesto.org/ (which is short and uncomplicated), that the first line is "Individuals and interactions over processes and tools" and these days practicing agile, at least in a big-house corporate environment feels like anything but.
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.
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.