Comments on: Potential Dysfunctions of Sprint Commitments http://properosolutions.com/2010/03/potential-dysfunctions-of-sprint-commitments/ Helping organizations succeed with agile software development Wed, 01 Feb 2012 02:47:16 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: Brad http://properosolutions.com/2010/03/potential-dysfunctions-of-sprint-commitments/comment-page-1/#comment-173 Brad Sat, 13 Mar 2010 12:07:27 +0000 http://properosolutions.com/?p=459#comment-173 Thanks for your comments, Bob. I do agree with rule #3 that sprints should not be extended. I like the rhythm that regular sprints provide, particularly for planning and retrospectives. You're correct that proper training and adjusting company culture to understand that there is no "penalty" for not delivering a story by the end of a sprint. I also believe a focus on value & priorities, combined with the principles of flow and building quality in teach us to reach a sustainable pace and to keep the business value flowing - regardless of a somewhat arbitrary sprint boundary. I believe kanban is a way to reinforce those principles. Thanks for your comments, Bob. I do agree with rule #3 that sprints should not be extended. I like the rhythm that regular sprints provide, particularly for planning and retrospectives. You’re correct that proper training and adjusting company culture to understand that there is no “penalty” for not delivering a story by the end of a sprint. I also believe a focus on value & priorities, combined with the principles of flow and building quality in teach us to reach a sustainable pace and to keep the business value flowing – regardless of a somewhat arbitrary sprint boundary. I believe kanban is a way to reinforce those principles.

]]> By: Bob Hartman http://properosolutions.com/2010/03/potential-dysfunctions-of-sprint-commitments/comment-page-1/#comment-171 Bob Hartman Thu, 11 Mar 2010 17:35:59 +0000 http://properosolutions.com/?p=459#comment-171 Brad, I agree with some things in your post but not with others. I understand the potential dysfunction you talk about, but I think that ties back to a team's training and working agreements. In particular your first items #2 and #3 I cover very differently. #3 I specifically say should never be done because there are "good sprint failures" and "bad sprint failures." At the retrospective figure out which you had and adjust accordingly. On #2 I specifically tell teams if everything else in a sprint is completed, pull an item from the backlog and not finishing it is ok. It spills into the next sprint. There is not "penalty" for doing that, in fact it is considered a good thing because the commitment was already met. It all boils down to the initial training and the way the team and the rest of the organization interprets it. I am very clear about good vs. bad failure but that's too big a subject for a comment! The rest of the org needs to understand this as well because that is where the pressure WOULD come from if they didn't understand. Once the org understands appropriately it is easier for the team to relax. Interestingly you can also look at some of the sprint metrics and see various dysfunctions in action as I mention in a series of blog posts about burndown charts http://www.agileforall.com/2009/12/29/agile-antipattern-dysfunctional-burndown-charts-roundup-post/ These may actually be applicable here as well because the burndown wall or cliff may also be caused by cutting quality corners. I didn't think about that at the time but I'm making it a note to add at a later time. Having said all that, you and I have both been in situations where the initial training made NONE of this very clear and the result is exactly what you say. I just want people to know there are alternatives depending mostly on how things are presented and interpreted. Great blog post though. Very thought provoking. Brad, I agree with some things in your post but not with others. I understand the potential dysfunction you talk about, but I think that ties back to a team’s training and working agreements. In particular your first items #2 and #3 I cover very differently. #3 I specifically say should never be done because there are “good sprint failures” and “bad sprint failures.” At the retrospective figure out which you had and adjust accordingly. On #2 I specifically tell teams if everything else in a sprint is completed, pull an item from the backlog and not finishing it is ok. It spills into the next sprint. There is not “penalty” for doing that, in fact it is considered a good thing because the commitment was already met.

It all boils down to the initial training and the way the team and the rest of the organization interprets it. I am very clear about good vs. bad failure but that’s too big a subject for a comment! The rest of the org needs to understand this as well because that is where the pressure WOULD come from if they didn’t understand. Once the org understands appropriately it is easier for the team to relax.

Interestingly you can also look at some of the sprint metrics and see various dysfunctions in action as I mention in a series of blog posts about burndown charts http://www.agileforall.com/2009/12/29/agile-antipattern-dysfunctional-burndown-charts-roundup-post/ These may actually be applicable here as well because the burndown wall or cliff may also be caused by cutting quality corners. I didn’t think about that at the time but I’m making it a note to add at a later time.

Having said all that, you and I have both been in situations where the initial training made NONE of this very clear and the result is exactly what you say. I just want people to know there are alternatives depending mostly on how things are presented and interpreted.

Great blog post though. Very thought provoking.

]]>