Working better is what I endeavour. I am allergic to disorganised work and process of rediscovering the wheel. Whenever I recognise a situation when the work is complex, not defined and can go sideways, I put some structure to it so that we can improve.
My approach for doing it originates in Lean and Kaizen steps.
The steps go:
Identify an opportunity for improvement.
Analyze the current work method.
Develop an optimal solution by investigating ideas.
Propose and implement the solution.
Track results of the change.
Standardize the solution for the scale.
Plan for the future and sustain the change
In one of my previous projects, I faced such a situation. That project was my first assignment in the department. This is where the journey begins.
1. Identify an opportunity for improvement.
Organizational requirements
I learned that every project needs to meet organizational requirements. The list had dozen or so security and quality-related requirements. You must meet all the relevant if you wanted to promote your project to production.
2. Analyze the current work method.
When I get familiarized with the process there were not many things that I could refer to. The expected result was vague defined. It could differ from case to case. From department to department. It was defined on the organizational level and suppose to fit to all the projects. Everyone was running project-based his/her way. It was built on the previous experience, but no one documented it. Everyone working on the project had to clarify almost everything. Prepare document template, figure out who deliver what and when. Sometimes you worked on the process with someone who has as little experience as you. Then you could get in the thought of war mode as everyone tried to do as little as possible. I realized that the current way of defining actions and people responsible was unclear. Different people gave me different answers: PO, BA, QA Manager. They all have their own opinion who should do what and how the result should be delivered. The only clear thing was that document preparation is the responsibility of a QA specialist. The person who did not have access to the required artefacts and was a middleman in the whole process. Of course, going this way we could not improve anyhow. If we do not measure it we cannot improve it.
3. Develop an optimal solution.
At the end of my first project and all the meetings and clarifications, I decided to take an initiative and put some structure on this process. I collected relevant data and prepare a process improvement initiative. Following benefits were foreseen:
Remove ambiguity for the team and project members,
Simplification of knowledge sharing with the new team members,
Transparency of the process; clear and sharable with Confluence link,
Professionalism, it is always good to know that responsible people know what needs to be done
Before the meeting with the Sponsor, I have prepared two artifacts.
Table with the time needed for the process & time I have spent with other participants just in meetings.
Process outline in the BPMN notation
How often
Who
What
Time invested (minutes)
one time
Change Team
Stakeholders meetings
150
one time
Change Team
Change proposal
60
one time
Sponsor
Approval
5
1/project
Change Team
Requirements data delivery
15
1/project
Change Team
Tacit knowledge gathering
15
1/project
Rafal
Data analysis
10
1/project
Rafal
Data consolidation
10
1/project
Rafal
New process design
60
Total
325
The time needed for the process to keep on rolling
Time invested for the meetings during reference project
Date
300
10/12
120
15/12
40
17/12
60
03/01
120
05/01
60
10/01
300
19/01
60
24/01
480
29/01
1540
BPMN process definition
Change team
The first step was to find a Sponsor for the initiative and have his buy-in. It was not easy from the beginning. I analyzed data based on my project and estimated potential time-saving in the long go. My estimation for the first noticeable benefits was set to 6 months. I have held a few meetings with the key stakeholders and process participants. Based on the data collected I proposed following solution.
4. Propose and implement the solution.
The process had 3 key phases:
Phase1: Data collection
As we had 14 different cases and depends on the project approach. Data gathering could differ from project to project. At the end of the project, QA expert shared with me all the relevant documents. At this point in time, all the pieces of evidence landed in one Word document. It didn’t help in analyzing it and drawing conclusions. I decided to split it per requirement. Next step was to have a quick meeting with the person to gain tacit knowledge:
who provided key data,
when in the project cycle the data was available,
key elements of the evidence,
required action from the person creating the document.
Phase2: Data analysis and process definition
Once we had enough data for the given requirement first version of the process was created using BPMN notation. How much data is enough? Based on the observation. In our case, it was when we start recognizing emerging patterns. On average it was after five projects. Based on the input I have created a document defining end to end process. It covered:
gathering relevant data,
communication flow,
store it on Confluence. Each process was reviewed and accepted by the team members and relevant stakeholders. After that, it becomes the first version of the working process.
Phase 3: Execute
It took us 7 months to have process created for the 12 out of 14 requirements. At that point, we knew that the most important parts are covered.
As of then at the beginning of the project:
the person responsible for quality identify relevant requirements
reviewed project needs
communicated the approach using defined processes to start building transparency with relevant stakeholders.
5. Track results of the change.
We have worked together on improving processes. It happened whenever someone encountered an edge case. This could be situations that were not covered or adjustment to the flow. Depend on the scope of the change we could have to actions:
The person in charge updated the process and communicate it or if the change was bigger
We gather together to ideate on the best approach to incorporate it in the current flow.
7. Plan for the future and sustain the change
During the next 12 months after finalizing the process, in the team, we didn’t experience any tension or will to get back to old habits. The change was successful. Accepted by the team and organization. Once per while we experienced some tension on the flow, but it never happens more than once or twice. Whenever the situation happened we reviewed current approach adjust and formalize it in the process.
Final thought
In the end, our department got all the expected benefits. The time wasted for the clarification of the responsibilities and managing expectations was gone. Other expected benefit of this approach was knowledge transfer needs. As it was clearly defined:
who do what by when in the project cycle.
It was also easy to ask for help. When any of us was swamped with the project work less busy colleague could help. And these things happen as the whole task was independent and encapsulated. New joiners were able to work on it without any additional guidance. All the actions and already collected evidence were accessible via Confluence for the reference.
Take away
What can you take with you? Whenever you work on:
the repetitive task,
you have dependencies,
it’s not clear what should be done start with:
Identify the current situation – how the work is done? What are the good things? Where are the bottlenecks? Try to collect some data. It’s always good to have a conversation based on the data and not assumptions (or emotions). Visualize it – it helps in fostering conversation.
Ideate ideal state – what are the perfect conditions for this situation. Consider organizational possibilities and limitations. In the best case, you will organize a meeting with all the stakeholders. Listen and write down their struggles and concerns. Bring a common understanding of the possibilities and challenges.
The gap – identify first possible steps that could be taken to close the gap moving you closer to the ideal state. Very often you will be able to identify quick wins. There without much effort, you can get quick improvements and results. Things like checklists or any other quality gates can help here.
And last but not least. Do it together – as a team. It helps to boost morale and bounds within the team. There are not many better ways for team building. Solving problems together and see it working, benefit from it is one of the most profound experiences as a team.
“[…] in this world nothing can be said to be certain, except death and taxes.”
-Benjamin Franklin (1789)
I will extend that quote and add problems. If you want it or not problems are part of our life. Daily, weekly we face a different kind of problems. According to the survey solving skill is one of the most important for success in your professional and personal life. Let’s start with the basics.
“a thing that is difficult to deal with or to understand”
You can visualize problems like an onion. They are built with multiple layers. When we are firefighting providing solutions, we tackle the most outer layer. The core of the problem remains intact.
Considering
these facts, we must have a good and easy to apply the problem-solving
approach, but do you have one?
What
happens generally is that we solve symptoms – outer layer- and not the core of
it. Are you among them?
Below
I’m going to give you a method I’m using that will rocket your problem-solving
capacity. It’s simple and easy to use as food to go! That’s why it’s so good.
It’s called “Five Whys”. It comes from Toyota Production System, so it must be
good J
Origins
Five Whys method was introduced in the 1930s by the founder of Toyota Industries – Sakichi Toyoda.
It
got famous thanks to Taiichi Ohno (father of Kanban) and his book 1950 “Toyota
Production System: Beyond Large-Scale Production” where he stated:
“the basis of Toyota’s scientific approach […] by repeating why five times, the nature of the problem as well as the solution becomes clear.”
In 2008 & 2009 Eric Rice author of Lean Startup (book and methodology) remained us about it in his blog posts.
Currently,
Five Whys is part of:
Kaizen,
Lean manufacturing,
Lean Startup
Six Sigma
Benefits
Simplicity
Anyone can use it; kids are using it already!
You don’t need fancy tools or statistical analysis
Flexibility
You can use it as a standalone technique
You can combine it with other techniques
Inexpensive
It’s a pen & paper solution
No additional costs
Straightforward
Quick learned
In 15 minutes, you can get to the root cause of your problem
When
to use it?
Whenever
you face a problem you want to solve. Think about situations:
You have a process that doesn’t work,
You have a process in place, but it doesn’t deliver the expected result,
Despite taken actions, unwanted circumstances happened repeatedly,
You have anything you want to improve on?
I
will provide you with the tool to help you tackle these problems. You can apply
it to improve any aspect of a product, work or process quality. To be
effective the technique requires the involvement of the people who are part of
the process under investigation. You will need
stakeholders as well as people who work on and with the process.
Five
whys tool is super simple and easy to use… In the business world listen for:
“We’ve always done it this way….”
“No matter what nothing will change here”
“We don’t document our best practices”
There
you go! On a white horse with your newly gather
skill.
As
stated earlier “Five whys” come from Toyota manufactures, where it was used to find human error
behind any technical problem. What is very
important to mention here – you never stop on a person. Your destination for
the root cause is process, procedure, but never a person. You need to jump over
the symptoms to get to the root cause of the problem. The best results you can
achieve with problems that have a single root cause – but not only. I will show
you that later.
How
to use it
The quick answer is to ask five times why starting with “Why did it happen?” and with the fifth answer will give you the root cause of the problem. As simple as that. Period.
Though
the method is Five whys there are no strict rules. Sometimes
you can reach the root cause with 3rd why (make sure it’s not a symptom) whilst
in other cases, you will need to ask why 9 times or more.
This
tool will work well as a standalone problem-solving approach or in combination
with other techniques like:
Fishbone diagram,
Lovebug diagram,
Causal tree diagrams,
Fault Tree Analysis,
Causal Analysis based on System Theory (CAST),
The prospective risk assessment approach
If
you want to use it as part of continuous improvement process or element of your
learning organization… there goes your recipe!
Ingredients
Organize
your space. Use pen & paper with a whiteboard of the flip chart. If you
can’t – go for a digital option. Ensure strong facilitator. Outcomes depend on
this person. It doesn’t have to be senior in position or organization, rather
someone with a curious mind. Someone who will ensure the quality of the process
and outcomes of it. Form a good team and this is where you start your
problem-solving journey.
Recipe
1. Form a team
Anyone who was involved or care about the problem. That could be stakeholders, process owners, any other people affected by it or ones who will create the solution. A cross-functional team with 360 views of the problem will deliver better input and ideas for problem-solving.
2. State the problem
Problem Well–stated is Half–solved”
Charles Kettering.
Write
it down. Make it visible to all the participants. Make sure you all agree on
the problem to you want to solve. Prepare all the fact and figures you can to
show the severity of it. Do not work with assumptions and feelings.
3.
Ask the first “why?”
Start with “Why do you think it happens?” or “Why did it happen?”
4. Collect and record all the answers
Depends on the team size you might need to divide the group. You can create 3-5 teams (you can use 1-2-4-All group process), to challenge each other and bring the best ideas from the team. Record results as a brief meaty statement – nothing verbose.
5. Validate the answers together
This is a very important step. Build the following questions on the previous answers. Team select the most probable problem statement to go forward. As the process goes from “why” to “why” with the invalid reason you will go in totally off track. Wrongly chosen problems at this point can put the team off track (benefits of having diversified team).
6. Ask second “why”, and… so on and so on… till you get to the actionable item.
This
is where you get to the root cause. Five why is only a suggestion. If you need
more questions, go for it! Start a conversation with your problem. You form
questions based on the answer you form preceding “Why”.
How
do you know you are the root cause of the problem? There are a few ways how can
you check.
You can apply SMART to it.
It is simply stated,
You can measure progress on it,
It’s actionable for the team,
Relevant to the problem,
And the action points will be time-bound.
You are at the process or tool level
The penultimate stage might point to the person who based on wrong/missing process, not accurate instruction or wrongly-placed cause the problem
Answers are not useful anymore.
What
to do when answers to the “Why” are outside the room? You have to go and bring
it. It means:
Do the research,
Investigate,
Bring someone who has missing knowledge.
You can also decide to end the meeting and continue when you cover the knowledge gap. To create valuable output you must ensure quality on input. It means you need to rely on data and facts and not on opinions and assumptions.
7. Generate countermeasures
It’s time to create some action points. We call them countermeasures and not solutions. Countermeasures will protect you against reoccurring of the problem. The solution will firefight the symptoms.
8. Record & Communicate
This
is the key step for you to embrace the continuous learning and learning
organization concepts.
You need to record the results of the session a communicate it openly. It
can have a form of list, mind map, fishbone diagram whatever fits you. Save it
in the SharePoint of a wiki page. By making it accessible you let others learn
from your case (continuous learning). Communicating it broadly you
promote learning & innovation culture.
Finally, create an action plan. Who will do what by when?
9. Follow up
Create
a sense of urgency. Pick the relevant date and stick with it. 30, 60, 90 days?
Set up the meeting then and verify if the positive change did happen. Nothing visibly
positive happen? Not a problem. You are smarter, you have learned something,
you have a new data set. Use it and relaunch the process.
There is also one especially good example when in 2004 the author of the blog post experienced how Jeff Bezos applied this technique.
Why did the associate damage his thumb?
Because his thumb got caught in the conveyor.
Why did his thumb get caught in the conveyor?
Because he was chasing his bag, which was on a running conveyor.
Why did he chase his bag?
Because he had placed his bag on the conveyor, which had then started unexpectedly.
Why was his bag on the conveyor?
Because he was using the conveyor as a table.
And so, the root cause of the associate’s damaged thumb is that he simply needed a table. There wasn’t one around and he had used the conveyor as a table. To eliminate further safety incidences, Amazon.com needs to provide tables the appropriate stations and update safety training. It must also look into preventative maintenance standard work.
Source: Adapted from Shmula. 2008. Available: www.shmula.com/
Different
flavours
5
why tree
To
address more complex problems, you can use 5 why tree. It is a game-changer.
Here
you don’t limit your options to only one path. You can
create on any level numerous branches
of the possible causes, to find the multiple
reasons behind each why.
In
such a tree you can see the steam of the tree as a problem, roots are causes
(root cause 😉 and leaves are observable results)
During
the problem-solving journey, you should not spend too much time developing all
the possible branches.
Though this activity is good for the risk
assessment.
For
the root cause analysis focus on the one most probable cause. Always finish
work on one (higher) level before moving to the next (lower) one. Decide
together with the team what is the most probable cause a continue exploring it
further.
Multiple causes can result in
one observation. Like burned food on the pane can be a result of too high
temperature and not stirring the food at the same time. If you do either of
these you will not burn it.
(For
And we use different graphical representation) .
“And”
gate has a different presentation.
As
it is a free form you can adapt it to your need. Colours, symbols, shapes as
you wish.
Every
node branch from the AND gate can result in its own Why tree to be
investigated further down.
Tips
and best practices
You
can use also 5Why tree to uncover not only your problems but also strengths.
Scale
up your strengths.
You can use 5why for this purpose as well. Instead of a problem, you focus on the behaviour you want to embrace. You work on this with 5why and at the end of the process, you have your home-grown recipe for success.
Continuous
innovation – keep documents form the 5whys sessions easily reachable and
available to the audience.
You
will promote a learning culture and help others learn -even many years after
the decision- what makes someone buy a license for that software we all have
(and love or hate it).
Build a culture with “bring your problems” mindset. Countermeasures you will
find together.
Why
countermeasures and not solutions?
Solutions
by nature are targeting the symptoms (firefighting) whilst countermeasures are
preventive and targeting root causes.
You
might know the people skilled with firefighting. When you smell the fire, you
will see they are coming with their solutions. Fire brings them money.
What
do you need for the effective 5 why session?
Ensure trust and openness
Work with the key stakeholders,
Use pen & paper if you can
Confirm with participants understanding of the problem
At the end of session read answers in the reverse order adding “and therefore” at the end
Don’t jump too quickly to the conclusions
Focus on facts, knowledge and data
Assess the process not people
Never settle for the human error
Works best with the teams
Why
not?
5
Whys it’s no silver bullet. It’s not a perfect tool. Among critical opinions
are:
It’s just a basic tool,
Mentioned very often: Different group of people can get to different results
You settle on the symptoms; not getting deep enough to reach the root cause
The team is limited with their knowledge
It’s confirmation bias – “I already told you before we started”
Not able to deliver answers on the “why?” – We don’t know what we don’t know
Focus on one root cause leaving out other causes (not applicable for the tree approach)
With multiple roots causes prioritization challenge. (tree related)
Assuming the solution delivered with 5th why is the best one.
The inexperienced facilitator can direct the conversation to the wrong path
Targeting the most distal cause while the best use will be on a proximate one.
Many why’s might go through it
Counter
measurements
·Get yourself good facilitator (at least). The one who will include everyone, ask good/right supporting questions. When you have problems with asking good questions probably you are on the wrong problem. When we work on wrong problems, we asked wrong questions
Use 5 why tree diagram
Verify each answer on the current “why” before going forward
Focus of the positive aspects/strengths (if you have) instead of asking “why something doesn’t happen” ask “why something happens?” It can be sells, processes, meeting.
Use it with combination with other techniques focusing on data collection.
Use 3 whose to help with 5 whys (Reg Revans)
Who knows?
The situation is best informed about how to solve it.
Who cares?
About the problem
Who can?
Act on the solution
Ensure you have all these people in the facilitation area.
Keep an eye on the answers that are not providing quality and value especially starting with not enough (time/money/manpower)
·
Conclusion
Have
you heard that we should deliver solutions, not the problems? How many of these
you’ve seen these solutions delivered and acted on?
With this technique, you can change this situation by changing your approach. Ask for problems and deliver solutions. Deliver solution as a team. This part alone promotes a culture of continuous improvement. The team will feel empowered and will build self-trust. It’s one of the strongest bound for the team building. Solve the problem together, deliver fix together, and improve on that together. 5 why technique gives your team tool they can trust. Together you will have confidence that from now on you can improve processes daily.
5 Whys with all these flavours are one of my favourite problems solving techniques. It’s easy to explain, easy to understand and easy to apply. The best part of it is that the result very often is bigger than initial expectations. Every method has its limitations.
To
get the best from the tool:
work on it with the
cross-functional team,
work on it with the cross-functional team,
collaborate on the problem and bring 360 views on it.
When
you apply the steps, mentioned you will bring a solution to every problem you
will tackle.
This
is the simplest way how can you encourage continuous improvement within your
team without blaming each other. By
bringing it to the team you give them a tool they can trust to boost their
confidence in the daily improvement process. And it’s
fun to use 😊 Now it’s yours. Take it with you and start using. You won’t be disappointed.
Recently in our Agile community of practice, one of my colleagues asked me:
What is Scrum Master doing the whole day? Is this a full-time job? I have heard that our company is claiming this is 66% time job. Is this good and accurate estimation?
I have followed up on this topic and I have found out there are more confused people around. I have my own Scrum Master experience and I know what I was busy with. But I start wondering: with what type of daily activities the community of SM is busy with? What employees are expecting from a person in that role? And finally how much reality match the role description from The Scrum Guide? Let’s check one by one…
Scrum Master by the book. What is on the menu?
The best place to start the journey is The Scrum Guide itself. You can see there that Scrum Master has on his plate service towards three areas:
Product Owner,
Development Team
Organization
Product Owner
The Scrum Master serves the Product Owner in several ways, including: · Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible; · Finding techniques for effective Product Backlog management; · Helping the Scrum Team understand the need for clear and concise Product Backlog items; · Understanding product planning in an empirical environment; · Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value; · Understanding and practicing agility; and, · Facilitating Scrum events as requested or needed.
The Scrum Master serves the Development Team in several ways, including: · Coaching the Development Team in self-organization and cross-functionality; · Helping the Development Team to create high-value products; · Removing impediments to the Development Team’s progress; · Facilitating Scrum events as requested or needed; and, · Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.
The Scrum Master serves the organization in several ways, including: · Leading and coaching the organization in its Scrum adoption; · Planning Scrum implementations within the organization; · Helping employees and stakeholders understand and enact Scrum and empirical product development; · Causing change that increases the productivity of the Scrum Team; and, · Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.
You know the rule, he who pays the piper calls the tune. To keep the job SM needs to deliver according to the expectation. First, you need to prove yourself before you start rocking that boat 😉
In November 2019 I have analyses +30 job offers from Switzerland, UK and the US. As a result, I have created a mind map with all the expectations towards the person in the SM position.
As you can see (or not ;)) expectations are various. From valid to funny ones. There are visible pattern and the most required skills are:
Knowledge
agile practices, Scrum and Kanban,
facilitation skills,
conflict resolution / mediation,
excellent communication skills,
knowledge of different estimation techniques,
Team
organize and lead ceremonies,
coach both team and individuals,
apply & help to understand the theory, practice, rules, and values of Scrum,
guide the team, provide training,
foster motivation and self-organization,
manage risks & issues,
protect the team & ensure focus,
Product Owner
help with release planning,
help with backlog preparation & prioritization,
Organization
communicate with stakeholders
As you can see there is a significant gap between what is in The Scrum Guide and the expectations from the job spec. This gap is visible, especially in Organization and Product Owner area. Scrum Master meant to serve much more there but companies don’t want/expect that. I’m wondering why? Any thoughts?
So show me your kitchen area. How you do it?
After this lengthy introduction, it’s time for the ultimate question: What is the Scrum Master doing? Unfortunately, there is not much good research on this topic. I have found only one from Stefan Wolpers. The results of his survey based on 242 valid responses he normalized and summarize to this:
Product backlog refinement: 1.00 hours/week Sprint planning: 0.75 hours/week Stand-ups: 1.50 hours/week Sprint review: 0.50 hours/week Sprint retrospective: 0.75 hours/week Learning: 2.00 hours/week Training of teammates: 3.00 hours/week Training of stakeholders: 2.00 hours/week
You should keep in mind that checking the results that:
” The survey comprised of ten questions, two addressing technicalities (sprint length and team size) and eight addressing the two most intensive work areas: scrum ceremonies as well as education and training of teammates, stakeholders, and the scrum master herself. “
On average Scrum Masters dedicated total 11.50 hours/week to these activities. Considering 6 working hours/day (what it very optimistic) it gives us 2 working days. How does SMs spend the other 3 days? (you can check the survey itself there are some good hints as well).
I’ve read that one should prepare for the meeting twice as long as it’s a schedule. If we apply it here it will fill rest of the week and we have it all clear, right? Well, this will be too easy.
The cadence of the Scrum ceremonies
Scrum Master’s day very much depends on the Sprint stage. As you have seen on the data above meetings/ceremonies takes a lot of time. This is the first thing to consider thinking about Scrum Master day. Scrum ceremonies cadence enforce a specific kind of engagement. So you must realize that these days you will be very busy with specific kind of tasks. Printing user stories, doing Jira stuff, talking to many people from the team, stakeholders name it. You dedicated all your time to the team. No questions about it. Of course, your engagement will depend on the maturity of the team and …project. 🙂 Team maturity I will cover below.
Shu-Ha-Ri
How SM allocate his or her time depends on team maturity. The best method of learning is by doing. Pairing with someone who masters it already will elevate your learning experience.
The more immature team the more SM time it needs. I like the Shu-Ha-Ri model introduced to the Agile world by Alistair Cockburn (co-authors of Agile Manifesto). In a few words:
“Shu” is when a student follows the master without questioning his approach or techniques. During “Ha” s/he starts asking questions and reaching to the roof of the chosen way. In the final “Ri” stage student becomes master and start creating own techniques. Spotify created their model going through this flow. You cannot just copy and paste agile adoption. You need to discover your way by continuous learning and adapting. Details of the model: https://www.martinfowler.com/bliki/ShuHaRi.html
So back to our SM daily responsibilities with a bit of food twist 🙂
Shu – let’s make a spaghetti we want
We know in general “what” but we don’t know “how”. We need someone who will walk us through the path. You are hungry. Do you want spaghetti? “Yes, please” Ok! I check what you have in the fridge and based on my knowledge and our taste I say “Let’s make carbonara. Trust me. You will love it!”. We will make it together.
When the team in in the “Shu” stage it needs lots of attention from the Scrum Master. More answers than questions, more teaching than coaching. You need to teach the team and explain why do we have all the events, what is the goal of it. Gain their trust. Build rapport and introduce (never force) your favourite and proven tools from the SM tool-box. Suggest running experiments based on your observation. Let them make mistakes and learn from it especially if it’s not costly and you can easily recover from them. It’s very important at this stage to introduce validated learning. Do, measure and adjust. All these points are activities that take your time.
Product Owner (PO) might be on the different maturity level than Dev Team. SM must pair up with PO every week, daily if needed. You need to be like Batman and Robin, Thelma & Louise, Rick and Morty. Among other things, you work together to increase the clarity and transparency of the product backlog items. You discuss vision and strategy for the product. There are many things that the PO need to have in the tool-box. SM has to pay attention if these tools are in use when appropriate. It’s not part of this article to name them, but as a SM you should know when and why to use them.
SM and Organization might be not yet there to work together on the agile transformation together. SM needs to work on the basics, and the organization needs to know more about its changeability. Taking the team perspective the best SM can do for/with the organization is to deliver the message from the retrospectives. Make it transparent and visible what slows us in agile adoption. Very important is to make sure that it is a two-way communication channel. Retrospective points for the organization should get back to the team. Any feedback (e.g. we don’t have money/ time/ resources for this) on the outcome from the retro is better than no feedback at all. It’s highly demotivating for the team to realize that no one cares about their efforts. It costs nothing to send a leader (decision person) to the team during one of the next retros and deliver the message. Believe me – It makes a huge difference.
Ha – I like your carbonara.
I want to have it my way. You play with the quantity of this or that. Less bacon more sauce. You learned basics you experimented many times. Different wine (yes it’s part of the recipe), different ingredients, you have found your way. Did you check how others do it? Let’s go to Italy to taste it there! Is it any better?
You challenge the team whenever you see inefficiency. One of my favourite root cause analysis tools originates from Lean and is known as “5x Why?”. Ask why we are doing this or that? Spend more time on personal coaching. Learn personal motivation, goals, ambitions. This is the ultimate coaching time. You can guide them to do better when low hanging fruits were already collected. There are no quick wins anymore. You need to dig deeper to find the next goals and challenge other frontiers. Test automation? Pair programming? Involve the UX team during the design process? Grow out of your role? There are many ways to go. Your role is to help them make better decisions, ask better questions, be better in any way.
Product Owner – once s/he knows the tool-box (you can google it) it’s time to focus on the questions like “is this feature worth the effort?” Ask about ROI (return on investment) be a consultant for the domain and help to make better decisions. Learn the business to be a partner in the project conversations. Do you know the market you are in?
Your team deliver amazing results. You are getting visibility outside of your team. You start working at a higher level. Think about scaling agility outside of your team & department. Work closer with the SM of the interfacing teams. If you don’t have it yet you should create Scrum of Scrums. Because you care about your team you start a community of practice. Your team members can grow in and out of their expertise. By doing it you remove communication silos. You need to help it grow.
Ri – carbonara with asparagus is what I want!
You develop your taste. You have tried different meals, carbonaras, you have experimented with different ingredients. It’s time to make it yours. Based on your, skills, experience, knowledge and resources available. I love the one with asparagus.
There is not much you can do on the team level. You keep yourself around especially to address organizational issues. You make sure the machine works with the optimal pace. Ceremonies are there, they are self-managed, they keep each other accountable and they are working on their “Spotify model”. Once in awhile challenge them so that they never stop experimenting. There is no growth without taking a risk.
Product Owner. Are you AirBnB, UBER or Netflix of your business? If not then it’s time to check why. Innovation is not born overnight. It’s a result of doing outstanding well all the basic things. Ask good questions (what does it mean, you can ask? 🙂 learn it! ), build your next iterations base on the numbers, not opinions (unless your PO surname is Rockefeller of Jobs 😉 ).
Everybody wants to save the Earth; nobody wants to help Mom do the dishes.
Is your HR, operations, maintenance services and canteen in your Organization works in an Agile way? If yes, then you can say – Elvis had left the building and it is time to go home. Otherwise, there is still work for you to be done. You are not a Scrum Master any more. You grow to the role of Agile Coach or even Agile Organizational Coach. Your next goal might be the first Organizational promise from The Scrum Guide:
Leading and coaching the organization in its Scrum adoption;
scrumguides.com
It’s all about expectations.
Have you ever went to the: restaurant, visit a city or bought anything based on the reviews and promises and end up being disappointed? It’s a very very bad feeling when expectations are not met. Remember:
A dead Scrum Master is a useless Scrum Master.
Ken Schwaber.
As mentioned above there are so many things that Scrum Master should be doing and yet there are some never grow out from the Secretary role. Sometimes this is an initial expectation of the employee, but you can work on this. This is why many of our colleagues see the SM role as someone who: do the Jira, do the stand-up, and let’s have the retro ….done. If you want to spot the anti-pattern ask “What is the experiment they are doing right now? The last one? When it was? Where are the results?” ask SM to join you for the meeting during the stand-up time. Does the stand-up happen or the team waited for Scrum Master to join?
I agree that the skilful Scrum Master can serve to 3 or even more scrum teams. But great Scrum Master can serve and master one (it might be coming from Geoff Watts – author of “Scrum Mastery). I mean bringing them to the “Ri” level. It’s a people role. You work for them and with them. You polish your skills daily.
“What Scrum Master does the whole day?” I hope at this point you realize that there is no clear answer to that question. Is it a Sprint Planning day? Is it a Sprint Retrospective day? What is team maturity level? How long you work together? How long you are in the organization? I must amid there is no clear answer to that question.
I wanted to present 3 viewpoints from the areas of:
what Scrum Master should be doing by the book,
what is expected by the employer
what could be done by a passionate individual.
If you are already a Scrum Master please keep in mind that this role is not the end station of your journey. You should see it as a step on your path to becoming an Agile Coach. Grow. Develop new skills. Never stop learning. Being a Scrum Master is not only a position. It is a promise to yourself to your team and organization. Promise that you will never stop improving, bringing best from your team, individuals and organization. Learn how to coach, teach, mentor, facilitate, develop products, scale agility, improve UX. The list goes on, and on and on… The key part of your growth are questions you ask yourself and others. It’s not about “if” it’s about “how”.
PS. Ceremonies were in the previous version of Scrum Guide now we call them Events
About Me
Hi, my name is Rafal. I am a long-time Agile & food passionate. I approach Agile the same way as meal preparation. From available ingredients deliver the best experience possible. Welcome to my Agile kitchen and Enjoy it! :)
This website uses cookies to improve your experience. We'll assume you're ok with this, but you can opt-out if you wish. Cookie settingsACCEPT
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
This website uses cookies to improve your experience while you navigate through the website. Out of these cookies, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may have an effect on your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
Recent Comments