21–30 of 459 posts
But the backlog is useful. I find it amazing how what seems like a great idea when I think of it looks utterly pointless when I see it still on the backlog 3 months later. It's a useful tool to deal with our tendency to fall in love with our ideas.
So how do we run a marathon? That's right, we run a 200m wind sprint! Then another sprint, and another, and pretty soon...
Of course no one does this, you'd die! We don't do this in software either, for the same reason. But when we talk about 'sprints' this is what we tell ourselves we're doing.
Personally, I never liked agile. I like to get a description of a problem. Prototype. Take that to that customer and ask for feedback. Iterate. QA. QA. QA. Release. Thing is, much like governments, these models all fall short because people aren’t great. I think that if agile isn’t working for a team they should try another method, and if agile does work for a team that’s fantastic. People, imho, shouldn’t blindly fo…
The problem with "Requirements, prototype, feedback, iterate, qa, qa, qa, release" is that most large shops turn that into a 3 year process. As in, a group sits in a room for 6 months and writes some insane "Requirements Doc". Then six months of prototyping against it before any customer has seen anything. Etc etc down the line until you're a programmer looking at a 3 year old requirements doc with a thousand questions that arise during implementation but the designers who wrote the doc left the company two years ago, etc etc
Waterfall was to me inarguably worse than agile.
At least with agile people try to do requirements, prototyping and iterating in a very short period of time, so the feedback loop with customers actually works, and you actually release something on a regular basis.
Kanban is the best middle ground IMO. I agree sprints are a distraction. The planning and ceremonies alone sap time. Sprints are really just a form of pressure. In my experience the stories estimating is not accurate enough to set up a predictable sprint, and the inevitable deviation from the plan just creates additional work to audit and adjust, along with a sense of failure around what has often been a productive 2…
Other than that, I fully agree that Kanban is a great middle ground, as it’s low overhead and focuses on prioritization and flexibility rather than planning and burndown charts and whatnot.
Kanban is the best middle ground IMO. I agree sprints are a distraction. The planning and ceremonies alone sap time. Sprints are really just a form of pressure. In my experience the stories estimating is not accurate enough to set up a predictable sprint, and the inevitable deviation from the plan just creates additional work to audit and adjust, along with a sense of failure around what has often been a productive 2…
In a job a long time ago there was a brogrammer in the team, always estimating absurdly short times because he was so good and fast (he wasn't bad, but he was 2-3x slower than he himself estimated). So I had picked up the habit of estimating 5x longer on tasks, to balance him out. Also all the sprint planning and retrospective took basically 30% of our time.
"Oh, you can do it like THAT?! I was not aware. I'll take a shot at implementing the feature using that approach."
Kanban is the best middle ground IMO. I agree sprints are a distraction. The planning and ceremonies alone sap time. Sprints are really just a form of pressure. In my experience the stories estimating is not accurate enough to set up a predictable sprint, and the inevitable deviation from the plan just creates additional work to audit and adjust, along with a sense of failure around what has often been a productive 2…
In a job a long time ago there was a brogrammer in the team, always estimating absurdly short times because he was so good and fast (he wasn't bad, but he was 2-3x slower than he himself estimated). So I had picked up the habit of estimating 5x longer on tasks, to balance him out. Also all the sprint planning and retrospective took basically 30% of our time.
Managers are pushed to produce reports to prove they're managing. Reports require metrics, and that's a lot of where all this rubbish starts. The solution in my experience is to keep teams small enough that you don't need those sorts of layers of management (though the opposite is inevitable in larger companies).
Personally, I never liked agile. I like to get a description of a problem. Prototype. Take that to that customer and ask for feedback. Iterate. QA. QA. QA. Release. Thing is, much like governments, these models all fall short because people aren’t great. I think that if agile isn’t working for a team they should try another method, and if agile does work for a team that’s fantastic. People, imho, shouldn’t blindly fo…
That is agile for me. What is agile for you then?
Rich Hickey has a great joke about sprints, paraphrasing: So how do we run a marathon? That's right, we run a 200m wind sprint! Then another sprint, and another, and pretty soon... Of course no one does this, you'd die! We don't do this in software either, for the same reason. But when we talk about 'sprints' this is what we tell ourselves we're doing.
Orienteering, perhaps: https://en.wikipedia.org/wiki/Orienteering
Anyway, with a QA function, you need some kind of release cycle. I don't believe in prescriptive sprints where either developers are stressed to hit an arbitrary end of cycle deadline or developers sit on their hands because the phase of the sprint dictates no new work (which I've heard of happening in some particularly agile-diseased companies). I think a reasonably regular cycle that aims to ship what's ready fairly often is a good middle ground that keeps quality high, keeps the product evolving, and maximizes developer keyboard time (and of course you also need the ability to hotfix production occasionally.)