You can actually see sprints as mini-Waterfalls. But the point is to fail and learn from it. I am sorry you had no Scrum Master with responsibility.
Not finished on Friday? So be it! Find out why and try a solution. You had distractions, complexities during the sprint: reduce them!
You planned wrong: why? Were you forced to, by people outside of your team? Put the decision making back to the team, where it belongs. Nobody else.
Embarrassment at the review? Don’t cover it up because no one will learn from it. Dont fix something in secret over the weekend. Someone will not notice something was ever wrong.
I guess I fundamentally reject the idea that a team should be able to plan and estimate weeks worth of work and if everything doesn’t go according to plan, then you did something wrong and need to figure out how to do better next time.
And you wouldn’t even disagree with scrum here. Whoever taught that, misinterpreted the scrum guide. You don’t need to figure everything out. See scrum as an instrument that shows you a result, nothing more. You as a team interpret the result as you like. If you see no problem in the result, fine. Nothing to do, move on.
The way you say it sounds like someone put disappointment or bad energy into ‘failing’ a sprint.
The point of scrum is that you can not plan perfectly and expect funny results. A good SM might ask: “do you see this as a problem?” and let the team decide.
Scrum actually doesn’t even mind spill over or unfinished work, etc. At the end of the sprint we check out the outcome and then talk about the next opportunities. Half finished work is no problem and not even mentioned in the scrum guide. If there was disappointment or bad feelings about it, then some one among you did that on their own. As a team you can literally decide that you don’t mind spill over from sprint to sprint because you see no problem in it and move on without worry.
estimate weeks
In my opinion, time estimations are a distraction to everyone involved and never work. I’d recommend to estimate in complexities. To talk about them. Nothing else.
The problem is that committing to a fixed scope in a fixed timeframe with a fixed team size is always bad idea and Scrum makes an entire process out of this bad practice.
Again, misinterpretation. The sprint length is just for consistency, like planning meetings is easier that way. And measuring is easier too.
Scrum even allows you to renegotiate the scope dureing the sprint. It even says that in the scrum guide…
I always wonder what the point is of time-boxing in the first place
When all work is done inside of sprints (including merging, testing, delivery, troubleshooting) etc., as it originally is meant, this becomes a really convenient thing. Sales people, the customers or the manager, know at 1pm every other Friday they can come to the review, check out a new iteration, with contiguous items, without interrupting anyone or having to make changes in their full calendar to get in touch. In kanban, i wouldn’t be so sure when a good moment is to review with others, in advance.
Scrum as mini waterfall isn’t supposed to happen, but it usually does. The idea is everyone can help the people will are currently busy
The problem is test and build can’t do much to help the system analysts; the analysts and testers can’t help build because they don’t usually know how to code, so all that happens is everyone tests when build is done
As an analyst I don’t do any testing because I had a bad team leader in a past job as a function tester which soured me on the job, so it’s pretty much mini waterfall to me
the mini waterfall is kind of the intention of a sprint. The whole idea is to reduce the huge waterfall and its horrible surprises at the end when it is way too late. Have those surprises early by doing small waterfalls. But everybody is splitting it wrong so all the small waterfalls have no outcome until the whole thing is done, just like you do without sprints.
Yeah, great iteration is the feature. But the other side where we’re expected to all help out each other, to keep everyone busy all the time doesn’t work
I agree but that has nothing to do with scrum. It does not say how busy everyone has to be. Things like these are left for the team to decide. If you felt like you had to be more busy, then someone among you probably pushed it.
In fact i prefer a bit of slack time so people can react to incidents better. Imagine a 100% busy highway. Not nice. And then you need to spontaneously deliver something from A to B, using that highway -> there will be a traffic jam and everything works terribly.
Have a bit of slack here and there so the spontaneous delivery does not mess up the flow -> much more effective and everyone is happier too.
deleted by creator
You can actually see sprints as mini-Waterfalls. But the point is to fail and learn from it. I am sorry you had no Scrum Master with responsibility. Not finished on Friday? So be it! Find out why and try a solution. You had distractions, complexities during the sprint: reduce them! You planned wrong: why? Were you forced to, by people outside of your team? Put the decision making back to the team, where it belongs. Nobody else.
Embarrassment at the review? Don’t cover it up because no one will learn from it. Dont fix something in secret over the weekend. Someone will not notice something was ever wrong.
deleted by creator
And you wouldn’t even disagree with scrum here. Whoever taught that, misinterpreted the scrum guide. You don’t need to figure everything out. See scrum as an instrument that shows you a result, nothing more. You as a team interpret the result as you like. If you see no problem in the result, fine. Nothing to do, move on.
The way you say it sounds like someone put disappointment or bad energy into ‘failing’ a sprint. The point of scrum is that you can not plan perfectly and expect funny results. A good SM might ask: “do you see this as a problem?” and let the team decide.
Scrum actually doesn’t even mind spill over or unfinished work, etc. At the end of the sprint we check out the outcome and then talk about the next opportunities. Half finished work is no problem and not even mentioned in the scrum guide. If there was disappointment or bad feelings about it, then some one among you did that on their own. As a team you can literally decide that you don’t mind spill over from sprint to sprint because you see no problem in it and move on without worry.
In my opinion, time estimations are a distraction to everyone involved and never work. I’d recommend to estimate in complexities. To talk about them. Nothing else.
Again, misinterpretation. The sprint length is just for consistency, like planning meetings is easier that way. And measuring is easier too. Scrum even allows you to renegotiate the scope dureing the sprint. It even says that in the scrum guide…
deleted by creator
thanks for your words.
When all work is done inside of sprints (including merging, testing, delivery, troubleshooting) etc., as it originally is meant, this becomes a really convenient thing. Sales people, the customers or the manager, know at 1pm every other Friday they can come to the review, check out a new iteration, with contiguous items, without interrupting anyone or having to make changes in their full calendar to get in touch. In kanban, i wouldn’t be so sure when a good moment is to review with others, in advance.
I like kanban too, by the way.
Scrum as mini waterfall isn’t supposed to happen, but it usually does. The idea is everyone can help the people will are currently busy
The problem is test and build can’t do much to help the system analysts; the analysts and testers can’t help build because they don’t usually know how to code, so all that happens is everyone tests when build is done
As an analyst I don’t do any testing because I had a bad team leader in a past job as a function tester which soured me on the job, so it’s pretty much mini waterfall to me
the mini waterfall is kind of the intention of a sprint. The whole idea is to reduce the huge waterfall and its horrible surprises at the end when it is way too late. Have those surprises early by doing small waterfalls. But everybody is splitting it wrong so all the small waterfalls have no outcome until the whole thing is done, just like you do without sprints.
Yeah, great iteration is the feature. But the other side where we’re expected to all help out each other, to keep everyone busy all the time doesn’t work
I agree but that has nothing to do with scrum. It does not say how busy everyone has to be. Things like these are left for the team to decide. If you felt like you had to be more busy, then someone among you probably pushed it.
In fact i prefer a bit of slack time so people can react to incidents better. Imagine a 100% busy highway. Not nice. And then you need to spontaneously deliver something from A to B, using that highway -> there will be a traffic jam and everything works terribly. Have a bit of slack here and there so the spontaneous delivery does not mess up the flow -> much more effective and everyone is happier too.