Starting with Scrum Values
Apart from the various core elements and roles, scrum is based on people interactions, and healthy interactions result to a healthy scrum implementation. Read again the agile manifesto values and principles and you will see that it is more like a mindset, a collection of beliefs that addresses the human and social side of working as a team. Scrum values address the same need and for that reason are important! The set of values scrum is founded are listed below:
Be willing to commit to a goal. Scrum provides people all the authority they need to meet their commitments.
Do your job. Focus all your efforts and skills on doing the work that you’ve committed to do. Don’t worry about anything else. Focus on only a few things at a time while doing the right next things.
Scrum keeps everything about a project and everyday work visible to everyone.
Individuals are shaped by their background and their experiences. It is important to respect the different people who comprise a team.
Have the courage to commit, to act, to be open, to expect respect and to undertake greater challenges.
try this: Teach your teams about Scrum Values. Whenever you observe a weak scrum implementation start reflecting on your values. Are you focused, is everything open? Are you committed to your goals? Do you show respect and have the courage to bring everything in surface? Incorporate these values in your team’s working agreements, reflect even on a daily basis.
What is scrum
In a few words, scrum is an agile framework for developing and sustaining complex products (refer to this post, “where to apply an agile methodology”) Scrum is a lightweight, simple to understand but difficult to master! It is based, as all agile methodologies, on empirical process control theory, which means that transparency, inspection and adaptation are the tree important pillars. Scrum follows an iterative, incremental approach aiming to optimize predictability and control risks.
When a new idea for a product is generated or when new features or enhancement for an existing product are emerged scrum starts with the generation of a product backlog that ideally contains abstract level, coarser grained items (a.k.a epics, MMFs, features e.t.c) at the bottom, and more detailed, finer grained items at the top (a.k.a user stories). Items should be prioritized based on the value and the impact will return if implemented. As an alternative of a one dimension “flat” prioritized product backlogs take a look in this post (coming soon) on creating two dimension product backlog structures to explore its benefits comparing to flat ones!
When the backlog is available the work needs to be done is organized in a series of stable development cycles (a.k.a sprints). There is need that there are enough finer grained product backlog items with enough details, well understood and fulfills a few criteria ready to be implemented in upcoming iterations.
The Scrum framework
In Scrum there are three roles that consist the Scrum team, five (six) events, three (five) artifacts and one transparency artifact. The complete guide of scrum could be found here
Someone could say that it’s not possible to describe in just 16 pages a complete framework and i think that this is the beauty of scrum guide! It’s written in such a way with just enough details you need to succeed with your scrum implementation. I’ve been in many discussions around scrum role descriptions, artifacts, events trying to redefine them and make them fit in specific context. Even if this is seem reasonable to do i think it might prevent you get the most out of this framework. Everything you need to consider is described in the guide and there are many other resources (take a look at he end of the post) that could help you find practices, ways that will enhance your scrum implementation.
So, prior discussing what a PdO is doing in scrum and more specific what a PdO should do in your organziation, what the dev-team or the ScM is responsible for, read the guide and try to understand it in depth! When you have a clear understanding then reflect on your own context. What needs to be changed? Remember that it’s easier to adapt the framework than changing your existing habits! It’s your decision.
As said in some other posts if you are thinking to implement scrum start doing that by following the rules of the game (Shu). Understand it in depth (Ha) try various practices, work with all the surfaced dysfunctions.Then learn from your experience and adapt it to your unveil needs (Ri)! Go beyond the roles, focus on delivering value!
try this: read the scrum guide wearing different lenses. Wear the dev-team lenses and focus on what the team is doing in every event, which are team’s responsibilities and rules that need to be followed, how the team is related to scrum artifacts, organization e.t.c? Keep your notes. Repeat it until all the roles are covered! If you are a group (for example during a training), split the roles in subgroups. Read the guide through your assigned role perspective. Share your notes with your subgroup and discuss them. Exchange roles among the subgroups and repeat the same process. If you are timely constrained then just share with the other subgroups your role outcome!