Thursday, 29 August 2019

SCRUM for SharePoint - Part 3 - Scaling scrum

Introduction:  Scrum teams work best with relatively small teams (3 to 9 people) made up of high quality individuals.  Basically, a Scrum master, a product owner and up to 7 team members.  But in large enterprises or Software companies that deliver a large product, there is a need to use a lot more people to deliver working quality software.  Scaling scrum is an option and there are a couple of frameworks to help.

Scrum of Scrums
By adding an additional event daily for key people from each Scrum team called a "Scrum of Scrums".  The meeting requires key stakeholders from each team to attend so that the integration between teams picks up dependencies and ensure cleaner easier integration.  This is the simplest form of Scrum scaling and requires a 15 minute meeting that I follow the: What we did, what we are going to do and and blockers from all attendees format.

Scrum of Scrums helps reduce the integration unknowns and ensure various teams can solve dependencies in a timely fashion.  The problem is there is diminishing returns as more teams get added and this works well, if there are 2 or 3 teams working on a single project and these teams self-organise.  In my opinion, more than 3 teams requires a stronger Scrum based framework like Nexus or SAFe.  Keep "Scrum of Scrums" meeting small with a technical scrum team member from each of the scrum teams.  I do them exactly like a daily stand-up Scrum meeting with technical items moved to the backlog.

Scaled Agile Framework (SAFe)
This is not an answer to Scrum scaling, I worked with a big four consultancy firm using SAFe and while it is useful and forward thinking, it really does not work well with dedicate Scrum teams. it is a way for an organisation to be ready for Scrum.  SAFE focuses on Agile software, Lean product development and system thinking.  Basically it is for an organisation to be more Agile but it is not applicable to Scrum except in contrived cases generally where senior management are trying to make a perfect answer to problems they do not comprehend.  I disagree with the author saying SAFe is for a way of scaling scrum, for me SAFe is not a way of scaling Scrum, but i think the article is a good read.
Note: Organisations can jump on the Scrum framework and try make all teams scrum teams.  This can be great and is generally a good sign however, beware of managers/management comparing teams spring volatility thru story points, all the teams tend to increase their story points when compared so they look like they are improving and beating other teams.  Focus on delivering quality in a trusted rewarding team.
Note:  Using the same Scrum in every team is not ideal, I like to let each team decide their rules and find their own way.  The culture win from team members is where Scrum's value lies.  I like to leverage other frameworks like Kanban and story points.
Note:  I do like to have repeatable CI/DC tasks to be agreed across Scrum teams, even though the team may take longer, it works better from expertise and consistency in software delivery.  The point here is tune to match you requirements.

LeSS (Large-Scale Scrum) framework LeSS 

Disciplined Agile Delivery (DAD) extends Scrum

Nexus
Nexus is for scaling scrum teams, I have never used it but I like the thoughts and these guys know there stuff.  I really like the idea of an integration team.  I have used this idea with floating team members with high degrees of specialization in CI/CD.  Having a central integration team ensure all the pieces come together for the deliverable's.  Mixed with Scrum of Scrum meetings, the number of teams can be increased and for very large products having a central architecture/integration team is a great idea to reduce dependencies and ensure alignment from the various Scrum teams.

Summary:  Scrum works well for small Agile teams, once going over a single team, use daily Scrum of Scrum meetings to scale to two teams.  If the product/programme is large, a dedicate architecture team that is responsible for build releases, integration of work streams and overall architecture and using daily scrum of scrums to deliver allow for larger Scrum based projects.

Agile for SharePoint
Scrum for SharePoint - Part 1
Scrum for SharePoint - Part 2
Scrum - Part 3 - Scaling Scrum  (This post)
Scrum - Part 4 - Kanban
Scrum - Part 5 - Certification PSM 1

0 comments:

Post a comment