The problem with breaking things down iteratively is the same as trying to paint a mural 1 square inch at a time. The developers / designers don't get a feel for the overall picture what so ever.
Also, instead of having broader estimates in terms of months, you force developers to rush constantly with sprint completion pressure. In case you didn't know, rushing developers is very, very counterproductive. Cost, Time, Scope. Pick 2.
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.
Where I recently did this, each iteration was a feature and it was supposed to be "code complete, ready for production, never needing to be modified again." We had to constantly fight to refactor existing stories when new stories were introduced that made our original designs less than desirable. It was a mess.
Comments
The problem with breaking things down iteratively is the same as trying to paint a mural 1 square inch at a time. The developers / designers don't get a feel for the overall picture what so ever.
Also, instead of having broader estimates in terms of months, you force developers to rush constantly with sprint completion pressure. In case you didn't know, rushing developers is very, very counterproductive. Cost, Time, Scope. Pick 2.
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.
What you are describing is the opposite of iterative. When you iterate, you go over the same territory multiple times, with more insight/detail.
Where I recently did this, each iteration was a feature and it was supposed to be "code complete, ready for production, never needing to be modified again." We had to constantly fight to refactor existing stories when new stories were introduced that made our original designs less than desirable. It was a mess.