That's extremely nice, especially for hardware engineering. Unfortunately on software it breaks a bit. Like for example, a proper machinist can tell you with a very high degree of accuracy how many cuts a particular part will need as well as the tools needed. That is usually offset by accidents (endmill breaking, tool breakdowns, etc). But low level operations are generally nailed down every step of the way. A piece may take 30 low level ops to complete and maybe 1-2 disruptions/month on the project level. In software, you are looking at several thousand low level ops for a daily task. Properly naming a variable, restructuring code, even an if statement, they all are meaningful. While a workpiece on certain faces may have a couple of thou tolerance, in software engineering at the functional level, the idea of tolerance does not exist. Further, disruptors, at the project level come just about twice a week. At the developer level can be as high as several times a day on the more complicated bodies of work. The initial cone of error for any software project is 180 degrees. Worsened by the fact that nobody knows anything about the actual details of a project. It's impossible. You can't know anything about something which has not been created ever. On the other hand, there are ways to bring in some certainty. For starters, it is far easier than hardware to learn more about the details of the most important aspects. And yes, projections do also increase in accuracy over time... Provided someone from sales does not sell your product to the wrong customer with a bundle of unrealistic promises (Ask me how i know.). So, in software engineering you get budget for exploring a project rather than committing. If trends appear, you either pull the plug or start selling.
It's about levels of degree and relative sizing to other work. It is not about accurate tasks estimating. This was born in software, not hardware, and several years of use in Toyota and other companies has proven its utility. It is not perfect, but nothing is. It does rely on people with the knowledge of the work and experience doing it. Thanks for the great reply.
Excellent video, very well explained. One area I need more clarification on is how can the team exactly determine how they will implement their work and how much effort is needed in the initial phase as a lot of things are unknown and can only be learned once the actual work starts?
This approach is meant for teams that have worked together for a while and have a good understanding of the work context and the skills and knowledge necessary. If this is a new team and/or a very new area of work, then they will have to run some experiments (do some Scrum) to refine their knowledge to be able to use this approach effectively. What I normally do is have them execute the first few backlog items which then gives them their base understanding to use this approach. Remember, in project management all they do is wild guess and hope it was right.
Thanks for providing this Nigel - it is a great presentation of what looks to be a very good technique. The challenge I always seem to run into with these approaches is the forecast is for a new team that has no historical velocity. Have you used this technique for new teams and if so, how did you predict their velocity?
Mike, new teams have to establish a known velocity for any accuracy. The key thing is the people doing the work estimate the work. To begin with estimates will be poor, even bad. As we continuously review them every sprint they improve. This is not just an agile phenomena, it impacts all teams who have to estimate (educated guessing) the size of a work commitment. The rule of thumb is 3 sprints in gets you to a point you can start to forecast with some confidence, but forecasts are updated every sprint. In the absence of any known velocity or say a new team, unknown work, uncertain skills, all we have if the affinity scale. S/M/L/XL etc and our experience to start from. Even this will be better than plain old guessing. I would also spend a lot of time discussing the work and using past experiences and collective wisdom of the crowd as a starting point. Once they start working together better estimates will emerge. Hope this helps a bit.
Then you need to do some work. This technique requires familiarity with the context and subject. It’s the same in any case if you have no knowledge or experience or expertise then you’re just taking wild guesses. My own experience is that once you have a team then can size. Velocity can be measured after 2-3 sprints to gain a moving average to help you predict. Any technique requires some historical data to be able to predict.
That's extremely nice, especially for hardware engineering. Unfortunately on software it breaks a bit.
Like for example, a proper machinist can tell you with a very high degree of accuracy how many cuts a particular part will need as well as the tools needed. That is usually offset by accidents (endmill breaking, tool breakdowns, etc). But low level operations are generally nailed down every step of the way. A piece may take 30 low level ops to complete and maybe 1-2 disruptions/month on the project level.
In software, you are looking at several thousand low level ops for a daily task. Properly naming a variable, restructuring code, even an if statement, they all are meaningful. While a workpiece on certain faces may have a couple of thou tolerance, in software engineering at the functional level, the idea of tolerance does not exist. Further, disruptors, at the project level come just about twice a week. At the developer level can be as high as several times a day on the more complicated bodies of work.
The initial cone of error for any software project is 180 degrees. Worsened by the fact that nobody knows anything about the actual details of a project. It's impossible. You can't know anything about something which has not been created ever.
On the other hand, there are ways to bring in some certainty. For starters, it is far easier than hardware to learn more about the details of the most important aspects. And yes, projections do also increase in accuracy over time... Provided someone from sales does not sell your product to the wrong customer with a bundle of unrealistic promises (Ask me how i know.).
So, in software engineering you get budget for exploring a project rather than committing. If trends appear, you either pull the plug or start selling.
It's about levels of degree and relative sizing to other work. It is not about accurate tasks estimating. This was born in software, not hardware, and several years of use in Toyota and other companies has proven its utility. It is not perfect, but nothing is. It does rely on people with the knowledge of the work and experience doing it. Thanks for the great reply.
I am unsure what heresy I have just witnessed, but I frickin' love it.
Great one Nigel..liked the overall approach..
Brilliant explanation!!! Nailed it
Completely blown away Nigel, great content and look forward to more of your videos .
Thank you. The good news is it works!
Thank you very much. It can be easier to understand if something like this is accompanied with specific examples and details.
I will look into creating a follow up with some real world examples from the past.
@@NigelThurlow Sounds wonderful, thanks! I subscribed to the channel.
Awesome Video. so glad to have been able to learn firsthand from you
Great one..
Fantastic technique Nigel. I will start implementation of this technique soon in my organisation.
Amazing!
Thanks!
Brilliant!
This was helpful Nigel! Thank you. Subscribing to your channel right away!
Awesome, thank you!
Great content!
I have been building something very very similar and this video helped me to complete my project and fill some gaps. Thank you.
Glad it helped!
Incredible video. Is there any tools or spreadsheets that you use yourself to help try this out ?
Excellent video, very well explained. One area I need more clarification on is how can the team exactly determine how they will implement their work and how much effort is needed in the initial phase as a lot of things are unknown and can only be learned once the actual work starts?
This approach is meant for teams that have worked together for a while and have a good understanding of the work context and the skills and knowledge necessary. If this is a new team and/or a very new area of work, then they will have to run some experiments (do some Scrum) to refine their knowledge to be able to use this approach effectively. What I normally do is have them execute the first few backlog items which then gives them their base understanding to use this approach. Remember, in project management all they do is wild guess and hope it was right.
Thanks for providing this Nigel - it is a great presentation of what looks to be a very good technique. The challenge I always seem to run into with these approaches is the forecast is for a new team that has no historical velocity. Have you used this technique for new teams and if so, how did you predict their velocity?
Mike, new teams have to establish a known velocity for any accuracy. The key thing is the people doing the work estimate the work. To begin with estimates will be poor, even bad. As we continuously review them every sprint they improve. This is not just an agile phenomena, it impacts all teams who have to estimate (educated guessing) the size of a work commitment. The rule of thumb is 3 sprints in gets you to a point you can start to forecast with some confidence, but forecasts are updated every sprint. In the absence of any known velocity or say a new team, unknown work, uncertain skills, all we have if the affinity scale. S/M/L/XL etc and our experience to start from. Even this will be better than plain old guessing. I would also spend a lot of time discussing the work and using past experiences and collective wisdom of the crowd as a starting point. Once they start working together better estimates will emerge. Hope this helps a bit.
What if you dont know the velocityh of the team because there is no team yet for this new project?
Then you need to do some work. This technique requires familiarity with the context and subject. It’s the same in any case if you have no knowledge or experience or expertise then you’re just taking wild guesses. My own experience is that once you have a team then can size. Velocity can be measured after 2-3 sprints to gain a moving average to help you predict. Any technique requires some historical data to be able to predict.
Very good video, one question though, how can I do this calculation upfront so I can prepare a fixed bid price to present to the customer ?