Yes yes yes. It never made sense to me that our ticket sizing was supposed to be an estimate and yet the planning that used those estimates was considered a commitment. Totally insane.
Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)
31–40 of 93 posts
Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)
#32I 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.
Absolutely - some people hear, "people before process", think it sounds great, then immediately go looking for a process to implement it and find Scrum.
Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)
#33http://programming-motherfucker.com/
do people really pair program in real life? I've never actually seen it
Yes. Pair programming as the default for me since 2004. I've done it full time for 8 years at an XP shop (Scrum was added later) w/ 3 teams of 20+ total on 3 different continents. Worked for an Agile consultancy and trained people on Pair Programming and TDD for 4 years. I'm now working for an org that does both Pairing AND mob programming (https://en.wikipedia.org/wiki/Mob_programming). It takes time, patience, and humility to learn how to do well. I find teams that pair simply build better software that has less bugs. There's literally a book on it to consider (https://www.amazon.com/Pair-Programming-Illuminated-Laurie-W...).
Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)
#34Yes yes yes. It never made sense to me that our ticket sizing was supposed to be an estimate and yet the planning that used those estimates was considered a commitment. Totally insane.
Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)
#35Now 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.
Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)
#36Earlier 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.
Is that actually what scrum suggests sprints are? Thanks, I missed that, that's silly if so. I assumed by the name that this was like a one week a month kind of thing.
Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)
#37My 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…
Have any good resources on your team's kanban system?
Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)
#38My 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…
Same here. Just pick the next item from the backlog and do what needs to be done. It's much easier.
Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)
#39Re: Commitment vs. Forecast: A Subtle But Important Change to Scrum (2011)
#40My 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…
I’m familiar with some of the artifacts of a kanban style system - do you have any documentation of what your particular kanban process looks like (that you can share)?