tag:blogger.com,1999:blog-7930876570525471458.post6849644538776317918..comments2023-09-08T07:50:02.120-04:00Comments on Agile & Business: Scrum & KanbanJoe Littlehttp://www.blogger.com/profile/13413810050491070483noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-7930876570525471458.post-55351928575164965372011-11-22T00:47:05.370-05:002011-11-22T00:47:05.370-05:00Joe,
Thanks for the response.
Any mode of devel...Joe,<br /><br />Thanks for the response. <br /><br />Any mode of development that increases intimacy with business or extends decision event horizons brings with it the risk of gratuitous vacillation in choice. Coping with that very real threat is one of the reasons why the "Individuals and Interactions" side of the Agile equation get's the bold letter treatment. Mastering when (and when not) to change design decisions requires discipline and the acquisition of that discipline is heavily influenced by corporate culture (what isn't?). <br /><br />I find that with a little creative coaching, seismic swings in direction can usually be nulled out without abandoning an otherwise helpful approach to creating products.<br /><br />My "Warning Will Robinson" ring tone goes off whenever I hear words like "pure" and "true" used in close proximity to any process or tool in a sentence. Process purity should always take a backseat to team effectiveness. Most Scrumban teams I've seen continue to realize value from doing demos and maintaining a planning / review cadence so.. why change? That's really up to the team. What's cool is that with iterative approval by product owners, there's a LOT fewer surprises when you get to those mile marker ceremonies. As mentioned, you do have to keep an eye on the thrash. <br /><br />I LOVE the music / dancing metaphor!! Grace and elegance emerge when the fundamentals become second nature; the trick is getting them to stop staring at their shoes, lift their heads, and find that harmony of flow (<i>...quickly ducks before the metaphor police come by to clobber him with their night sticks...</i>)<br /><br />Cheers!<br />J.Jay Packlickhttps://www.blogger.com/profile/01508428509647437952noreply@blogger.comtag:blogger.com,1999:blog-7930876570525471458.post-90851136088921922742011-11-21T22:28:35.425-05:002011-11-21T22:28:35.425-05:00Hi Jay,
Glad to hear that Kanban has gotten MORE ...Hi Jay,<br /><br />Glad to hear that Kanban has gotten MORE customer/business engagement. As you suggest, anything is possible depending on the specific people involved.<br /><br />I have observed (although not proven to myself) that the business can want too much flexibility, ie, they become 'whimsical' not because real life is changing, but because of their political dysfunction. I do hope that is not the case for you. I can imagine it not being the case, too.<br /><br />My next concern about 'pure' "Kanban" is that we lose the demo. And the right attendance at the demo. To me, we want people there who will tell us: "Well, it's pretty much what we said, but now that I look at it, it's not what I want." At most of my clients, we can only get a bunch of those guys to show up about once every 2 weeks. Now, if you can get them to show up daily (and I have been in a few places where you can...well, every day that 'their' story is being worked), then it's a different problem.<br /><br />My last concern is the tendency of me and others to be lost in the weeds. We need a cycle (every 2 weeks?) of looking up and saying "now, where were we actually trying to get to?" Or, to put it a different way: what do we think the minimum marketable feature set is today? Again, most of the kinds of firms I work with need this. I have also seen firms where this issue is very different. <br /><br />One more thing you point out... we do not do Scrum or Kanban or whatever without thinking about the principles that the related practices are attempting to put in play. Only when we are in sync with the music do the dance steps become wonderful. I think many of us are dancing the steps, but no longer hear any music. It is a wonderful thing for a man to see a beautiful girl realizing the music in her dancing. Much the same applies, by metaphor, to our work. It can be wonderful.<br /><br />Thanks!<br />JoeJoe Littlehttps://www.blogger.com/profile/13413810050491070483noreply@blogger.comtag:blogger.com,1999:blog-7930876570525471458.post-42942419276566664242011-11-21T20:48:04.158-05:002011-11-21T20:48:04.158-05:00Joe,
Ahh..you can almost feel the learning in the...Joe, <br />Ahh..you can almost feel the learning in the air, can't you? (smile). It must be that time of year. <br /><br />I couldn't agree more with most of what you've shared above; either the tools we're using help our teams and customers or they're not. Sometimes it's a problem of fitting the tool to the context, and sometimes it's a problem of learning and maturity. <br /><br />Re. mastering Scrum before attempting Kanban; generally, I've found that teams unable to curtail their carryover lack the skills to limit WIP in activity queues. This is patently obvious when you realize that, from one point of view, a Sprint is essentially Kanban with a single time based queue (i.e. where the WIP cap = estimated capacity of the team for the duration of the Sprint) <br /><br />Regarding those smiling faces, on the teams in which we've implemented 'Scrumban', I've observed the opposite phenomena you describe; business has been ecstatic about the increase in flexibility and reduction in cycle times. They're more engaged, not less (and in a healthy way). The teams seem happier too. Maybe it's just a difference in contexts or execution?<br /> <br />Regarding metrics, I'd be interested in hearing what problems you've encountered with 'cycle time per story point'. It seems to provide <i>fairly useful</i> feedback for evaluating the outcome of tweaks to the way the team manages flow (nothing's perfect of course). It's also a pretty handy way to spot deficiencies in the team's ability to estimate effort relatively (the yucky graphs just jump out at you). <br /><br />I'm looking forward to reading about your thoughts and/or experience on the discipline of story decomposition (size) to improve flow. Regardless of methods of visualization, it seems a vexing (and sometimes fruitless) pursuit for some categories of problems. In lieu of that, I've seen some pretty good results limiting WIP in activity queues based on story points rather than story counts. Oh... wait... that's what we do with Sprints in Scrum. Never mind. Old news. (smile)<br /> <br />Extremely thoughtful post,<br />Thanks!<br />J.Jay Packlickhttps://www.blogger.com/profile/01508428509647437952noreply@blogger.comtag:blogger.com,1999:blog-7930876570525471458.post-73827150381656737322011-11-21T08:37:32.873-05:002011-11-21T08:37:32.873-05:00Hi Matthias,
I agree. I guess I will add this. To...Hi Matthias,<br /><br />I agree. I guess I will add this. To me, Scrum's 'incompleteness' is a virtue. While, if by Kanban one means the cards and some small usage around that, then Kanban's in completeness is a problem.<br /><br />I think/hope most decent Kanban implementations avoid the problems I am concerned about to a fair degree.<br /><br />I hope I explained those two comments in the post well enough.<br /><br />Anyway, completely agree with what you said.<br /><br />Thanks!<br />JoeJoe Littlehttps://www.blogger.com/profile/13413810050491070483noreply@blogger.comtag:blogger.com,1999:blog-7930876570525471458.post-85865026271573303222011-11-21T08:35:48.912-05:002011-11-21T08:35:48.912-05:00This comment has been removed by the author.Joe Littlehttps://www.blogger.com/profile/13413810050491070483noreply@blogger.comtag:blogger.com,1999:blog-7930876570525471458.post-48565067683340534782011-11-21T07:35:31.205-05:002011-11-21T07:35:31.205-05:00Thanks, Joe, on your thoughts on Scrum, Kanban, an...Thanks, Joe, on your thoughts on Scrum, Kanban, and Lean. Too often people forget that Scrum and Kanban both are founded in Lean and that none of them is complete in itself. It's really important to understand the underlying Lean principles - only then people can improve their processes to make them more successful.Matthias Marschallhttp://www.agileweboperations.comnoreply@blogger.com