| It sounds like you got a lot of positive things out of it. Which is great. Also great that you are iterating and not sticking to what the coach gave you. My take on what made many elements of SCRUM work for me follows. 2-3 hour backlog grooming sessions is a warning sign. Of what I couldn't say but maybe it is time to evaluate team size or how meetings are being conducted. Push as much stuff out of meetings as possible. If you have a morale issue due to stuff slipping (and I suspect maybe you didn't capture everything in this post) then it may not be planned sprints that are the issue. Expectations that people have of themselves and of the team are something you are free to set. I think SCRUM tend to end poorly for developers because they are placed on top of dysfunctional systems of expectation that discourage many kinds of failure. I am perfectly happy abusing SCRUM and letting things slip from sprint to sprint sometimes excessively. Fitting things into 2 weeks was a goal to gain the benefits of constrained scope and clearly articulated and designed implementations or requirements, but failure is something I made sure to embrace. Sure we had retrospectives to see what could be learned and what we could do better, but you have to be very careful to make sure it isn't second guessing or moving the goal posts. You shouldn't fault people pretty much ever as part of SCRUM, but definitely don't fault them for slippage. There should be next to no onus on an assignee for a task to prove they did the right thing. IMO That kind of feedback comes best out of band on a very macro scale when there is a pattern of failure for an individual to address AND you must get buy in from the individual that there is improvement to be had. The reason I stress this is that I don't want people to try and avoid things that they might fail at. That pushes people away from important work that needs to be done. I think that planned sprints and retrospectives are the 1-2 punch of SCRUM. By estimating what you should be capable of you are then capable of reasonably identifying WHY you didn't achieve that and trying things until there is improvement or you establish that the estimates are wrong. SCRUM without high functioning retrospectives is missing 50% of the goodness IMO. It's great that you kept regularly scheduled meetings. There is a huge amount of buy in, knowledge sharing, and consensus you get for relatively low cost by having regularly scheduled meetings. With small enough teams you can get it all done with one hour long interrupt per week. Socially it's also good because it discourages backroom deals, planning, and cliques which are toxic. Doubly so if you have remote workers. |
It should be sufficient for someone to lead and assign tickets as they come in, and for people to talk to people and reassign them as needed.
Again, if you need status on something, don't have a 2-3 hour long meeting, just ask... because when you have a long meeting and only 2 people out of, say, 8, are engaged at the same time, those other people are being very expensive and are getting bored fast.
The team's velocity is what it is - retrospectives can be boiled down to a "hey, how are things working out" that you can fit into a standard team meeting IMHO. Doesn't need it's own time slot, and this can also prevent retros turning into "throw X under the bus / CYA" type meetings. You can also get a lot of this from 1:1 conversations, and probably in greater depth in that context.