The title may have intrigued you, here is how it evolved. A few teams that I coach wanted to know about Scaling Agile  and particularly Scaled Agile Framework and I was thinking on how best to introduce that in a contextual manner. The patterns I had seen emerge during my coaching interactions with the teams came handy. These were real challenges that teams had encountered and resolved and the teams related to. Linking this to “online knowledge base of proven success patterns” became the easy first step.

Here is one…

Quite some time back, when I started coaching a Scrum team that was not co-located, the first change the team looked forward to was better Sprint planning.

The Sprint Planning would start at about 7 pm IST and go on up to 8 pm IST on the last day of the sprint. This time was chosen as both team members in India and a few team members at the onshore location were available. For a two week sprint the duration was inadequate, invariably they committed to (forecast) a sprint backlog that was often not achieved.

Interestingly the team had decided to do so, based on the Scrum guidelines of this being a time boxed meeting with all members participating. They were not able to incorporate the guideline on the duration (of about two hours) though.

    • This was remedied easily by eliciting the purpose of the Sprint Planning and how we could focus on outcome and leverage the different team members playing different roles
    • The 7 to 8 pm meeting was reduced to a ½ hour, as the purpose was to get a prioritized spring backlog, understand the stories and the acceptance criteria from the PO (1)
Distributed Sprint Planning

Distributed Sprint Planning

  • The India team would meet in the morning on the next day and do the detailed planning – breaking stories down to sub-tasks, estimating hours if required and arriving at a near final sprint plan (2)
  • They would meet with the PO in the evening on the same day for ½ to clarify any doubts on the stories that they may have come across during the planning and then commit to (forecast) the sprint backlog (3)
  • The team would start work on the high priority stories after the planning

This worked out well and this pattern was applied with some tweaks by many of the distributed teams.
SAFe deals with a set of distributed teams and their Program Increment (PI) planning lays out how to do a multi-team, multi-location planning leveraging everyone effectively. The team was able to relate to the challenge and the approach.

Multiple Teams

Here is another one on multiple teams responsible for a product, working with different sprint duration to start with:
http://pm-powerconsulting.com/blog/manifestation-self-organization-across-teams/

The teams experientially figured out that they have to have synchronised sprints and adopted the same to move towards fast integrated learning cycles.

My advice at the start to do the same was not accepted, but I felt a lot happier and more satisfied when they themselves decided to do so.

Sprints On and On

And here is another one which talks about fatigue that sets in whens team work on never ending backlog sprint after sprint without respite.
http://pm-powerconsulting.com/blog/ready-steady-on-and-on/
SAFe introduces a iteration every few iterations called Innovation and Planning Sprint, which helps the team deal with the next increment with more gusto and enthusiasm.

Hope this help you get an introductory view into SAFe, agile teams discover patterns as they work together to deliver products and focus on continuous improvement. SAFe provides you access to a set of successful patterns that you could use as is and/or with your tweaks. You certainly will come across something that you have already experienced.

SAFe has a lot more in it, this was introduction to some aspects of it from the team perspective.

Do share your views and experiences