About the author
Darko Špoljarić
VP of AI
Scrum is a framework many teams don’t truly understand even after reading and studying materials on it. It’s simply way different than what most people are accustomed to. On-the-job support is crucial for success.
In this article, you’ll find what Scrum Coaching looks like from start to finish, what work lies ahead of you, your team, and your organization, and what challenges you can expect Notch to help you with.
Key takeaways
Scrum is different, complex, and quite often a hill to climb for many teams and organizations because its foundations vastly differ from what most companies operate on.
We welcome your specifics with an open mind and bring no cookie cutters or ready recipes to the table. We expect you to roll up your sleeves. You do the cooking; we’re your sous chefs, and we’ll be there for you every step of the way.
The Ground Rules: Preparations/preconditions
Before we start with the engagement, there are several essential things to check.
Is there a product-framework (Scrum) fit?
Some of the questions to help with the answer are:
- Are we building this product for the first time, or is this a rewrite?
- Have we built something similar, and do we already have some valuable learning that we can apply?
- Is the target group of users entirely new to us?
- How much do we know about the market and the product-market fit?
- Do you know the feature list in advance for whatever reason?
Working in a Scrum fashion solely because of the desire to work in such a fashion – without checking the product-framework fit – will always result in issues and disappointment, so it’s the most important thing to check.
- There’s a dedicated cross-functional team with a Scrum Master, Product Owner, and as few external dependencies as possible.
- Everyone has some basic knowledge of Scrum so people know roughly what to expect.
- The team is appropriately sized, 3-9 people in the development team.
- The team has all the necessary skills to build, deploy, monitor, and gather feedback on the product.
- Ensure management support and protection from the outer organization until the interactions and artifacts exchanges are adapted.
The Plan: What does the engagement look like?
We focus on a couple of areas.
Kickoff
In a 2-day workshop, our coaches will facilitate the following activities and the creation of the following artifacts:
- Day 1: Product Vision and Initial Backlog Items
- Day 2: Team Values, Working Agreements, Definition of Done, First Refinement and Planning
Product Vision
Each product begins with a vision. A good vision will provide direction for your product and still allow flexibility in reaching it. Amongst the main parts of the vision are target groups of users and their needs, together with the business goals we need to reach. It will also filter requirements that are not coherent with the vision, preventing scope creep to a reasonable extent.
Initial Sprint Goal and Backlog Items
A product vision is nothing without concrete steps to build it.
Initial backlog, i.e., a list of backlog items, represents the first steps towards it. It is not a comprehensive list of all the bricks you need to build a castle. Instead, it is a list of things to build that fulfills the first sprint goal. The first (and all subsequent) product increment must provide user value and invite initial feedback.
In practical terms, the amount of PBIs we aim for is slightly more than we need to fill the first sprint.
Team Values
People who comprise a team come from different walks of life. Their beliefs and values may or may not be similar, and this session serves to uncover, understand, and talk about them.
The result is a set of values the team holds dear to their hearts and minds, guiding their behaviors and efforts in months and years to come.
Working Agreements
Like product vision, team values must also be articulated into a practical set of everyday behaviors. They answer questions ranging from how the decisions are made, what the team does in a conflict, and where and when the daily standup is.
It’s an evolving list of behavioral reminders. And as with all reminders, they are only needed until the whole team internalizes the behavior.
Definition of Done
When someone in the team says something is done, the whole team must have the same understanding. This understanding is put on a piece of paper we call the “Definition of Done.” It’s a short but evolving document that the development team shapes.
First Refinement
The Product Owner gets together with the team to present the first sprint goal and all the PBI leading to it. A conversation is started on the solution’s usefulness, scope, and shape to be built by the development team.
It is a meeting to create joint understanding by the whole team and add new perspectives on why something needs to be built, concluding with what that something really is.
Planning
After the initial backlog is refined, the team will select the amount of work that is realistically complete in the first sprint. It is a decision that the development team makes on its own without any interference from outside. Information is welcome, but pressure or coercion is not.
Learning the mechanics
During 4 to 6 two-week sprints, our coaches will be with you at every Scrum meeting so that you can learn how to participate and facilitate them.
Long story short – the whole development team participates in every meeting, the Product Owner is mandatory in all of them except in the daily Scrum, and the Scrum Master is the facilitator. The goal is for the team to learn to facilitate itself to a large degree and have the Scrum Master as a course-correcting role only. The meetings are all recurrent and their goals never change, allowing for self-facilitation and self-organization to happen.
The goal is to make the motions automatic and make these meetings as effective and efficient as possible. Inspecting and adapting how they’re facilitated is also something that the team does from time to time. Drifting into uselessness is highly demotivating.
Inspecting and adapting interactions
Various interactions with the rest of the organization and the market may need to be changed to reap all the benefits Scrum promises.
Typically, the changes come from the need for the team not to be interrupted during a sprint (to focus completely on the sprint goal) and from the need to be in close touch with the users.
Usual interruptions come from previous team members’ assignments/projects or junior people in their silos, in the case of seniors. The goal is to minimize them to an acceptable level. Some knowledge transfers or mentoring might need to occur to achieve that goal. But, this needs to be made explicit and planned.
Other interruptions might come in the form of requests to do just a little bit here and there or fix a bug, effectively stealing time from the sprint. This is something that the Scrum Master must have a very close eye on and work on to eliminate as quickly as possible. This responsibility lies entirely on the Scrum Master, who typically must get management involved and push for often not-so-easy decisions.
While the primary beneficiary of adapted interactions is clearly the Scrum team, the product, users, and stakeholders all benefit from their increased focus and effectiveness.
Inspecting and adapting artifacts
Artifacts related to planning, design, delivery, documentation, compliance, reporting, or any other concern also may need to be inspected and adapted. Scrum’s artifacts are all build and delivery-oriented rather than specification, compliance, and reporting (to an extent), so a delicate balance between them is needed to have the least possible bureaucracy.
That balance also may change with time as the team evolves and becomes even more waste-elimination savvy.
Additionally, organization procedures and processes contain blanket guard-rail activities to prevent mistakes or drifting, even in contexts where this is prevented by custom-fitted activities that are usually way simpler and more natural.
Increased transparency
Take reporting, for example. Often, a comprehensive report with progress numbers and risk indicators next to work items is what the management wants, only to paint themselves an informed picture of how things are and if they should intervene somehow. When working in a Scrum fashion, all the information is available in the product and sprint backlogs. Since these artifacts are public, everyone can see what’s finished, what’s in progress, and if it’s in a sprint, when it will be finished (by the end of the sprint it’s in).
On top of this, an additional plethora of information is shared at the Sprint Review, where working software is shown to everyone present. Extra information, such as user feedback, is also aired, surpassing the usefulness and detail level of the classic report by miles, making it completely obsolete.
A project plan in terms of a Gantt chart is another prime example. The Gantt chart assumes predictability and certainty. Scrum, however, is best suited for products whose predictability is smashed by the inherent complexities in the product-market interaction and constant learning about what users really need. Therefore, using and maintaining a Gantt chart in a Scrum project is, at best, wasteful and steals time from other value-adding activities. At worst, it’s downright harmful because it constantly sends untrue messages that things will happen exactly as planned.
The primary beneficiary here again is the Scrum team, but the rest of the organization also benefits because of increased transparency.
Foundations
The following are the most important to grasp and must be given sufficient time to digest. This can not be done in the classroom but rather in the workplace and dialogues within it.
Our coaches will facilitate dialogues on these topics since there is usually much more to them than meets the eye.
Empowerment
The age-old truth is that power is never given, but is always taken. That happens even if someone “from above” wants to “give” power. If the person “below” doesn’t want it, the transfer won’t happen. There could be multiple reasons. But, they usually mainly lie in the reluctance to take on the responsibilities that come with it.
To help a person empower themselves, we can do the following things:
- Give them permission to do things and make decisions
- Invite them to actually do it
- Train them in whatever skill necessary
- Mentor and coach them
Once all of the above is provided one can only stand back and wait because – it is worth repeating – empowerment comes from within.
Autonomy
The permission to make decisions on what to build, how to build it, and how to collaborate to achieve it must be handed over to the Scrum team. The whole organization must respect this.
The whole organization must respect this. But many times, it’s easier said than done, and autonomy is not a “is autonomous” or “isn’t autonomous” affair. It’s often a spectrum, but for a complex project, the game needs to be changed from “give them instructions” to “give them information”.
The goal to be pursued here is to be able to make decisions fast by the people with the most information.
Areas in which autonomy can be given are multiple; therefore, consider having the team pick their own:
- Tools such as issue tracker, mockup and requirement management tools, formats, AI helpers, etc.
- Technology used to build the solution includes programming languages, framework, architectural style, branching model, CI/CD approach, deployment target, etc.
- Collaboration style with users and stakeholders and feedback collection mechanisms
While these may be some of the larger general areas, there are certainly specific ones in every organization.
Self-organization
Every team is composed of people with different skills, experience, knowledge, and ways of interacting. Every project is different, and not even the same group of people would approach the same project the same way twice. And if you’re working in Scrum fashion, you’re already working on a product with high unpredictability and constant learning.
So, variability is everywhere. To “lay down” a prescribed way of organization “from the top” onto such cross-functional groups of people will result in friction and inefficiency. A situation where people can’t do anywhere near their best and are constantly frustrated and demotivated.
Therefore, it is imperative to let people self-organize.
To do so, some things need to be fixed, because people can only self-organize when they all know:
- what’s the goal
- exactly who needs to self-organize
- what are the constraints within which they are supposed to self-organize
Example: The end of a sprint is near, and the latest increment needs to be tested and hardened
Goal: harden the increment for a broad rollout to production to all users – meaning no A/B tests will be done, and the rollout is not canary
Who: the whole team (if the team agrees so)
Constraints: by the end of a sprint, hardening is to be done on the staging environment, the team is allowed to set up external systems with which their product is integrated, with any data they might need to perform any scenarios they want, etc.
Coaching sessions
Two completely new roles are being raised during this engagement – the Product Owner and the Scrum Master. Since they are quite different, each will get a separate coaching slot, one per sprint.
Experience has shown that coaching sessions are indispensable for building proficiency in a new role. Typically, real life brings all sorts of questions to be answered while bringing this new way of work to life. Scrum Masters and Product Owners need this extra time to get away and think more slowly about the more profound things that infuse their daily activities. It’s also frequently used to revisit parts of the framework, but this time with real-world questions about how to relate to enabling constraints and how to use them to their advantage best.
In short, the Scrum framework is first seen as a set of disabling rather than enabling constraints, and people really need time to think and recognize the value they bring.
Addressing The Elephant In The Room: The coaching way
Generally speaking, coaching consists of listening, observing, challenging, and asking questions to unlock unexplored thinking avenues in pursuit of new possibilities and ways forward. It’s done either with an individual or a team.
Coaching doesn’t have to have a frame of reference, but in our case, it does, and the frame of reference is Scrum framework. This means that our questions will revolve around how to exploit Scrum’s enabling constraints to your advantage, being for the development of the product and its increment, the team, or its way of work.
Coaching is in almost diametrical opposition to consulting, where the main activities are information gathering, analysis and synthesis. In other words, analyzing, designing and implementing a solution bearing all the responsibility that comes with it.
We do things the coaching way very deliberately because we aim to build your agile and Scrum muscles. The muscles you can then use wherever you need long after we’re gone in any other product, project, or team. We teach you how to catch fish rather than give it to you.
Coach vs. Consultant
The elephant in the room with coaching is always related to who creates the solution and takes responsibility for it.
In coaching, the coach does neither. The client, a person, or a team – must create the solution independently and accept all responsibility for building or implementing it. That’s where the consultant brings value. The coach, however, brings value by changing the client’s perspective, and opens possibilities the client never thought existed. And since the client has the most information and knowledge about the problem at hand (and also wants to upgrade their way of thinking), it’s only best for them to bear all the responsibility of making the whole thing as accurate and beneficial as possible.
Ultimately, both the coach and the consultant bring value, each in its own domain. But care must be taken to call in the right person for the right job.
The Inside Scoop: Lessons learned
Our coaches will monitor the progress of the entire engagement. They will provide you with a detailed report of acceptance of the Scrum framework. As well as an explanation of where and why the friction occurred and how it was resolved. You will reach a certain maturity with the framework. Your following steps will become much more straightforward, albeit only up to a point. This will be shared with a broad audience through a live presentation.
