Oh We have advanced beyond Scrum - Revision history

Clarman at 01:40, 25 January 2015

2015-01-25T01:40:16Z

Clarman: /* Beyond Timeboxing within Scrum: Type C (Type 3) Scrum */

2015-01-25T01:40:03Z

Beyond Timeboxing within Scrum: Type C (Type 3) Scrum

Clarman at 01:39, 25 January 2015

2015-01-25T01:39:42Z

Clarman: /* Beyond Timeboxing within Scrum: Type C (Type 3) Scrum */

2015-01-25T01:39:06Z

Beyond Timeboxing within Scrum: Type C (Type 3) Scrum

Clarman at 01:36, 25 January 2015

2015-01-25T01:36:43Z

Clarman at 01:34, 25 January 2015

2015-01-25T01:34:17Z

Clarman at 01:33, 25 January 2015

2015-01-25T01:33:35Z

Clarman at 01:14, 25 January 2015

2015-01-25T01:14:29Z

Clarman at 01:09, 25 January 2015

2015-01-25T01:09:01Z

Clarman at 01:08, 25 January 2015

2015-01-25T01:08:47Z

← Older revision		Revision as of 01:40, 25 January 2015
Line 45:		Line 45:

	Although there are various advantages to timeboxing, little known except in the expert-Scrum community is that that original HBR paper introducing the roots of Scrum, and re-iterate by Jeff Sutherland (the co-creator of modern Scrum) is that being able to skillfully working in a strict timebox is only the first phase of Scrum adoption. In fact there is Type-A (standard Scrum), Type-B, and Type-C (or 1, 2, 3) types of Scrum. ''AFTER'' a product group mastered timeboxing and worked out all the weaknesses that it reveals (and not before!), there is "Type C Scrum" in which a team is working in something close to continuous flow and continuous delivery. And that's part of Scrum! But you've gotta walk before you can run		Although there are various advantages to timeboxing, little known except in the expert-Scrum community is that that original HBR paper introducing the roots of Scrum, and re-iterate by Jeff Sutherland (the co-creator of modern Scrum) is that being able to skillfully working in a strict timebox is only the first phase of Scrum adoption. In fact there is Type-A (standard Scrum), Type-B, and Type-C (or 1, 2, 3) types of Scrum. ''AFTER'' a product group mastered timeboxing and worked out all the weaknesses that it reveals (and not before!), there is "Type C Scrum" in which a team is working in something close to continuous flow and continuous delivery. And that's part of Scrum! But you've gotta walk before you can run
		+

	== Oh, Scrum is Too Inefficient for Analysis, Estimation, Planning, etc. ==		== Oh, Scrum is Too Inefficient for Analysis, Estimation, Planning, etc. ==

@@ Line 44: / Line 44: @@
 == Beyond Timeboxing within Scrum: Type C (Type 3) Scrum ==
-Although there are various advantages to timeboxing, little known except in the except in the expert-Scrum community is that that original HBR paper introducing the roots of Scrum, and re-iterate by Jeff Sutherland (the co-creator of modern Scrum) is that being able to skillfully working in a strict timebox is only the first phase of Scrum adoption. In fact there is Type-A (standard Scrum), Type-B, and Type-C (or 1, 2, 3) types of Scrum. ''AFTER'' a product group mastered timeboxing and worked out all the weaknesses that it reveals (and not before!), there is "Type C Scrum" in which a team is working in something close to continuous flow and continuous delivery. And that's part of Scrum! But you've gotta walk before you can run
+Although there are various advantages to timeboxing, little known except in the expert-Scrum community is that that original HBR paper introducing the roots of Scrum, and re-iterate by Jeff Sutherland (the co-creator of modern Scrum) is that being able to skillfully working in a strict timebox is only the first phase of Scrum adoption. In fact there is Type-A (standard Scrum), Type-B, and Type-C (or 1, 2, 3) types of Scrum. ''AFTER'' a product group mastered timeboxing and worked out all the weaknesses that it reveals (and not before!), there is "Type C Scrum" in which a team is working in something close to continuous flow and continuous delivery. And that's part of Scrum! But you've gotta walk before you can run
 == Oh, Scrum is Too Inefficient for Analysis, Estimation, Planning, etc. ==

