Subject: RE: BLOG on "How do Scrum and Critical Chain compare? " - msg#00075

Previous Message by Date: click to view message preview

Re[2]: BLOG on "How do Scrum and Critical Chain compare? "

MC> One thing I will sometimes do differently from "by the book" Scrum is, MC> as you point out, look at task (story) dependencies. However, I don't do MC> that for critical chain planning. Rather, I do it to avoid achieving a MC> local optimization to the work of a sprint. Suppose a sprint includes 26 MC> things to do, labeled a through z. They can be done in any order except MC> a, b, and c must be done in order. As a ScrumMaster I train the team to MC> look for sequences like that and make sure they start those types of MC> tasks as early as possible in a sprint. There are normally very few of MC> these in a sprint so this is a pretty small change and it's really just MC> how we think about the work of a sprint. However, it helps avoid a MC> situation where the sequential tasks a, b, c are all left for the last MC> day and even though there are three developers and three days left of MC> work we just can't do the work in one chronological day. One thing that I get a real kick out of when I work with new teams is showing them how software related sequencing dependencies are an illusion. If you can define an interface, you can work in parallel. That just leaves tooling tasks where someone is going to use something developed earlier in an iteration to do additional work in an iteration. As much as possible, I like to get teams to finesse those by having someone sign for both the creation and the use. It's hard medicine, but I really like to push it because I run into teams all the time who believe that they have sequencing dependencies when they really don't. Michael Feathers www.objectmentor.com

Next Message by Date: click to view message preview

RE: Re[2]: BLOG on "How do Scrum and Critical Chain compare? "

If the team is doing TDD, they also need to learn how to mock an interface that has not yet been implemented. Of course, this is an important technique to learn anyway. -----Original Message----- From: Michael Feathers [mailto:mfeathers@xxxxxxxxxxxxxxxx] Sent: Tue 11/18/2003 8:58 AM To: Mike Cohn Cc: Subject: Re[2]: [scrumdevelopment] BLOG on "How do Scrum and Critical Chain compare? " MC> One thing I will sometimes do differently from "by the book" Scrum is, MC> as you point out, look at task (story) dependencies. However, I don't do MC> that for critical chain planning. Rather, I do it to avoid achieving a MC> local optimization to the work of a sprint. Suppose a sprint includes 26 MC> things to do, labeled a through z. They can be done in any order except MC> a, b, and c must be done in order. As a ScrumMaster I train the team to MC> look for sequences like that and make sure they start those types of MC> tasks as early as possible in a sprint. There are normally very few of MC> these in a sprint so this is a pretty small change and it's really just MC> how we think about the work of a sprint. However, it helps avoid a MC> situation where the sequential tasks a, b, c are all left for the last MC> day and even though there are three developers and three days left of MC> work we just can't do the work in one chronological day. One thing that I get a real kick out of when I work with new teams is showing them how software related sequencing dependencies are an illusion. If you can define an interface, you can work in parallel. That just leaves tooling tasks where someone is going to use something developed earlier in an iteration to do additional work in an iteration. As much as possible, I like to get teams to finesse those by having someone sign for both the creation and the use. It's hard medicine, but I really like to push it because I run into teams all the time who believe that they have sequencing dependencies when they really don't. Michael Feathers www.objectmentor.com ------------------------ Yahoo! Groups Sponsor ---------------------~--> KnowledgeStorm has over 22,000 B2B technology solutions. The most comprehensive IT buyers' information available. Research, compare, decide. E-Commerce | Application Dev | Accounting-Finance | Healthcare | Project Mgt | Sales-Marketing | More http://us.click.yahoo.com/IMai8D/UYQGAA/cIoLAA/9EfwlB/TM ---------------------------------------------------------------------~-> To Post a message, send it to: scrumdevelopment@xxxxxxxxxxx To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@xxxxxxxxxxx Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ <<winmail.dat>>

Previous Message by Thread: click to view message preview

RE: Re[2]: BLOG on "How do Scrum and Critical Chain compare? "

