Patterns in fluent Scrum teams
I have been working with 100's of Scrum teams since the early 2000's. And I have seen the fluency of several of these teams improve to phenomenal levels over time.
There are several successful patterns that you see with these teams which do extraordinarily well and I am going to talk about a bunch of them today. And in future posts, will take each one of them specifically to talk about why that pattern matters and what makes those tick.
- Planning is over in ten minutes or less - yes ten minutes, not 1,2 or 4 hours. Why? They had sufficient knowledge on the required Product Backlog items due to the proactive work done earlier.
- Refinement happens continuously - the team, Product Owner and the stakeholders are continuously having the required conversations on keeping the Product Backlog up-to-date as well as discussing, creating understanding, decomposing and estimating the top backlog items.
- Daily Scum is once a day, several times a day or not at all - my top performing teams met several times a day to regroup around the work. And that meant that they did not have to meet at a specific time and that also means sometimes they don't have to meet at all.
- Sprint Review - was to inspect the Product along with the stakeholders to see where the Product is and where it needs to go to next.
- Sprint Retrospective - the best Scrum Masters used multi-stage (5 stage) retrospective techniques to spend sufficient time (up to 3 hours) to inspect and adapt the team(s) for the forthcoming Sprints. And the team(s) spent more time on inspecting how they worked together, than worked individually.
- Did not have Scrum Masters for each team - as it a role, not a person and the team exhibited the capabilities of this role collectively
- Had Product Owners managing features at a multi-team level - not for an individual team, the focus of the PO was on features that ship to customers and the teams collectively had responsibility to get it built and shipped.
- Had teams directly talking to customers
- Had no roles on the teams
- Regrouped themselves as required in different Sprints
- Focused on learning all the time
- Did not spend time on elaborate estimates
- Did not use estimations at all
- Used feelings to limit the work taken in a Sprint
- Did not divide work into tasks to track, but still got the work done
- Had access to senior executives to talk about goals and problems directly to understand market pain points.
- ... and I can keep going on, and on and on...
Need I say more... how many can you actually count on your team(s)?