Good advice; when faced with a new situation don't act too fast instead Observe, Interpret, then Intervene.
A Kanban Is Just A Signal To Do Work
A good post on kanban by describing it with a series of pictures and examples. I think this is the best description I have read as it tries to not blur what it is. Kanban is a tool, nothing more, nothing less.
An article talking about a particular project and how Scrum didn't seem to fit the bill. I agree with the stated limitations of Scrum (based on a reading of Lean SW by Mark & Tom):
- Why do we have two-week sprints? Isn't that an artificial and therefore wasteful limit that batches up work?
- Why do we have seven people on the team? Can we have fewer (or more) team members?
- Why do we demo at the end of a sprint and not when the story is complete? Doesn't this sound like batching work?
- Why do we estimate story points in an estimation session when some of those stories may not played because of reprioritization?
- Shouldn't estimates be done ONLY by those working on a story? Having people that will not work on the story estimate seems like a handoff situation.
- Why do we work on several stories during a sprint? Can we work on just one and reduce inventories of work?
The second page goes into how they implemented kanban. This was less interesting to me as it seemed mostly arbitrary and didn't really question/analyze why they did what they did. Stories and examples are good though as they help others with similar problems.
This response from DJ Anderson is well thought out and makes sense. Of course, Ron responds. I think both have valid points. I would say it depends on the situation and stories are just that...stories that try to teach. Ron does that extremely well.
It is hard to argue with his logic. I would like to hear where he is wrong.
I am biased as Chrome is my favorite browser, but I think their approach is cool.
No comments:
Post a Comment