SQS Scrum Quick Start
Purpose of SQS
Having a Good Practice is nice, but for what can you be used? Below you will find a short description per "target" area for which purpose you can use SQS for that area.
When a team starts with Agile Scrum, it is good practice to start with a Good Practice.
This way, the team is;
- fast up to speed
- starts to deliver quickly, in an Agile way, added value
- the team starts to feel ownership
- celebrates successes quickly
- a feature road-map starts to evolve fast
- stakeholders experience that Agile Scrum works
For teams who are already working for a while "with Scrum," SQS can be of help, it can be used;
- as a benchmark against their Scrum processes
- detect areas where they can improve
- detect areas where they have a better solution then SQS
SQS is a comprehensive set of WoW's right from the beginning of an idea (Saga/Episode/Epic) all the way down to the Stories in Sprints and the WoW's needed in a Sprint.
When new team members join the team, this SQS library will help the new team member in getting up to speed fast and integrating into the team and organization.
"How did we do this again?" SQS serves as a library where team members can go to when they want to know how to do a specific part of the process.
For example; what to do with a Story that is Done and is only waiting on the approval of somebody outside the team?
The Cynefin Complexity Model and SQS
A best practice is a best practice, meaning when you use it, it works. Changing a best practice can result in a decline in the performance of the best practice.
A Best Practice is used in the Simple quadrant of the Complexity model.
A good practice is good to use as a quick start for teams to help them to start quickly and achieve quickly good results. After using it for a couple of Sprints, it can be adjusted specially for that team and the context where the team is working in.
A Good Practice is used in the Complicated quadrant of the Complexity model. Agile Scrum resides in the Complicated quadrant.
Why invent the wheel over and over again?
That was a thought that popped up in my mind a couple of years ago.
Again and again, I saw teams struggling to get the hang of Scrum. I saw frustration and irritation with the teams.
Stakeholders had trouble trusting the team if they were able to deliver the high-quality what they needed, and when they needed it.
Managers, who tried to be servant leaders towards the teams, were forced to save the day by moving back to manager-style like behavior to get the "things under control" again.
Many Scrum teams don't learn how to make clogs; they are expected to INVENT how to make clogs.
In the past
A couple of hundred years ago, if you wanted to learn how to make clogs, it wasn't so that the master clog maker would give you a piece of wood, some tools, and then say to you, "Here's wood and tools, I have all the trust in you that you will discover in 3 Sprints how to make clogs."
If you look at it, it is folly to approach it in this way because now the apprentice has to go through the whole learning path that all those clog makers before him also went.
The master clog maker did not do this; he would say, "Here's wood and tools, sit next to me and just do like me."
Within a week, the apprentice can make clogs, and after again a week, he could already produce an order on his own for a woman who ordered clogs size 38.
A couple of months later, the apprentice could develop improvement ideas. Improvements the master clog maker could not see himself because he was creating in a habitual way the clogs.
Now, the apprentice moved to mastery.
The master clog maker was first a mentor, and then became a coach.
The Scrum World
Within the Scrum world, I noticed that the Scrum teams were often given wood and tools and were expected to re-invent the clog-producing process again. To say it differently: "The Scrum Master moved too quickly from mentorship towards coaching."
This inside started the "development" of what I now call the Scrum Quick Start.
How it can help Scrum teams
SQS is an ever-evolving set of Good Practices that should not be used as laws but being used as a starting point to get quick results, enable success quickly, enable to celebrate success soon, and show the world that we can DO it!
SQS is a good benchmark for existing Scrum teams where the team can discover improvements or discover that they have developed even better practices, adding to their confidence.
SQS Topics
SQS exist out of 6 main topics which on itself has sub-topics, below you find a short description about each main topic.
It is essential that we have the same ideas about what Agile is, what Scrum is, the role of the Product Owner, the role of the Scrum Master, and has some idea about Large Scaled Scrum methods.
There is a lot of information available on the internet, with good and not so good information. These can cause different understanding about topics with Agile Scrum, which can confuse, causing lots of discussions and irritation. It carries a big potential in it to slow down the adaptation of Agile Scrum, and move quickly too; improved velocity, improved quality, and last but not least, improved team and customer happiness.
To avoid this, I have gathered good information so confusion, discussion, time loss, and in the worst case, avoid a not successful implementation of Agile Scum.
Here we dive into the difference between naming conventions between the old project structure and Agile roadmap structure, and we talk about the importance of Refinement.
In the Agile Scrum world, there is a Good Practice to come from the initial idea to in a Sprint executable Story.
The three workflows in this part are essential to study because they represent many years and have delivered Good Practice and give you a quality and quick start.
The WoW's you find here will support the team and the Product Owner to create a stable pipeline that spits out, like clockwork, well-refined and poker stories.
The effect of high-quality Refinement of Stories is enormous!
I have seen good working teams jump from an average of 70 Story Points per Sprint to 170 Story Points average per Sprint.
The only thing the team changed was the Story refinement process according to the Good Practice process you can find here.
During the Sprint, common interruptions appear, like; an unplanned Story needs to be added to the Sprint, a production incident needs to be solved, a Story is Done but you are waiting on external action, and when to create Sub-tasks for a Story and when not.
This section gives a proven Way of Workings with these common interruptions and discussions, which often occur during a Sprint.
The critical reason why Scrum is successful is that the team comes into a cadence that they can maintain over a long time.
The Scrum meeting Rhythm is an essential pillar of this cadence. This section contains an in-practice proven example of a cadence that supports the team in this.
Not enrolled
I'm sorry you are not enrolled in SQS, please get in contact with your Elite Agile representative.
You can view the first chapter, though.
To get more information about what SQS is, how it came to pass, and how you can use it, please view this chapter; 'How did SQS come to pass and how to use it?'.
This chapter can also be viewed when you are not enrolled.
No access yet?
Get in contact with me using the contact form and I will contact you as soon as possible about how you can use the Elite Agile Academy to support your teams, so they too can become a true Agile Elite Team and how it can support you in your transformation to a true Elite Agile Servant Leader.