Wow thank you! I dedicated my last two years fighting against estimates, making videos about how to get rid of them on the YT channel Scrum Life, and I didn't even see that estimates were removed, thank you for pointing that at me!! :) Well done. For me , beside those two huge things you mentionned, I see the self-managing team important and the role of the Scrum Master as accountable. I don't see the role different for many times, I don't like those who slip away saying "the team didn't want to improve, I can't do much". No, the SM is part of the team, and is responsible for the team to deliver as anyone else, so I agree with that. Also, I like the rework on the review, espacially targeting ways of doing it only as a "demo". On Scrum Life, we tell it for sometimes now: "the review is a business meeting where decisions are made". I feel the new Scrum Guide tells it too now. What do you think?
@@cog_g - Seems we're both fighting the good fight! (Love Scrum Life, BTW the way. C'est le pied!) Interesting to hear (on the launch webinar) stories of "bad behaviour" across all roles: developers that use agile as a reason to work on "whatever they like"; PO's with no sense of direction; and Scrum Masters in (what sounded like) a secretarial role. I've witnessed the first two, but never the last: I guess I've been lucky. But/And I agree with you: things are clearer in regard to the SM's role. I missed the changes related to the Review. I'll take a look!
What are your thoughts on companies requiring Scrum Masters to be project managers as well. I've been seeing that a lot in job postings and in the job description?
@@Developmentthatpays me too..however it doesn't stop there. I'm not sure about other countries, but here in the US..I've seen job descriptions where companies are putting..engineering, computer science, cybersecurity, UX degrees required plus 10+ years of project management required for a Scrum Master. I've been a SM for 6 years and I'm darn good at my job.. it's been really difficult to find work, even before the pandemic.
Excellent video, Gary! I hadn't even noticed that the estimates had been removed! Also, loved your description of your "rocky relationship" with Scrum. Golden :)
@@Developmentthatpays The drama - the music, the frustration, the persuasion, the passion, the mien - bits made me laugh; I loved it. However, sizing or relative sizing is the backbone of planning and performance measurement in Scrum. Alternatively what is your preferred approach, as sizing will always be relative and not accurate.
Nice analysis. For me, the thing that caught my eye was 2 parts, the removal of structure for the Daily Scrum, which I agree with, but I think that teams new to Scrum need a starting point. The 2nd thing that caught my eye was the redefinition of what a team is.
There were a couple of things that were removed - including the 3 Questions. I did wonder if that would make things harder for teams coming to Scrum for the first time. Agree that the team redefinition is a good move. I wonder why they went with "developers", rather than something less "software". Something to watch for next time!
I just read it, and I have to say that I like they considered some experiences I have lived. I loved they focused on data in order to forecast and they clarify that a scrum team doesn't need to wait until sprint review to release an increment
You sent me scurrying back to the Scrum Guide to look for "forecast". Is this the passage you're referring to: "Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making." ? _I completely missed this!_ I HATE burn-ups/burn-downs; *delighted* to see them thrown under the bus!
@@Developmentthatpays I think tracking progress is useful using a burn-up, it's useful if we use that historic data to forecast when the team would deliver a number specific of items (on a probabilistic way)
You have also highlighted something else here. The definition of Done (DoD) is the artifact for the 'Increment' not the Sprint and as we don't need to wait to the end of the sprint for the increment to be complete we have a clearer/different view on release management.
Excellent point! I was also interested to see the change in wording around the "increment". We're always adding to the adding to the product, and I always (mistakingly?) thought of the "increment" as the "bit that was added", while the (previous version of) Scrum Guide implied that "increment" was the "new whole". The new language seems to have moved in my direction. I'd be interested to hear how you read it.
Introduction of the Project Goal is something I always had to promote. Agile is good and efficient, when you set a long-range target. Without such a 'lighthouse' making iteration steps most often leads to walking in a circle. Whrn I used to start projects and guide our BAs tgrough them, I even had to develop my own approach to formulate the target (i.e. a Product Goal), and it proved to help in all aspects from generating PFBs and WBSs to setting OKRs and KPIs. Scrum-spoiled people most often tried to reject it as unnecessary, but later always accepted it as the 'lighthouse'.
Liked that now there is only a Team, not Scrum Team and Devlopment Team. One thing that makes me a bit confused is the PO delegating the backlog management.
Sorry to ruin your party but the Scrum Guide 2020 clearly states the following: "Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and *size* ." Now what else than estimating can you do in order to add an attribute like "size" to a PBI? I´m sorry for all the passionate supporter of the #NoEstimate fraction but it´s just not true they removed it from the framework
Actually, I don't entirely disagree with you. Did you see the "launch party" for the 2020 version? Think it was Ken Schwaber that talked about going into businesses and noticing that where teams were getting stuck - and where teams were spending most of their time arguing - was in two areas: estimating and daily scrum. He went on to say that neither of these things are part of the Scrum framework: they were added to the Scrum Guide as "clarifications" or "helpful hints". Experience has shown that the hints were not helpful, hence their removal from the 2020 version of the Guide. HOWEVER, they were NOT removed from the Scrum Framework because (if we take Schwaber at his word) they were never part of the Framework in the first place! Coming back to wording you mention, I guess we need to prove that BOTH of the following statements are true: 1. That _ "such as a description, order, and size"_ means that *description* , *order*, and (especially) *size* are mandatory. 2. That the only way to arrive at *size* is via the process of estimation. Here's a case to consider: teams that get good at Story Slicing are likely to consider that all of their stories are "small"... and would deny that their process included "estimating".
I like the Why very much and if we defocus estimates (btw the results of this was often a clarification of the what) the focus on the why is very strong because it leads toward the value and :) :) :) for this
You're right that the conversation that leads to an estimate also leads to clarification. That's exactly the reason I tolerated the process of estimating for so long. But then I found a better basis for the conversation: Story Slicing.
@@Developmentthatpays hi Gary, I have been on a lookout for an effective way of eliminating estimates (for clarification) and would love to know more about story slicing. Can you please point me to any reference read on it so that we do not have to rely on estimates during refinement for clarification/same understanding.
So what are we supposed to now do in Daily scrum...How to we discuss updates...The 3 questions were never forced upon everybody but always made sense to use as people could give updates quickly and then conclude the call in 15 minutes...
It seems - from what I picked up on the webinar - that the team (behind the Scrum Guide) were caught between a rock and a hard place: they started with a framework... people asked for clarification... they added "guidelines"... the guidelines were taken as directions... the guidelines were removed again! The way Ken Schwaber put it was this: when they went in to companies and found people arguing "about Scrum", the argument was always around the guidelines. What we might call the "implemntation details". The solution? Remove the guidelines! For mature teams, the guidelines won't be missed. And many will find their absence liberating. For new teams, I agree with you: it's likely to be confusing.
@@Developmentthatpays Guidelines are always needed hence we have the Manifesto and Principles...At least even if they would have mentioned do anything you want in that 15 minutes that would also help but it has been kept too open ended...ow we may have opinion that Manifesto and principles are not guidelines and i would respect that opinions but i would argue why cannot we call them guidelines but again very open guideline...Saying we should have Face to Face communication is still a guideline though a very helpful one
Thanks for the video, Gary. I really like your dark humour way to describe things. Based on the slide that you presented where sprint backlog has sprint goal and now product backlog has now product goal, can we assume that this product goal is changing also as output of sprint reviews? If yes, all the scrum team now has real time access to the product goal and give inputs to update it accordingly? In other words, how and who is going to manage the product goal? Do they are going to bring it in all sprint reviews and also get inputs from stakeholders? I would be curious to know how the product goal is created in the first place and for whom? If the product goal doesnt change along the way, it seems to me kind of the "waterfall" style to have the scope agreed and "written in stones" in the first place.😉
Good video, thanks! Question regarding 2020 absence of “estimate” in the Guide: isn’t it basically replaced by “size”? If not, what is “size” referring to in the 2020 version (pages 10-11)? Cheers!
I think it's a good bit more significant than that. Here's the entry, which i think this is the only (relevant) instance of "size". - "This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work." The "attributes often vary" bit implies that "size" might be optional. Previously, it was a required: "Product Backlog items have the attributes of a description, order, estimate, and value." More importantly, there's nothing to say how the "size" might be arrived at. The previous version was riddled with "estimatING" language: - "Work may be of varying size, or estimated effort." - "Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog." - "More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail." - "The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate".
I'm still trying to unpick exactly what's changed. Looks like "responsible for... " has been strengthened to "accountable for..." in several places. What's your take on the changes?
@@Developmentthatpays Hi Gary, it is interesting to see the accountability thing in the Scrum Guide. I like the 5 dysfunctions of team model by Patrick Lencioni and, below inattention to results, there is avoidance of accountability that comes from lack of commitment due to fear of conflicts and absence of trust. So yes I do like accountability. The problem is when we translate the Scrum Guide in french we have issues because of one single word for accountability and responsibility. And same issue between effectiveness and efficiency. As "the Scrum master is accountable for the Scrum Team’s effectiveness" its sounds like the return of the team boss. The former means doing the right things. The later means doing the things right. Don't know.
@@Developmentthatpays so when we take the training or inform the Teams we clearly suggested no project managers in the team...If they want entry become a Scrum Master but they have to let go off the powers they had as project Managers and become true servant leaders and serve the team (not as Secretary though) because this is what is suggested in the guide....now with that going away we have no way of justifying servant leader...Also with Self management in place instead of self organizing management will find its way back into the teams
Very nicely put. It seems that you, me, Jeff, Ken, and others were (a) understood the term "servant leader", and (b) thought is described exactly what was required for the role. It also seems that there was enough misinterpretation - _secretary, note-taker, etc._ - to warrant a change to the Scrum Guide. I agree with you: this is likely to have negative consequences.
Not sure that will help. The new version strips away just about everything that might be considered to be an "implementation detail". Suggestion: take a look at Story Slicing.
I should add that estimating is one of a number of what we might call "implementation details" to be removed from the Guide. So you can continue to use estimates if you wish.
Hi Gary , it seems that the new scrum guide us borrowing a page of our book ?(is it going to the dark side to Scrumbhan side ?loll)..I love the fact that estimates are removed ,seems that scrum is becoming more lean and thus it should be ,after all it is lean that provided the genesis of scrum .Odly enough most of the things said in the new version made perfect sense to me .There is however one ☝️ thing that caught my eye and I wanted to get your input on it ,is the notion of self-managed teams replacing self organizing teams ,I’m still trying to scratch my head around that ..What is your opinion on it ,what exemple best illustrates that difference ..Richard Hickman’s famous definition of self managing team vs self governing teams convey that the former has a definition quite correlated to self organizing teams ,I really don’t see why there was a need to replace the term..
It's a very strange feeling: to have the things I've been battling against suddenly disappear! ---- On 'self-organising' vs. 'self-managing': There were a couple of name changes (e.g., 'servant leader' --> 'leader who serves') that had me scratching my head too. On the webinar, Jeff Sutherland shared various stories of "bad behaviour": - SM's taking no responsibility for progress; - PO's without a product direction; - Devs working on... whatever they want! The recurring themes of this version [of the Scrum Guide] seem to be *direction* (towards a goal) and *commitment*. Hence: - SM's ... are now *leaders that serve* - PO's... have a *Product Goal* - Devs... have... I'm not really sure! But this might be where there 'self-organising' --> to 'self-managed' comes in. Could it be that they're saying: self-organising + direction + commitment = self-managed ? I'm sure there will be much discussion around the new terms!
Goals are for loosers, winners have systems - Scott Adams. You better check out Agile Lounge Review on this scam guide. Coach AF over at Agile Lounge is a pupil of the late Mike Beedle: founders of Enterprise Scrum for Business Agility. All this Product Goal is a regression pf subsumption at the core of the lean thinking.
Think I heard someone of the webinar - JJ Sutherland? - refer to the Product Goal as "what the Product Backlog amounts to". I took that to mean that it's a single "thing". (And yes, I wanted to use the word "vision"). What's your take?
@@nathalieallard6978 - I think the product vision is exactly what it is. (From what I remember of the webinar) "vision" was seen as being too "airy fairy", hence the reason for bringing in a "big strong" COMMITMENT!.
You need estimates to hold people accountable for the work they produce and said they can deliver, like building a house. Its not an open ended contract. In the real world business wants a feature or goal delivered as soon as possible, maximize customer satisfaction and value for money. Else they just get a crappy product...
@@Developmentthatpays Really ? Aren't you playing with the words ? Providing a deadline or a development cost is estimating a workload. Admittedly, there are several ways for the PO to prioritize by value according to the expected business benefits and development costs (efforts). But companies are not always mature enough to implement them and the estimate of the development effort remains the most accessible. What would you replace the estimates with so that the PO prioritizes its backlog ?
I'm not playing with words. But I am challenging an underlying assumption: providing a deadline can be done by "estimating a workload". But it's not the only way. In agile, we do "bottom-up" estimating: estimate the individual items, and sum them. If we know the team's velocity, we can figure out a deadline. (And, because costs tend to be flat in agile teams, this also gives us the development cost.) So far so good. But what if just _counted_ the individual items. And counted the number of items that the team delivers in (say) a two-week period. We could use these numbers to figure out a "deadline". For example: 100 items; (roughly) 10 items per 2 week period; total duration: 20 weeks. Notice that this "deadline" required no estimating whatsoever. Now, you'd expect this so-called "deadline" to be wildly inaccurate. After all, the items in the backlog are all shapes and sizes. But you'd be wrong. This approach - the simple counting of items - has been shown to be MORE accurate than estimating-based forecasts. [I'm aware that I didn't address your point re. prioritisation; I wanted to address forecasting first.]
What struck YOU the most about the brand new *Scrum Guide* ?
Wow thank you! I dedicated my last two years fighting against estimates, making videos about how to get rid of them on the YT channel Scrum Life, and I didn't even see that estimates were removed, thank you for pointing that at me!! :)
Well done.
For me , beside those two huge things you mentionned, I see the self-managing team important and the role of the Scrum Master as accountable. I don't see the role different for many times, I don't like those who slip away saying "the team didn't want to improve, I can't do much". No, the SM is part of the team, and is responsible for the team to deliver as anyone else, so I agree with that.
Also, I like the rework on the review, espacially targeting ways of doing it only as a "demo". On Scrum Life, we tell it for sometimes now: "the review is a business meeting where decisions are made". I feel the new Scrum Guide tells it too now.
What do you think?
@@cog_g - Seems we're both fighting the good fight! (Love Scrum Life, BTW the way. C'est le pied!)
Interesting to hear (on the launch webinar) stories of "bad behaviour" across all roles: developers that use agile as a reason to work on "whatever they like"; PO's with no sense of direction; and Scrum Masters in (what sounded like) a secretarial role. I've witnessed the first two, but never the last: I guess I've been lucky. But/And I agree with you: things are clearer in regard to the SM's role.
I missed the changes related to the Review. I'll take a look!
What are your thoughts on companies requiring Scrum Masters to be project managers as well. I've been seeing that a lot in job postings and in the job description?
@@emiliana_N - Now THAT is a can of worms! I'm going to sit back and hope someone else jumps in :)
@@Developmentthatpays me too..however it doesn't stop there. I'm not sure about other countries, but here in the US..I've seen job descriptions where companies are putting..engineering, computer science, cybersecurity, UX degrees required plus 10+ years of project management required for a Scrum Master. I've been a SM for 6 years and I'm darn good at my job.. it's been really difficult to find work, even before the pandemic.
Excellent video, Gary! I hadn't even noticed that the estimates had been removed! Also, loved your description of your "rocky relationship" with Scrum. Golden :)
I enjoyed that bit I must say 😂
@@Developmentthatpays The drama - the music, the frustration, the persuasion, the passion, the mien - bits made me laugh; I loved it.
However, sizing or relative sizing is the backbone of planning and performance measurement in Scrum. Alternatively what is your preferred approach, as sizing will always be relative and not accurate.
Nice analysis. For me, the thing that caught my eye was 2 parts, the removal of structure for the Daily Scrum, which I agree with, but I think that teams new to Scrum need a starting point. The 2nd thing that caught my eye was the redefinition of what a team is.
There were a couple of things that were removed - including the 3 Questions. I did wonder if that would make things harder for teams coming to Scrum for the first time.
Agree that the team redefinition is a good move. I wonder why they went with "developers", rather than something less "software". Something to watch for next time!
I just read it, and I have to say that I like they considered some experiences I have lived. I loved they focused on data in order to forecast and they clarify that a scrum team doesn't need to wait until sprint review to release an increment
You sent me scurrying back to the Scrum Guide to look for "forecast". Is this the passage you're referring to:
"Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making." ?
_I completely missed this!_
I HATE burn-ups/burn-downs; *delighted* to see them thrown under the bus!
@@Developmentthatpays I think tracking progress is useful using a burn-up, it's useful if we use that historic data to forecast when the team would deliver a number specific of items (on a probabilistic way)
Estimations out!!! That’s a shock! Got to go through the Scrum Guide today.
I didn't see it coming either!
You have also highlighted something else here. The definition of Done (DoD) is the artifact for the 'Increment' not the Sprint and as we don't need to wait to the end of the sprint for the increment to be complete we have a clearer/different view on release management.
Excellent point!
I was also interested to see the change in wording around the "increment". We're always adding to the adding to the product, and I always (mistakingly?) thought of the "increment" as the "bit that was added", while the (previous version of) Scrum Guide implied that "increment" was the "new whole". The new language seems to have moved in my direction. I'd be interested to hear how you read it.
Thanks for this video. I was staying away from Scrum, only, because of estimating. I am really glad that they have finally get it out from the guide.
Such a great channel. Really nice insights on the changes, loved the estimates drama! Lol
Thank you, Gary! As sharp on details as always!
Introduction of the Project Goal is something I always had to promote.
Agile is good and efficient, when you set a long-range target. Without such a 'lighthouse' making iteration steps most often leads to walking in a circle.
Whrn I used to start projects and guide our BAs tgrough them, I even had to develop my own approach to formulate the target (i.e. a Product Goal), and it proved to help in all aspects from generating PFBs and WBSs to setting OKRs and KPIs.
Scrum-spoiled people most often tried to reject it as unnecessary, but later always accepted it as the 'lighthouse'.
Great to hear that you were (in a sense) already using a Product Goal. Agree that the "lighthouse" is sooo important.
Liked that now there is only a Team, not Scrum Team and Devlopment Team. One thing that makes me a bit confused is the PO delegating the backlog management.
The part of delegation was already there in the 2017 version.
@@cog_g but was delegation to the Development Team, not to others... A bit more open and vague.
@@mjrsilva ah yes, completely you’re right
Sorry to ruin your party but the Scrum Guide 2020 clearly states the following:
"Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and *size* ." Now what else than estimating can you do in order to add an attribute like "size" to a PBI? I´m sorry for all the passionate supporter of the #NoEstimate fraction but it´s just not true they removed it from the framework
Actually, I don't entirely disagree with you. Did you see the "launch party" for the 2020 version? Think it was Ken Schwaber that talked about going into businesses and noticing that where teams were getting stuck - and where teams were spending most of their time arguing - was in two areas: estimating and daily scrum. He went on to say that neither of these things are part of the Scrum framework: they were added to the Scrum Guide as "clarifications" or "helpful hints". Experience has shown that the hints were not helpful, hence their removal from the 2020 version of the Guide. HOWEVER, they were NOT removed from the Scrum Framework because (if we take Schwaber at his word) they were never part of the Framework in the first place!
Coming back to wording you mention, I guess we need to prove that BOTH of the following statements are true:
1. That _ "such as a description, order, and size"_ means that *description* , *order*, and (especially) *size* are mandatory.
2. That the only way to arrive at *size* is via the process of estimation.
Here's a case to consider: teams that get good at Story Slicing are likely to consider that all of their stories are "small"... and would deny that their process included "estimating".
I like the Why very much and if we defocus estimates (btw the results of this was often a clarification of the what) the focus on the why is very strong because it leads toward the value and :) :) :) for this
You're right that the conversation that leads to an estimate also leads to clarification. That's exactly the reason I tolerated the process of estimating for so long. But then I found a better basis for the conversation: Story Slicing.
@@Developmentthatpays hi Gary, I have been on a lookout for an effective way of eliminating estimates (for clarification) and would love to know more about story slicing. Can you please point me to any reference read on it so that we do not have to rely on estimates during refinement for clarification/same understanding.
@@Developmentthatpays Fine with that, but even more interesting as I mentioned is the WHY - it leads so easily to Value and Simon Sinek!! :)
You're right, that actually is a big deal!
(Sorry that I replied to your "aside", rather than to your main point.)
thanks Gary....very interesting changes.
Good job,Gary!
Thank you!
So what are we supposed to now do in Daily scrum...How to we discuss updates...The 3 questions were never forced upon everybody but always made sense to use as people could give updates quickly and then conclude the call in 15 minutes...
Remember: there's no reason NOT to use the 3 Questions. This "implementation detail" has been removed from the Guide; it wasn't banned!
@@Developmentthatpays Agreed but then it becomes real confusing...
It seems - from what I picked up on the webinar - that the team (behind the Scrum Guide) were caught between a rock and a hard place: they started with a framework... people asked for clarification... they added "guidelines"... the guidelines were taken as directions... the guidelines were removed again!
The way Ken Schwaber put it was this: when they went in to companies and found people arguing "about Scrum", the argument was always around the guidelines. What we might call the "implemntation details". The solution? Remove the guidelines!
For mature teams, the guidelines won't be missed. And many will find their absence liberating. For new teams, I agree with you: it's likely to be confusing.
@@Developmentthatpays Guidelines are always needed hence we have the Manifesto and Principles...At least even if they would have mentioned do anything you want in that 15 minutes that would also help but it has been kept too open ended...ow we may have opinion that Manifesto and principles are not guidelines and i would respect that opinions but i would argue why cannot we call them guidelines but again very open guideline...Saying we should have Face to Face communication is still a guideline though a very helpful one
Thanks for the video, Gary. I really like your dark humour way to describe things. Based on the slide that you presented where sprint backlog has sprint goal and now product backlog has now product goal, can we assume that this product goal is changing also as output of sprint reviews? If yes, all the scrum team now has real time access to the product goal and give inputs to update it accordingly? In other words, how and who is going to manage the product goal? Do they are going to bring it in all sprint reviews and also get inputs from stakeholders? I would be curious to know how the product goal is created in the first place and for whom? If the product goal doesnt change along the way, it seems to me kind of the "waterfall" style to have the scope agreed and "written in stones" in the first place.😉
Good video, thanks! Question regarding 2020 absence of “estimate” in the Guide: isn’t it basically replaced by “size”? If not, what is “size” referring to in the 2020 version (pages 10-11)? Cheers!
I think it's a good bit more significant than that. Here's the entry, which i think this is the only (relevant) instance of "size".
- "This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work."
The "attributes often vary" bit implies that "size" might be optional. Previously, it was a required: "Product Backlog items have the attributes of a description, order, estimate, and value."
More importantly, there's nothing to say how the "size" might be arrived at. The previous version was riddled with "estimatING" language:
- "Work may be of varying size, or estimated effort."
- "Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog."
- "More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail."
- "The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate".
What do you think about the accountabilities addition ?
I'm still trying to unpick exactly what's changed. Looks like "responsible for... " has been strengthened to "accountable for..." in several places. What's your take on the changes?
@@Developmentthatpays Hi Gary, it is interesting to see the accountability thing in the Scrum Guide. I like the 5 dysfunctions of team model by Patrick Lencioni and, below inattention to results, there is avoidance of accountability that comes from lack of commitment due to fear of conflicts and absence of trust. So yes I do like accountability. The problem is when we translate the Scrum Guide in french we have issues because of one single word for accountability and responsibility. And same issue between effectiveness and efficiency. As "the Scrum master is accountable for the Scrum Team’s effectiveness" its sounds like the return of the team boss. The former means doing the right things. The later means doing the things right. Don't know.
Also what does True leader mean...I believe this gives the Project Managers an opportunity to get back into the old ways in the guise of a True Leader
Interesting. Can you say more about this?
@@Developmentthatpays so when we take the training or inform the Teams we clearly suggested no project managers in the team...If they want entry become a Scrum Master but they have to let go off the powers they had as project Managers and become true servant leaders and serve the team (not as Secretary though) because this is what is suggested in the guide....now with that going away we have no way of justifying servant leader...Also with Self management in place instead of self organizing management will find its way back into the teams
Very nicely put. It seems that you, me, Jeff, Ken, and others were (a) understood the term "servant leader", and (b) thought is described exactly what was required for the role. It also seems that there was enough misinterpretation - _secretary, note-taker, etc._ - to warrant a change to the Scrum Guide. I agree with you: this is likely to have negative consequences.
I have no idea how you should run scrum without estimates, looks like I'll be reading the updated version of scrum over the weekend then.
Not sure that will help. The new version strips away just about everything that might be considered to be an "implementation detail". Suggestion: take a look at Story Slicing.
I should add that estimating is one of a number of what we might call "implementation details" to be removed from the Guide. So you can continue to use estimates if you wish.
Hi Gary , it seems that the new scrum guide us borrowing a page of our book ?(is it going to the dark side to Scrumbhan side ?loll)..I love the fact that estimates are removed ,seems that scrum is becoming more lean and thus it should be ,after all it is lean that provided the genesis of scrum .Odly enough most of the things said in the new version made perfect sense to me .There is however one ☝️ thing that caught my eye and I wanted to get your input on it ,is the notion of self-managed teams replacing self organizing teams ,I’m still trying to scratch my head around that ..What is your opinion on it ,what exemple best illustrates that difference ..Richard Hickman’s famous definition of self managing team vs self governing teams convey that the former has a definition quite correlated to self organizing teams ,I really don’t see why there was a need to replace the term..
It's a very strange feeling: to have the things I've been battling against suddenly disappear!
----
On 'self-organising' vs. 'self-managing':
There were a couple of name changes (e.g., 'servant leader' --> 'leader who serves') that had me scratching my head too. On the webinar, Jeff Sutherland shared various stories of "bad behaviour":
- SM's taking no responsibility for progress;
- PO's without a product direction;
- Devs working on... whatever they want!
The recurring themes of this version [of the Scrum Guide] seem to be *direction* (towards a goal) and *commitment*. Hence:
- SM's ... are now *leaders that serve*
- PO's... have a *Product Goal*
- Devs... have... I'm not really sure! But this might be where there 'self-organising' --> to 'self-managed' comes in. Could it be that they're saying:
self-organising + direction + commitment = self-managed ?
I'm sure there will be much discussion around the new terms!
They should have launch earlier this year or late last year. launch at year end??
Goals are for loosers, winners have systems - Scott Adams. You better check out Agile Lounge Review on this scam guide. Coach AF over at Agile Lounge is a pupil of the late Mike Beedle: founders of Enterprise Scrum for Business Agility. All this Product Goal is a regression pf subsumption at the core of the lean thinking.
Is the Product Goal based on 3 / 6 / 12 months objective?
Think I heard someone of the webinar - JJ Sutherland? - refer to the Product Goal as "what the Product Backlog amounts to". I took that to mean that it's a single "thing". (And yes, I wanted to use the word "vision"). What's your take?
The product backlog keeps evolving so I’m a bit confused if it’s the product vision. What’s your take?
@@nathalieallard6978 - I think the product vision is exactly what it is. (From what I remember of the webinar) "vision" was seen as being too "airy fairy", hence the reason for bringing in a "big strong" COMMITMENT!.
You need estimates to hold people accountable for the work they produce and said they can deliver, like building a house. Its not an open ended contract. In the real world business wants a feature or goal delivered as soon as possible, maximize customer satisfaction and value for money. Else they just get a crappy product...
What you need - for the situation you describe - is a forecast. And you can get forecast without ever estimating.
@@Developmentthatpays Really ? Aren't you playing with the words ? Providing a deadline or a development cost is estimating a workload. Admittedly, there are several ways for the PO to prioritize by value according to the expected business benefits and development costs (efforts). But companies are not always mature enough to implement them and the estimate of the development effort remains the most accessible.
What would you replace the estimates with so that the PO prioritizes its backlog ?
I'm not playing with words. But I am challenging an underlying assumption: providing a deadline can be done by "estimating a workload". But it's not the only way.
In agile, we do "bottom-up" estimating: estimate the individual items, and sum them. If we know the team's velocity, we can figure out a deadline. (And, because costs tend to be flat in agile teams, this also gives us the development cost.)
So far so good.
But what if just _counted_ the individual items. And counted the number of items that the team delivers in (say) a two-week period. We could use these numbers to figure out a "deadline". For example: 100 items; (roughly) 10 items per 2 week period; total duration: 20 weeks.
Notice that this "deadline" required no estimating whatsoever.
Now, you'd expect this so-called "deadline" to be wildly inaccurate. After all, the items in the backlog are all shapes and sizes.
But you'd be wrong.
This approach - the simple counting of items - has been shown to be MORE accurate than estimating-based forecasts.
[I'm aware that I didn't address your point re. prioritisation; I wanted to address forecasting first.]
You need to have "date of completion" for business. No matter what we call it, orange or apple or banana.
Not sure what point you're trying to make. Can you clarify?