@@ Line 45: / Line 45: @@
 Although there are various advantages to timeboxing, little known except in the except in the expert-Scrum community is that that original HBR paper introducing the roots of Scrum, and re-iterate by Jeff Sutherland (the co-creator of modern Scrum) is that being able to skillfully working in a strict timebox is only the first phase of Scrum adoption. In fact there is Type-A (standard Scrum), Type-B, and Type-C (or 1, 2, 3) types of Scrum. ''AFTER'' a product group mastered timeboxing and worked out all the weaknesses that it reveals (and not before!), there is "Type C Scrum" in which a team is working in something close to continuous flow and continuous delivery. And that's part of Scrum! But you've gotta walk before you can run
 == Oh, Scrum is Too Inefficient for Analysis, Estimation, Planning, etc. ==
@@ Line 56: / Line 57: @@
 Another common shifting of blame to Scrum is related to new teams. The organization previously had single-function teams and there is an extraordinary knowledge and skill debt in the group as a result. And massive levels of WIP and handoff waste. But all this is hidden within by organizational systems other than Scrum, which is based on cross-functional and multi-skilled flexible workers. When the group moves to Scrum and the huge knowledge debt (and weak workers) is exposed, there is a lot of learning and improvement to do to addresses those weakness. In the pre-Scrum (or "post-Scrum") group, there's the illusion of local optimization and it seems all very efficient from a local perspective. But from the systems perspective, there are massive weaknesses. But groups don't want to pay down that knowledge debt or address these weaknesses, and then say, "Oh, we have advanced beyond Scrum." Sure. ;)

@@ Line 44: / Line 44: @@
 == Beyond Timeboxing within Scrum: Type C (Type 3) Scrum ==
-Although there are various advantages to Scrum, little known except in the except in the expert-Scrum community is that that original HBR paper introducing the roots of Scrum, and re-iterate by Jeff Sutherland (the co-creator of modern Scrum) is that being able to skillfully working in a strict timebox is only the first phase of Scrum adoption. In fact there is Type-A (standard Scrum), Type-B, and Type-C (or 1, 2, 3) types of Scrum. ''AFTER'' a product group mastered timeboxing and worked out all the weaknesses that it reveals (and not before!), there is "Type C Scrum" in which a team is working in something close to continuous flow and continuous delivery. And that's part of Scrum! But you've gotta walk before you can run
+Although there are various advantages to timeboxing, little known except in the except in the expert-Scrum community is that that original HBR paper introducing the roots of Scrum, and re-iterate by Jeff Sutherland (the co-creator of modern Scrum) is that being able to skillfully working in a strict timebox is only the first phase of Scrum adoption. In fact there is Type-A (standard Scrum), Type-B, and Type-C (or 1, 2, 3) types of Scrum. ''AFTER'' a product group mastered timeboxing and worked out all the weaknesses that it reveals (and not before!), there is "Type C Scrum" in which a team is working in something close to continuous flow and continuous delivery. And that's part of Scrum! But you've gotta walk before you can run
 == Oh, Scrum is Too Inefficient for Analysis, Estimation, Planning, etc. ==

