Friday, March 19, 2010

Agile Architecture Kanban

This content has moved permanently to:
https://blog.jonm.dev/posts/agile-architecture-kanban/

3 comments:

John Speno said...

I enjoyed this. Thanks.

I want to know why the time increases as new items were added to the backlog. Did team members have to divert their attention to process new them in some way instead of working on current backlog items?

Is this why in traditional scrum the backlog is fixed during the sprint?

Jon Moore said...

@Pythonic Avocado: actually, the time for us to do any one consulting "story" once we had started it was pretty constant. We imposed a work-in-progress (WIP) limit on ourselves, so we had to finish something before starting something new. The WIP limit plays conceptually the same role as a fixed sprint backlog in Scrum: preventing the team from getting overloaded.

However, from the point of view of our clients, there are only two times that matter: when they asked for something (i.e. when it hit our backlog) and when they got it (when we were done). They didn't care when we actually started working. Queuing theory basically says if things show up on the backlog faster than you can drain them, the backlog will grow longer and longer, and the "average wait time" for a client will also grow longer and longer. The only way to avoid this is either to drain the backlog faster (perhaps by hiring more architects) or to prevent the backlog from growing so fast (by sometimes telling someone "not now").

Anonymous said...
This comment has been removed by a blog administrator.