Software development is all about breaking problems down iteratively. If you can't break the problem down to a scale where people understand, how can you ever break a problem down to a scale where a computer can understand?
But I do agree with you about "sprint completion pressure". With Kanban you don't have that and you don't have large day long "sprint planning sessions". You have just enough work in the "Dev ready" column to keep the pipeline going.
Of course not having the sprint planning pressure and not having a deadline to release doesn't work without a continuous delivery pipeline and some way to turn features on when ready.
Software development is all about breaking problems down iteratively.
It is, but it depends on the size of the iteration and who is breaking it down as to whether or not it is useful.
I much prefer, "here is the problem, solve it," to "here is the problem and I'm going to tell you how to solve it, even though I have no idea how software development works."
Of course, the most recent "official scrum" environment I worked in was horrible. They really used it to micro-manage development. We actually created all the stories for a multi-year project so we could give an overall timeline (waterfall) to management, then the business dictated the order of the stories even when they made no sense. It was a constant battle.
It is, but it depends on the size of the iteration and who is breaking it down as to whether or not it is useful.
I much prefer, "here is the problem, solve it," to "here is the problem and I'm going to tell you how to solve it, even though I have no idea how software development works.
Yes I've been subjected to that also. But the right way to do it is to have an experienced developer working with the business representative/product owner to do "backlog grooming" before the item ever gets seen by the rest of the team.
Comments
Software development is all about breaking problems down iteratively. If you can't break the problem down to a scale where people understand, how can you ever break a problem down to a scale where a computer can understand?
But I do agree with you about "sprint completion pressure". With Kanban you don't have that and you don't have large day long "sprint planning sessions". You have just enough work in the "Dev ready" column to keep the pipeline going.
Of course not having the sprint planning pressure and not having a deadline to release doesn't work without a continuous delivery pipeline and some way to turn features on when ready.
It is, but it depends on the size of the iteration and who is breaking it down as to whether or not it is useful.
I much prefer, "here is the problem, solve it," to "here is the problem and I'm going to tell you how to solve it, even though I have no idea how software development works."
Of course, the most recent "official scrum" environment I worked in was horrible. They really used it to micro-manage development. We actually created all the stories for a multi-year project so we could give an overall timeline (waterfall) to management, then the business dictated the order of the stories even when they made no sense. It was a constant battle.
It is, but it depends on the size of the iteration and who is breaking it down as to whether or not it is useful. I much prefer, "here is the problem, solve it," to "here is the problem and I'm going to tell you how to solve it, even though I have no idea how software development works.
Yes I've been subjected to that also. But the right way to do it is to have an experienced developer working with the business representative/product owner to do "backlog grooming" before the item ever gets seen by the rest of the team.