Exactly. There are very few things that we can't do in parallel. There may be a few things may be better done in a specific sequence but that's normally because we're comfortable working a certain way (e.g., add columns to a database table before coding a change that uses them). -----Original Message----- From: Michael Feathers [mailto:mfeathers@xxxxxxxxxxxxxxxx] Sent: Tuesday, November 18, 2003 8:59 AM To: Mike Cohn Subject: Re[2]: [scrumdevelopment] BLOG on "How do Scrum and Critical Chain compare? " MC> One thing I will sometimes do differently from "by the book" Scrum is, MC> as you point out, look at task (story) dependencies. However, I don't do MC> that for critical chain planning. Rather, I do it to avoid achieving a MC> local optimization to the work of a sprint. Suppose a sprint includes 26 MC> things to do, labeled a through z. They can be done in any order except MC> a, b, and c must be done in order. As a ScrumMaster I train the team to MC> look for sequences like that and make sure they start those types of MC> tasks as early as possible in a sprint. There are normally very few of MC> these in a sprint so this is a pretty small change and it's really just MC> how we think about the work of a sprint. However, it helps avoid a MC> situation where the sequential tasks a, b, c are all left for the last MC> day and even though there are three developers and three days left of MC> work we just can't do the work in one chronological day. One thing that I get a real kick out of when I work with new teams is showing them how software related sequencing dependencies are an illusion. If you can define an interface, you can work in parallel. That just leaves tooling tasks where someone is going to use something developed earlier in an iteration to do additional work in an iteration. As much as possible, I like to get teams to finesse those by having someone sign for both the creation and the use. It's hard medicine, but I really like to push it because I run into teams all the time who believe that they have sequencing dependencies when they really don't. Michael Feathers www.objectmentor.com To Post a message, send it to: scrumdevelopment@xxxxxxxxxxx To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@xxxxxxxxxxx Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

Next Message by Thread: click to view message preview

RE: BLOG on "How do Scrum and Critical Chain compare? "