← Older revision		Revision as of 01:36, 25 January 2015
Line 57:		Line 57:

	Another common shifting of blame to Scrum is related to new teams. The organization previously had single-function teams and there is an extraordinary knowledge and skill debt in the group as a result. And massive levels of WIP and handoff waste. But all this is hidden within by organizational systems other than Scrum, which is based on cross-functional and multi-skilled flexible workers. When the group moves to Scrum and the huge knowledge debt (and weak workers) is exposed, there is a lot of learning and improvement to do to addresses those weakness. In the pre-Scrum (or "post-Scrum") group, there's the illusion of local optimization and it seems all very efficient from a local perspective. But from the systems perspective, there are massive weaknesses. But groups don't want to pay down that knowledge debt or address these weaknesses, and then say, "Oh, we have advanced beyond Scrum." Sure. ;)		Another common shifting of blame to Scrum is related to new teams. The organization previously had single-function teams and there is an extraordinary knowledge and skill debt in the group as a result. And massive levels of WIP and handoff waste. But all this is hidden within by organizational systems other than Scrum, which is based on cross-functional and multi-skilled flexible workers. When the group moves to Scrum and the huge knowledge debt (and weak workers) is exposed, there is a lot of learning and improvement to do to addresses those weakness. In the pre-Scrum (or "post-Scrum") group, there's the illusion of local optimization and it seems all very efficient from a local perspective. But from the systems perspective, there are massive weaknesses. But groups don't want to pay down that knowledge debt or address these weaknesses, and then say, "Oh, we have advanced beyond Scrum." Sure. ;)
		+
		+
		+
		+	== Really Advanced ==
		+
		+	You've got a group of 5 teams working on 1 product, with true continuous delivery, great code, a real flow of value without pause or impediment, continuous learning and improvement, simple practices, etc.? Great. We in the Scrum community salute you!

← Older revision		Revision as of 01:34, 25 January 2015
Line 1:		Line 1:
		+	== Introduction ==
		+
	Sometimes i hear, "Oh, those Scrum practices of timeboxes, etc., are too basic or wasteful. We've advanced far beyond Scrum!"		Sometimes i hear, "Oh, those Scrum practices of timeboxes, etc., are too basic or wasteful. We've advanced far beyond Scrum!"

@@ Line 15: / Line 15: @@
 Another reason for "being too advanced for Scrum" is not understanding the benefits of the practices.
 == Timeboxing ==
@@ Line 38: / Line 39: @@
 * Humans are probably more sensitive to time variation than to scope variation—“It was late” is remembered more strongly than, “It had less than I wanted.” Timeboxing avoids the erosion of confidence that happens for business stakeholders when product development people say, yet again, “... maybe in one more week it will all be done.”
-type 3

@@ Line 3: / Line 3: @@
 First, if that's really true, i'm really happy to see a group that's done so much deep improvement. There are exceptions to what am about to describe, and for those exceptions, i say, "Good for you!"
 But what I actually ''see'' when i go to ''gemba'' (not in a room with managers telling me their state) in almost every one of these cases of claimed advancement is not that they have advanced beyond Scrum, but that something else is going on. What's that?
 It's that adopting real by-the-book standard Scrum exposed weaknesses that the group did not want to deal with. And as a variation, the group is demonstrating [[Larman's Laws of Organizational Behavior]] and hiding the self-serving efforts by specialists and managers to maintain their privileged status-quo positions. How? By shifting attention away from their desire to cling to the status quo by claiming, "We are more advanced than Scrum", which really means "We don't want to change in any way that would challenge our positions."
 So for example, a group of 5 teams working on one product together is actually ''unable'' to be disciplined and efficient and effective enough to work in a 2-week timebox and deliver a "done" product increment and ship it. Rather than fix the root cause problems, they shift the problem and say, "Scrum doesn't work here, let's try Kanban." Or, "We're more advanced than Scrum."
 type 3

← Older revision		Revision as of 01:09, 25 January 2015
Line 1:		Line 1:
	Sometimes i hear, "Oh, those Scrum practices of timeboxes, etc., are too basic or wasteful. We've advanced far beyond Scrum!"		Sometimes i hear, "Oh, those Scrum practices of timeboxes, etc., are too basic or wasteful. We've advanced far beyond Scrum!"
		+

	First, if that's really true, i'm really happy to see a group that's done so much deep improvement. There are exceptions to what am about to describe, and for those exceptions, i say, "Good for you!"		First, if that's really true, i'm really happy to see a group that's done so much deep improvement. There are exceptions to what am about to describe, and for those exceptions, i say, "Good for you!"