tag:blogger.com,1999:blog-3491762.post3613136522029149907..comments2023-10-22T06:10:35.936-04:00Comments on Scrum Log Jeff Sutherland: Getting Lean with ScrumJeff Sutherlandhttp://www.blogger.com/profile/07761053439034726679noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-3491762.post-44350253226547097712012-11-07T06:49:34.795-05:002012-11-07T06:49:34.795-05:00This is explained in the Hyperproductive Metrics p...This is explained in the Hyperproductive Metrics paper that will be published at HICSS in January. It is on this site (click on Jeff's Sutherland's Papers on the right side of this page). It is also on the Agile 2012 site. Velocity is always based on story points. Story point inflation is avoided by proper estimation using good reference stories. For high performing teams, stories are small so inflation becomes very easy to control. A good product owner will scream if she sees inflation so that is the first line of defense.Jeff Sutherlandhttps://www.blogger.com/profile/07761053439034726679noreply@blogger.comtag:blogger.com,1999:blog-3491762.post-88859694094050293222012-11-07T06:33:36.736-05:002012-11-07T06:33:36.736-05:00Right, so when you say the "velocity triples&...Right, so when you say the "velocity triples", what do you mean? How are you measuring velocity? With story point estimations?<br /><br />This is what I'm trying to get you to answer - what is the measure of productivity/velocity that you are increasing, and how do you know that productivity has genuinely increased instead of, for example, story point inflation?Neil Killickhttps://www.blogger.com/profile/09138781355943719626noreply@blogger.comtag:blogger.com,1999:blog-3491762.post-15634740343159812652012-11-07T06:15:50.916-05:002012-11-07T06:15:50.916-05:00The focus on Scrum is to build less, delivery earl...The focus on Scrum is to build less, delivery early, and through customer feedback build a great product. Working with our investment group we now have investments in 20 Scrum companies. We focus the initial effort on implementing Scrum properly so the velocity will triple. We then spend 80% of our time working with the product owners to get the right product strategy. These usually forces us to work at the CEO level to clarify the business strategy and market before the product owner can function well. Our view is that slow teams are useless and their quality is terrible. Good Scrum will fix that immediately with three sprints (3-6 weeks). We don't tolerate sloppy Scrum.Jeff Sutherlandhttps://www.blogger.com/profile/07761053439034726679noreply@blogger.comtag:blogger.com,1999:blog-3491762.post-66590881038962773072012-10-30T19:26:34.236-04:002012-10-30T19:26:34.236-04:00Not at all, I'm not sure how you gleaned that ...Not at all, I'm not sure how you gleaned that from my comments.<br /><br />I'm very interested in what you're saying though. There is no mention of "velocity" in the Scrum Guide, and I agree fully with your sentiment about velocity increases. So my question remains - how do teams measure productivity in the context of developing software in order to determine quantitative gains, such as those cited by Nonaka and Takeuichi? With cars and car parts it is far easier (on the production line a spark plug for a Prius is the same as another Prius spark plug, and one Prius is the same as the next).<br /><br />How do we measure working software in such terms?Neil Killickhttps://www.blogger.com/profile/09138781355943719626noreply@blogger.comtag:blogger.com,1999:blog-3491762.post-43484899980094721862012-10-30T09:08:29.969-04:002012-10-30T09:08:29.969-04:00In Scrum we only increase velocity by removing imp...In Scrum we only increase velocity by removing impediments. This increases quality. In a properly implemented Scrum, quality improvement drives velocity. Are you proposing we reduce quality?Jeff Sutherlandhttps://www.blogger.com/profile/07761053439034726679noreply@blogger.comtag:blogger.com,1999:blog-3491762.post-66466580872763863392012-10-30T02:46:33.646-04:002012-10-30T02:46:33.646-04:00Hi Jeff,
I understand Scrum's roots in Lean a...Hi Jeff,<br /><br />I understand Scrum's roots in Lean and the organisational goals that can be achieved using Scrum. But in order to achieve such goals the organisation needs to take a broader approach to removing inefficiencies. Focusing purely on the Scrum team(s) producing more seems counter-productive.<br /><br />Isn't Scrum more about building the best possible product(s) in a given timeframe? Having business goals like getting better at delivering quality software, being more predictable for the purposes of planning, getting to market more quickly, etc. are noble goals and surely what Scrum is more suited for? Putting the emphasis (i.e. pressure) on teams to increase velocity (which is a bogus measure of productivity) will cause both quality and predictability to suffer. Isn't constant, sustainable pace more important?<br /><br />I don't see how productivity can be measured in a creative, unpredictable pursuit like software development. "Doing more" is not being more productive, because what does "more" actually mean in the context of iterative/incremental delivery? More story points? Story points are relative estimates of product increments with perhaps unconscious target-massaging involved, so surely not.<br /><br />Plus what if the wrong thing is being built? Focusing too much on efficiency (over effectiveness) is the downfall of many teams (and no doubt a contributor to the high failure rate of Scrum).Neil Killickhttps://www.blogger.com/profile/09138781355943719626noreply@blogger.comtag:blogger.com,1999:blog-3491762.post-36873472239850601662012-10-30T02:46:18.175-04:002012-10-30T02:46:18.175-04:00Hi Jeff,
I understand Scrum's roots in Lean a...Hi Jeff,<br /><br />I understand Scrum's roots in Lean and the organisational goals that can be achieved using Scrum. But in order to achieve such goals the organisation needs to take a broader approach to removing inefficiencies. Focusing purely on the Scrum team(s) producing more seems counter-productive.<br /><br />Isn't Scrum more about building the best possible product(s) in a given timeframe? Having business goals like getting better at delivering quality software, being more predictable for the purposes of planning, getting to market more quickly, etc. are noble goals and surely what Scrum is more suited for? Putting the emphasis (i.e. pressure) on teams to increase velocity (which is a bogus measure of productivity) will cause both quality and predictability to suffer. Isn't constant, sustainable pace more important?<br /><br />I don't see how productivity can be measured in a creative, unpredictable pursuit like software development. "Doing more" is not being more productive, because what does "more" actually mean in the context of iterative/incremental delivery? More story points? Story points are relative estimates of product increments with perhaps unconscious target-massaging involved, so surely not.<br /><br />Plus what if the wrong thing is being built? Focusing too much on efficiency (over effectiveness) is the downfall of many teams (and no doubt a contributor to the high failure rate of Scrum).Neil Killickhttps://www.blogger.com/profile/09138781355943719626noreply@blogger.comtag:blogger.com,1999:blog-3491762.post-63102871932666316962012-10-28T09:37:01.888-04:002012-10-28T09:37:01.888-04:00Scrum was designed to give programmers a better li...Scrum was designed to give programmers a better life while achieving 5-10 times as much production with a corresponding increase in quality. Thus it also satisfies investors goals of producing a better product at 10-20% of the normal cost and time. Scrum is based on Lean Product Development teams observed by Nonaka and Takeuchi. For example, the Prius team needed to deliver twice the gas mileage in a production car in half the time.Jeff Sutherlandhttps://www.blogger.com/profile/07761053439034726679noreply@blogger.comtag:blogger.com,1999:blog-3491762.post-9998361819354223382012-10-28T01:35:54.560-04:002012-10-28T01:35:54.560-04:00The statement "sharpening the focus on increa...The statement "sharpening the focus on increased productivity and velocity" interests me, and I have a couple of questions:<br /><br />1. What does productivity look like in software development, and how/why would you want to increase it?<br />2. What leads you to believe that the focus of Scrum is to increase velocity?<br /><br />Thanks.Neil Killickhttps://www.blogger.com/profile/09138781355943719626noreply@blogger.com