Self organization and scrumbuts
Hi everyone.
I'd like to get some stories on how your teams have dealt with ScrumButs through team inspection and adaptation.
With a newly formed team who does not start out following all the rules of the scrum framework, how does a scrum master guide the team towards them?
What are some ways that you have achieved this while still maintaining team empowerment and selforganization?
Hi Randy,
It depends on your team, a mature team finds it easy.
New teams not so easy as already they are already breaking the rules, sounds like you may
have to run some workshops to get everyone to a level playing field.
After all you are a SM, this is part of one of your services, when implementing scrum.
If everyone is singing off the same song sheet is a start, and work off that.
Everyone must know the rules, don't take it for gospel everyone does, could be the case
some people will say they understand scrum, but actually don't, give them the best education
you possibly can in scrum, is a good starting point.
Don't expect miracles and be prepared to play the long game with it.
If you have some advocates for scrum in the team get them involved too with the sessions.
Michael
Hi,
when the new team breaks the rules, the discussion with experienced Scrum is enough. When it happens to the mature team and they are fully aware what they do, why they shouldn't try? They might discover the new way of working. Moreover it's always good to experiment. When we treated this as an experiment, we always have some assumption at the beginning and upshot at the end to be discussed.
BR,
Bartek
> I'd like to get some stories on how your teams have dealt with
> ScrumButs through team inspection and adaptation.
A team should constantly try to improve its process through inspection and adaptation. That doesn't necessarily mean that a suboptimal implementation of Scrum is "ScrumBut".
The term "ScrumBut" is usually applied in the context of wider organizational antipatterns, where it is the organization itself that places constraints upon what teams can do. The classic example is where pseudo-agile practices are applied to a development phase only, while delivery is deferred to a large release and existing SDLC and cultural malpractices continue unabated. "Agile In Name Only" and "WaterScrumFall" are closely related metaphors.