I've never had to really negotiate on every thing that gets added to the backlog. In the past I've sold clients on the approach and the techniques. I show them why a project will take as long as I think (normally faster or the same as most companies would bid but sometimes undercut by companies who lie/mis-estimate) then tell them to cut us off when we've done enough functionality that they're happy. On something we think is 7 sprints that could be in 5-7 sprints; or longer if they keep coming up with good ideas. -----Original Message----- From: Steven Gordon [mailto:sagordon@xxxxxxx] Sent: Tuesday, November 18, 2003 9:31 AM To: scrumdevelopment@xxxxxxxxxxxxxxx Subject: RE: [scrumdevelopment] BLOG on "How do Scrum and Critical Chain compare? " Mike, I have not read your blog yet - I was just noting what I always thought was a contradiction between the approaches. I am under the impression that the modeling the distribution of tasks using an average estimate and worst case estimate predates Critical Chain, and therefore consider the distinguishing feature of Critical Chain to be the modeling of how these distributions of task lengths (along with resource constraints) causes dynamic changes in which path turns out to be the functionally critical path. My impression could be wrong. Your method certainly seems sound. I recall once seeing a statistical justification of this type of estimation approach assuming a task length distribution that looked normal between 0 and the mean, and skewed after the mean. I would add that my experience is that the tasks upon which the most other tasks are dependent tend to be the most central tasks in the system. These are usually of the tasks with the greatest business value, and are the ones that allow you to most quickly deliver a skeletal system that works end to end. So, it usually makes sense to work on these tasks first, both for business value to your customer and to help your customer evolve their understanding of what they really need as soon as possible. Of course, I do not believe you can really project how the backlog will have changed 6-7 sprints ahead; afterall, learning and adapting is a big part of the reason you are using Scrum. So, I assume you are forced to "negotiate" the impact of every task that gets added to the backlog during the course of the project. Steven Gordon -----Original Message----- From: Mike Cohn [mailto:mike@xxxxxxxxxxxxxxxxxxxxxxxx] Sent: Tue 11/18/2003 8:39 AM To: scrumdevelopment@xxxxxxxxxxxxxxx Cc: Subject: RE: [scrumdevelopment] BLOG on "How do Scrum and Critical Chain compare? " Steve- You're right that this is not a full typical critical chain application but I've never found it necessary to look into ways to consider adding feeding buffers within a sprint. (On one large project we did use feeding buffers when there were many scrum teams involved.) One thing I will sometimes do differently from "by the book" Scrum is, as you point out, look at task (story) dependencies. However, I don't do that for critical chain planning. Rather, I do it to avoid achieving a local optimization to the work of a sprint. Suppose a sprint includes 26 things to do, labeled a through z. They can be done in any order except a, b, and c must be done in order. As a ScrumMaster I train the team to look for sequences like that and make sure they start those types of tasks as early as possible in a sprint. There are normally very few of these in a sprint so this is a pretty small change and it's really just how we think about the work of a sprint. However, it helps avoid a situation where the sequential tasks a, b, c are all left for the last day and even though there are three developers and three days left of work we just can't do the work in one chronological day. This same problem can happen with any process that doesn't take a step back and look at sequence-Scrum, XP, etc. Good developers just seem to know to think about it and 95% of the time think about subconsciously without any problem (e.g., we all know to finish the code on Thursday so the integration test and some exploratory testing can happen on Friday). Here's why I don't worry about task dependencies to determine my project buffer. I have never convinced myself 100% that the math and logic here work out perfectly but I think they do and in practice it works better than I could hope for. If you can help convince me it's truly right I'll owe you one! I assume that for a sprint everyone will be 100% busy on the sprint. This doesn't mean ideal time = calendar time, just that we're working on nothing but this sprint. I assume (and make sure) that tasks are small enough and dependencies infrequent enough that some optimal solution can be worked out such that the work the team selects for the sprint can be done in the sprint. That is, if I wanted to I could sequence the tasks so that they could all be completed. I assume that the team will work out that optimal solution as the sprint progresses (that is they self-organize around that goal). I assume that I do not need to buffer the completion dates of any tasks in the sprint but what I need to buffer is either that sprint or, more likely a series of sprints (a release). Given all that, I do the math recommended by Reinertsen or Larry Leach to come up with a buffered schedule. Here's an example. The columns are estimates in days of six items on the product backlog. The first column is the 90% confident estimate, the next is the 50% estimate, the final is the squared difference of the two. 90% 50% (90%-50%)^2 7 2 25 5 2 9 2 2 0 8 5 9 4 2 4 5 3 4 Sum the squared differences and get 51. Take the square root of that and get about 7. The seven is the project buffer. Add that to the sum of the 50% estimates (16) and get 23. So, to buffer this project to a 90% level of confidence you should plan on 23 days, not the 16 that is the sum of the 50% estimates or the 31 that is the sum of the 90% estimates. Naturally this doesn't add a lot of value when there are only this many tasks. Suppose instead though that for a larger project this process estimates 135 days of work-that would translate into 6.75 sprints (I use 20 working days per sprint) so I'd tell the product owner to plan on 7 sprints. If I didn't do this process and we needed to give the product owner (typically someone paying for outsourced development in these cases) an estimate we could have given them (a) the sum of the 90% estimates but then we'd never get the work and the estimate would be too high anyway (rarely does *everything* take the longest amount of time); (b) the sum of the 50% tasks in which case we'd get the job but we'd never finish on time (completion times are not normally distributed and rarely would *everything* finish near it's minimum time) or do (c) something else which for projects of this size I find typically underestimate the work by 1-2 sprints and then the team has a huge challenge of sticking to their quality discipline as time runs out on them. So, it's Scrum with just a dash of TOC into the planning phase. --Mike -----Original Message----- From: Steven Gordon [mailto:sagordon@xxxxxxx] Sent: Monday, November 17, 2003 2:37 PM To: scrumdevelopment@xxxxxxxxxxxxxxx Subject: RE: [scrumdevelopment] BLOG on "How do Scrum and Critical Chain compare? " Mike, How do you obtain task dependencies? My understanding of a backlog is that it is a flat list of tasks (or possibly a priority queue). Furthermore, if you are using XP for your development methodology, it generally works out that one can implement tasks in any order without much impact on development time due to task isolation via small specific stories and stand-alone automated unit tests and acceptance tests. Lacking critical task dependencies, Critical Chain does not seem to offer much over just summing up estimates. Steven A. Gordon, Ph.D. Manager, Software Factory Arizona State University PO Box 875506 Tempe, AZ 85287-9509 http://sf.asu.edu <http://sf.asu.edu/> (480)-727-6271 -----Original Message----- From: Mike Cohn [mailto:mike@xxxxxxxxxxxxxxxxxxxxxxxx] Sent: Monday, November 17, 2003 2:24 PM To: scrumdevelopment@xxxxxxxxxxxxxxx Subject: RE: [scrumdevelopment] BLOG on "How do Scrum and Critical Chain compare? " In Clarke's message on Hal's blog he notes that he doesn't think anyone is combining Scrum together with Critical Chain. I've been combining the two since 1999 and agree that they are quite synergistic. I use Critical Chain techniques to provide an upfront forecast of how long a project will take. On our projects we collect two estimates for each item on the backlog (our backlog is generally in the form of XP stories). The first estimate is the "50% estimate" that represents how long something should take to code. If the programmer coded it 100 times this would be the time she'd take for the median. The second estimate is a 90% estimate--this is the "worst case" but not the *worst* in that no buses run anyone over, the source repository doesn't crash two seconds before backup and the building doesn't burn down. It's a realistic worst case. From these estimates we extrapolate a "project buffer". We then sum up the 50% estimates and add to them the project buffer to come up with the number of sprints we think something will take. It's been amazingly effective looking as far out as 9 months. (I haven't tried anything longer and don't really plan to.) So, we use CC to help give our Product Owner a more informed guess at the beginning and then once a sprint starts it's pretty much by-the-book Scrum. --Mike -----Original Message----- From: Deb [mailto:deborah@xxxxxxxxxxxx] Sent: Monday, November 17, 2003 8:37 AM To: scrumdevelopment@xxxxxxxxxxxxxxx Subject: [scrumdevelopment] BLOG on "How do Scrum and Critical Chain compare? " Thought some of you might be interested in this entry on Hal Macomber's "Reforming Project Management" site: "How Do Scrum and CCPM Compare? This posting came from Clarke Ching, Scotland, writing in the TOC Experts Yahoo! Group on November 10...." see: http://weblog.halmacomber.com/2003_11_09_archive.html#1068822436734154 87 To Post a message, send it to: scrumdevelopment@xxxxxxxxxxx To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@xxxxxxxxxxx Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ To Post a message, send it to: scrumdevelopment@xxxxxxxxxxx To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@xxxxxxxxxxx Your use of Yahoo! Groups is subject to the Yahoo! <http://docs.yahoo.com/info/terms/> Terms of Service. Yahoo! Groups Sponsor ADVERTISEMENT <http://rd.yahoo.com/SIG=12c1f53uv/M=243273.4156324.5364586.1261774/D=egroup web/S=1707209021:HM/EXP=1069191460/A=1750744/R=0/*http:/servedby.advertising .com/click/site=552006/bnum=1069105060342543> Click to learn more... <http://us.adserver.yahoo.com/l?M=243273.4156324.5364586.1261774/D=egroupmai l/S=:HM/A=1750744/rand=806912783> To Post a message, send it to: scrumdevelopment@xxxxxxxxxxx To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@xxxxxxxxxxx Your use of Yahoo! Groups is subject to the Yahoo! <http://docs.yahoo.com/info/terms/> Terms of Service. To Post a message, send it to: scrumdevelopment@xxxxxxxxxxx To Unsubscribe, send a blank message to: scrumdevelopment-unsubscribe@xxxxxxxxxxx Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/