Archive for category Team
Ever since I was a child I have had this instinctive urge for expansion and growth.
To me, the function and duty of a quality human being
is the sincere and honest development of one’s potential.
Working as active Scrum Practitioner for almost 9+ years I have come up with my understanding of what is Scrum Master’s role, service to the team and key responsibilities. Earlier I have written about what Scrum Master should master, here I would like to concentrate on 8 Key Aspects of Scrum Master work. Focus areas so to say. Here those are….
- Facilitates Sprint Planning Meeting
- Facilitates Sprint Review Meeting
- Facilitates Backlog Refinement (aka Grooming) Meeting
- Facilitates Sprint Retrospective Meeting
- Facilitates Daily Scrum
- Facilitates Release / Roadmap Planning Sessions
- Facilitates whatever/whenever else Team and/or stakeholders communication is required to be facilitated (not about any collaboration)
Purpose: to improve shared task clarity, planning, bring in more transparency over status quo for team to see where do they stand (and plan to go, and what have they achieved and how they want to improve) and their work results, help team to be able to enhance communication and perform their daily work
- Cultivates “us” vs. “me” culture and mindset
- Enables and fosters team to self-organize
- Helps team to make decisions
- Supports team through stages of its development
- Coaches individual team members on communication, collaboration and teamwork when necessary
- Increases “bandwidth” of communication among team members
- Observes team and talks to every single team member
- When required does one-on-ones to help through raising conflicts
- Navigates conflicts (involves management when necessary)
Purpose: to build up better team => better understanding each other => improved collaboration among team members => improved team performance
- Guards team agreements, decisions and process (e.g. retrospective decisions, agreed “howtos”, DoD, DoR, review process, etc)
- Make team stick to its agreements, drives teamwork and respect towards owning decisions, leading to performance improvements
- Keeps balance between fulfilling business (Product Owner) needs and maintaining team sustainable pace, so that business needs are addressed by PO requests while team development and pace is not forgotten.
- Makes sure environment is as Team empowering as possible. Empowerment raises team feeling of ownership that rises up dedication and servers to better results
- Helps the team and Product Owner to maintain their artifacts (product backlog, sprint backlog, task and action boards, sprint/release burndown charts, tickets comments, story maps, etc.)
Purpose: create and maintain environment where high demand is possible. Here is why that is important
Impediment “Fisher” & Resolver
- Creates environment for effective impediment “fishing” and removal. Cultivates transparency and information radiation as pre-requisite for impediment clarity and removal
- Enables team to respond to impediments
- Raises awareness of team’s impediments
- Coaches team in resolving impediments (the one’s that could be solved by team)
- Helps team to discover new impediments (wastes). Constantly questions the status-quo
- Helps to resolve impediments / take ownership of those cannot be solved within / by team
- Improves efficiency of the team by helping with eliminating impediments
- Escalates and follows up on impediments to where they belong
“High Focus” Promoter
- Shields team from external interferences (extra tasks, todos not agreed with Product Owner, etc)
- Enables team to concentrate on most important todos, achieving “state of flow” and high concentration.
- Helps to avoid wastes caused by context-switching and to avoid team member burn-outs
- Gardens team’s sustainable pace, so that combined with “empowered” environment of high demand is possible
- Increases feeling of “urgency” and highlights how much is left to achieve (e.g. tickets, story tasks, story points, etc.), e.g. with the help of burndown charts, tickets left, etc.
- Helps team to focus on regularly achieving small thing to create feeling of fulfillment and good progress
Motivator and Coach
- Promotes positive thinking, open, honest and respectful feedback culture
- Motivates team to improve team productivity regularly
- Helps to raise team morale, to increase dedication and to improve team deliverables
- Helps to create feeling of achievement
- Creates environment of excellence and continuous improvement (and mindset of seeking for improvements)
- Creates mindset of “quality first”, intolerance to poor quality and continuous improvement
- Regularly takes care of team’s “happiness” (and involves management when necessary)
- Coaches and teaches required mindset, frameworks and engineering practices (Lean thinking, Scrum, Kanban, XP, pair programming, continuous integration, test automation, etc.)
- Teaches and integrates new team members into working process and agreements (and into the team)
- Serves as agent for change and positive challenger of the team
- Reflects integrity and leads by example (e.g. being on time, continuously self-improving, sticking to agreements, etc.…)
- Reflects Lean thinking and Agile principles to the team
- Reflects on reality and promotes transparency on status-quo to question
- Makes things measurable where applicable and possible to illustrate team progress: brings transparency about what is done, how much is achieved, so that weaknesses are easier to identify and potential improvements are easier to see
- Helps team to radiate information (e.g. burndowa, burnup charts, impediment boards, hapiness matrix, knowledge matrix, peerwork matris, etc.)
- Introduces required measurements for team to see regularly its work results (e.g. tickets achieved, stories done, story points achieved, bugs popped up/fixed, retrospective decisions implemented, ..)
- Uses collected data to think and question team and act if required
Agileist: outside of Scrum Team
- Shares Agile/Lean mindset within organization
- Shares best practices and tools, so that other Scrum Masters can benefit / see different perspective of managing things and company can benefit from enriched toolbox of methods and practices
- Collaborates and helps other Stakeholders to learn how their requests could be fulfilled with the team doing Scrum (or Kanban), so that other Stakeholders could get their requests address while team’ pace is also protected
- Helps to improve organization by creating learning organization
- Helps to address organization’s impediments
Last and not least there are many other things that do not belong to this structure. Those are dependent on situation and circumstances. And those are still handled by great Scrum Masters 🙂
I always wanted to come up with the collection of my favorite” Teaming Up” Retrospectives, those that allow to build up steel-strong teams, increase connection bandwidth between team members and increase motivation on teamwork. So here is it…
Check in before you start…
To start building up a team you need to cultivate Trust among team members. This is foundation you have to establish, otherwise open talk is impossible. One of the best way to check in for Teaming up retrospectives is to offer one of those statements to the team and ask each team member to reflect on Teamwork clearly with the statement like “What is in that for us?” or “How do you understand that?” or “Why you think this is important for us as a team?”
Here are some examples of statements you can use to ask these questions:
1. Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
2. At the end of an iteration everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgement used to embarrass or de-motivate.
3. Team is a partnership of unique people who bring out the very best in each other, and who know that even though they are wonderful as individuals, they are even better together.
- Coming together is a beginning;
- Keeping together is progress;
- Working together is success.
Then I would suggest to move to one of the following exercises …
Exercise 1: My Personal Poster (shorten the distance between us)!
When: with new team / getting to know each other, helping to build up personal connections.
Heads up: may be touchy-feely to some team members (especially shy ones). Make sure people do not feel uncomfortable “revealing” their personal.
Script: We are going to get to know ourselves better! Opening yourself creates relationships!
Please fill in the following template and prepare poster of your life and share it with the colleagues 🙂
- My Name
- 3-4 facts on my personal
- Decisive (crucial) events in my life up to know that influenced who I am most:
- (Could draw timeline of your life with some important data you are willing to share)
- What do I do in my spare time (hobbies, activities)
- What are my personal strengths?
- What are my personal weaknesses (might be tough one)?
- What has been a source of pleasure for me today?
- What kind of secret about myself am I willing to reveal to you?
As soon as poster is ready team members take turn to tell their “Stories” followed by team questions. Aim is to learn as much as possible about team member to understand his/her past and what makes him/her acting in a certain way.
Exercise 2: Cool/Uncool Team member (to share what we want / want to avoid)
When: when you sense team starts having some issues with the “norms” or unspoken “rules” (with the aim to have
Heads up: Make sure it is not turned into personal “blaming” session.
Script: We are going to develop ongoing guide for desired and undesired team behavior .
Please imagine two hypothetical team members (no real persons and names are allowed):
- Cool guy, team member of my dream 🙂
- Uncool guy, team member I would not like to work with 😦
Describe what each of those hypothetical characters does, how behaves one treat/behavior pattern per sticky note that are important for you. Mark positive ones with (+) and negative ones with (-). Prepare to share and discuss with colleagues. Perhaps clustering similar topics and prioritizing would help. I did this excerscize for many teams, – some were discrubing their team without names, others – went quite abstract.
If discussion is held too abstract ask team: “Do we have similar issues?”, “Which ones?”
Exercise 3: Team Matrix (to share openly how do we feel and want to change)
When: there is need to share how does each team member feels him/herself in a team and about teamwork.
Heads up: create safe environment! Make sure no accusation happen.
Script: Please prepare your answers for the following questions (one per sticky note):
- How do I feel myself in the team?
- How I would like to change it?
- How I would like that person X changes certain behavior (how do I feel)?
- If X changes that what do I offer in return?
- How I am ready to help my team?
RULE: no accusations expressed as wishes!
Write those questions on the whiteboard on the left while put team members names on the top, to form matrix. Offer each team member to fill his column, explaining his position followed up by an open discussion.
Exercise 4: Brilliant moments (to learn from our positive past)
When: when there is need for a team to appreciate their positive past and learn from their great moments.
Heads up: n/a
Script: We are going to examine what moments of the past we would like to repeat and how make them influence our team positively and stronger!
Split team in pairs and ask them to interview each other. Prepare interview template and hand over (see below). Ask interviewer to fill it during Interview. First ask to execute only part 1:
- Your brilliant moment: ask to describe certain situation when something really worked in recent past, that team member considers as achievement.
- Why was this moment so brilliant? What was so special on this brilliant moment for her/him?
- What else?
Then ask pairs to switch roles and redo Part 1 for other team member.
Afterwards ask each of interviewers to write down what they have learned about their pair also filling Part 2:
- Because of what you have just said, it appears to me that you are someone who is / has / can….
Then again ask to share findings with pair and think together to answer part 3:
- If these strengths would play a larger role in your work life, what would you notice?
- What else?
- What little things could their colleagues might notice?
- Some small actions that she/he might try in the next days?
Then let everyone tell the story of team member they have interviewed to entire group. Then let open discussion, sharing findings and decisions.
Exercise 5: Our Personal Communication Style (to learn how we are communicating)
When: with new team / getting to know each other, helping to learn their similarities / differences in communication style.
Heads up: n/a
Script: We are going to experience how we like to communicate and in what way it is better to approach certain team
Brainwriting exercise: My communication style (underline what is more relevant to you)
- Do I prefer read or listen?
- Am I fan of short statements or do I prefer long reports?
- Do I want long meetings every month or prefer short meetings more often?
- Do I like to know entire story, every single bit, or do I want to know just the headline (big picture)?
- Is it sufficient someone says something to me once or do I have to be reminded several times until I notice?
Brainwriting exercise: colleagues communication style (underline what is more relevant to your colleague)
NOTE: split in pairs or consider colleague sitting left/right to you
- Does my colleague prefer read or listen?
- Is she/he I fan of short statements or prefers long reports?
- Does he/she want long meetings every month or prefers short meetings more often?
- Does she/he like to know entire story, every single bit, or wants to know just the headline (big picture)?
- Is it sufficient someone says something to me once or do I have to be reminded several times until I notice?
- Is my colleague totally focused on his work and therefore unapproachable or he is someone who is more team oriented and more pleasant and social?
The exercise is to guess which team member prefers what and learn from those diverse preferences.
Exercise 6: appreciation game (to flourish energy of team members)
When: to help team show appreciation to each other and provide constructive feedback
Script: We are going to thank each other for certain things.
Create half circle of chairs. Place another chair on the other side facing the rest. Ask team for trust and respect, honesty and attention.
To start, ask one person to volunteer to be in the ‘Main Chair’. Other members take turns, to say things they liked about the ‘Main Chair’ person help to the team. Following statement might be used:
- “You really helped team when.. and when..” ( 2 statements) followed by
- “What would be great to have more is….”( 1 statement)
“Knowing others is intelligence; knowing yourself is true wisdom.
Mastering others is strength; mastering yourself is true power
Some may think Scrum Master is an easy job to do and is just about facilitation. That is so wrong. It is very important for Scrum Master to master himself , and many challenging situations:) And here are some “traps” scrum master may fall in I would like to show some ways out.
So, here is collection of my favorite tips for Scrum Masters …
Fight an attempt to take sides. This is hard if you consider opinion close to yours, also not always easy to resist personal favors.
Ask yourself what is more important now: to get tactical issue solved (and please your ego) or enable team in solving it, have artificial harmony or heavy storming that uncovers real issues to solve.
Mind also talking affirmative words, like “yes”, “ok”, rather use neutral: “thanks”…This is very important when managing conflicts and taking 1 on 2 persons involved in conflict and navigate them.
Keep the balance!
Storming is unavoidable part of any team development. What you need to keep in mind that team will try to involve you in storming with them. Team members will dump all their problems on you. Often some will talk to you when they are supposed to talk to the team when they are sad, mad, frustrated. They will also try to get you on “their side”. These are indication they want you in the storming and appealing to you as to judge and expect you to take certain position (their side).
Do not let yourself be involved in that. Reflect responsibility gently to the team. Stay patient, turn emotions off. Team should feel you are with them, available and supporting, use “we”, never “you”, but position yourself as not part of storming team, so they seek solutions among themselves and storm together.
Definitely! As Scrum Master you have not right to freak around! You are the one that shall stay calm and do not “reflect” when everything / everyone else around does. Mastering does not only ends in what you say and do, but also how. Include body language, facial expression, tone and most importantly thoughts.
Some team members may behave the way so that their intentions are not clear to you (or the other team members). They also may not look ok to you. Any assumption is false here! You simply do not know their insights. Or at least this statement is very useful to be stated periodically. Therefore always assume that you do not know them.
Ask for clarity, ask directly , find comfortable time and place, do it 1 on 1. Practicing active listening will also help: https://en.wikipedia.org/wiki/Active_listening
Do not stop conflicts, navigate them. This means, stay neutral, stay calm, understand intentions and most importantly make sides involved to understand each other’s intentions, increase trust and help to reduce negative impact on team.
I always try to make conflicting side open up about how do they feel. Important here is to start conversation with “I” and not “You” since statements starting with “you” quite often sound “blamish”.
There are situation when team in involved in heavy debates and cannot come to an agreement. You as facilitator shall help them to come to a solution, but beware of trap of compromise in order to get common agreement.
Common agreement is something crafted of the opinions of the team, that may be very diverse. Do not start engineer something on top of the parts, consisting of opinions of team members. Because:
- They may be not compatible
- It is not their but your ideas that glue them (so do not expect much enthusiasm and energy)
Make sure agreements are truly owned by the team, it is better to state there is no agreement rather then one designed under your influence, for the sake of having one. Be patient and rather let team do it!
There will be times when your mind will attempt to drift away from here and now. This might happen if you start thinking about what to do next, or why certain thing did happen. Drop it! Stay present with the team and what is currently happening and what is the most important problem they are trying to solve, to be able to facilitate their collaboration efficiently.
Master Powerful Questions
You need to be able to challenge. The trick for servant leader is to challenge the team the way it is not closes opportunities and focuses mindset on thinking how to achieve certain things instead of narrowing them down. Here comes the power of open questions, those that start with magic words like “What”, “How”, “Who”, “Why” and “Why not”.
Also consider silence and one of the most powerful one. Do not try to fill it. Let there be uncomfortable silence. Let there be many opportunities. Here is when team thinking starts…
Here are some very nice inspiring and useful questions I would reccomend
Last but not least one.
The more negative things you will witness the more positivity you should give to the team. This not about being “happy”, this is about enabling team via believing in their capability, empowering with trust and leading by example.
Turn mistakes of others into inspiring and powerful conversation to help them to learn. When it is getting hard, close your eyes and remember positive moment when team performed well. Remind those. Encourage team and yourself. And do not drag mistakes team and you did in the past with you. Leave them!
Stay rich for your capacity for positivity, garden your mind and team spirit!
Plans are useless but planning is indispensable.
Dwight D. Eisenhower
What goes up must come down. This is true of aircraft in flight. Bringing an aircraft back to the ground safely is the primary concern, but it also is necessary that the return to the ground occur at the intended landing point. The descent from flight altitude must be started well before the intended landing point is reached, and the rate at which the aircraft descends must be calculated, so that the aircraft reaches ground level just as it reaches the desired landing point. This controlled drop in altitude is called the descent rate.
Let us use these tips to learn how we can apply it for Agile development team.
The analogy here is very close…
Imagine team is a crew and airplane is the sprint, while burndown chart (CI, established NFRs, …) are navigation tools that allow to land sprint properly, with all passengers (stories) safe, at right airport (release) and on time (sprint review meeting).
So the crew must take into consideration many factors as altitude, distance to destination, aircraft descent velocity, weather conditions, fuel consumption, etc..
One of the key factors that allow to have successful landing of aircraft is choosing the correct descending point. You for sure remember that at some point you see “fasten your seat-belts” sign on and flight attendants start asking you to follow the “landing rules”. This happens not right before airplane lands but some time in advance…
Similarly Agile team must consider many factors to get things done on time with required quality baked in (number of stories in progress, time left finishing development, regression testing left, meeting agreed non-functional requirements, preparing for the demo, etc. ). And shall start finishing things in advance to guarantee proper “landing”.
How much in advance?
It heavily depends on variety of factors: team maturity and confidence, extent team can rely on automated testing (and extent product is covered with automated functional testing), need to check for non-functional requirements, all kind of risks, etc…
Sprint (Flight) Plan and Descent Point
I will bring real life example.
In a picture below team had planned sprint in the way to start checking product on development environment in advance (while possibly working on integration defects), then deploy it on staging environment the last day of the sprint to make required final performance/load tests, confirm release/deployment plan and test application closest possible to the real life conditions:
Part of this plan presumed that in case all is OK, free team members will focus on less priority bugs, increase unit tests coverage, prepare for upcoming sprint, focus on past retrospective action items and do other valuable things. While plan changed of course, reflecting changing reality leading team inspecting and adapting accordingly and team moved descent point according to the joint decision.
But there is still difference…
While airplane landing is an example of waterfall project with QA (hardening) phase in the end (landing), it’s still differs from Agile. The more you do Agile right the more your team is mature, your product is safe, having more quality in and things are more automated. The more you apply engineering practices and earlier you start integrating and testing things (continuously), the later you can start “landing” and the more passengers you’re capable to take (stories) and the shorter your “flight” will be (you will “Deliver Faster”).
Many Agile coaches have their own list of top failure modes. My favorite one is Mike Cohn’s: “How To Fail With Agile: Twenty Tips to Help You Avoid Success“.
But I also want to publish my winning list of things that impact teams and undermine their trust in business and Agile (combined from experience gained observing different teams at different times, so no particular team is meant here 🙂 ).
So tips are written from the Product Owner perspective:
1. Argue in front of team at Sprint Planning. Let them see you were not capable to decide what you want to build them. Moreover, involve them into arguing. This will demonstrate how your (PO) team misses integrity;
2. Demonstrate that being on time does not matter: interrupt meetings with calls, side talks and questions. Leave the room occasionally and be late regularly. Doing this will make it almost impossible to demand on-time delivery from the team;
3. Continuously fail to deliver INVEST stories and integrity in sprint goal/product backlog. Let stories w/o details thought through, so that team feels you had not invest enough time to prepare them. This will also make it easier for team to fail delivering outcome of that stories to you, will make things more ambiguous, so that no one will understand where is failure or what was wrong and will never learn from it, so that improvement will not be feasible;
4. Ignore team signals on complex stories (the ones that are above ~13 story-points, the ones that are risky, big, and usually need to be analyzed and split into smaller chunks in advance). Just let big stories that have big doubts, leading to easier underestimations, over-commitments, sprint failures, causing less team confidence, further under-commitments and wastes of all kinds;
5. Present deadlines ignoring reality “I do not care how you do it, it MUST be done”. With this “masculine” management style you can always push things forward as Agile teams just delivery chain, so they must obey and no matter what they think and capable of;
6. Never share the Product Vision and mid-long term roadmap with the team (just keep it secret);
7. Ignore technical debt (just concentrate on #5);
8. Bombard team with in-sprint questions and “Can you do it now please?” tasks. Explain them that SCRUM is good but now we need to be more “FLEXIBLE”. Moreover, assign tasks to team members without talking to entire team. Demonstrate that you were not been able to plan things for an iteration, this will ruin team trust that they are working on most valuable things and completely undermine their ability to deliver;
9. Never groom your backlog just leave it to the sprint planning meeting when it is already too late. This will lead to long and stressful discussions as you will have to do it mid-planning,will drain team energy, lead further to fatigue, wrong estimations, poor planning and sprint failure;
10. Always try to find something that team did wrong to pin point and focus on blaming. This is proper way to avoid Kaizen and let team protect themself by “storytelling”;
Scrum is based on “Empower the Team” Lean principle that prescribes self-organization. This means that regardless of age and experience team members are equal and serve as managers to one another. There is strong rationale behind: people that do the work are the best to manage it as they own responsibility of results and know best how to handle it.
Daily stand-up or daily SCRUM is a team tool to reflect on changing reality and adapt accordingly.
I’d like to point out some cases when self-organization does not work as should and help those teams out to boost their productivity.
Let us discover some sick stand-up/self-organization symptoms first…
1. Refraining from exposing problems (ignorance of reality):
- Task takes longer than planned and reasons are not clear to everyone (or something holds back people from raising problems);
- Task is blocked and impediment is not exposed/raised (this also may indicate some other problem with task that is not comfortable to raise);
- It’s just a way it is (yes we all know that we’ve planned 4 hours for that task, but as usual it takes us 2,3,5,… times longer or this guy always messes things up, we can do nothing, etc…);
- Team does not reflect during a day on changing reality (just in stand-ups), leading to impediments piling up and being addressed late, so that they mask something else;
2. Intolerance to critical feedback:
- Team member pushes back heavily when someone tries to rise a problem related to his/her task;
- Raising problems considered as de-motivating and team silently prefer to hide them until it’s too late;
- Team members prefer to stay “nice” to each other rather than constructively criticize their plan in order to adapt it daily;
Those two are inter-related. As a team member one will hold back from giving critical feedback if receives push back from his/her peer leading to confrontation and poor->no self-organization…
Scrum Masters, look around. Don’t you observe those symptoms during your stand-ups and/or during daily work?
If yes then…
Try out following cures ….
- Talk to push-backers one on one, try to understand what makes them do so? It could be personal issues with team members, lack of positive feedback or self-esteem, or other personal or inter-personal problem(s). It also could be absence of trust (readiness to look vulnerable to the team).
- Explain that feedback is not oriented towards person, rather towards team (exposes problem) as there are no personal problems in a team, since problem causes wastes, further slowness, incompleteness and later sprint failure of entire team.
- Focus person on constructiveness rather de-structiveness when exposing problem and coach on asking why 5 times, usually it helps to come up with adequate counter measures to remove root cause of the problem;
- Educate other team members that raising questions is crucial and needed, but highlight issues and offer them to try out different ways to do so (there may be personal barriers for push-backers, so more “gentle” way may be less stressful while lead to the same result, e.g. instead of asking “Why you did not finish this task so far”?, try “What holds you back from completing this task”?
- Cultivate more solution oriented then problem stating approach (as solution is vector, while problem is scalar);
- Talk to entire team that problems are normal and ignoring them just postpones failure. So they require courage to face and team spirit to overcome, that makes difference between team and group of people. Exposing problem does not mean it shall become energy-drainer and de-motivator, rather it’s in-time red flag that shall re-focus team on next right thing to do;
- If conflict is unavoidable and your peers do not go with “exposing problems approach”, steer it, but not let pile it up (nice article on conflict avoidance here);
- Launch team storming to “shorten the distance” between team members, so that exposing problems is more constructive and easy (see: “Teamleads, “Storming”, Self-organization and Entropy”)
- Propose and drive team branding activity to help them find out shared values and motivators (see: “Team DNA: how to Brand up your team”);
To summarize, work both ways with ones who raise (also including you if you are in SM role) and with ones who push back to make raising problems comfortable and easy.
“Problems cannot be solved by the same level of thinking that created them.” Albert Einstein.
I was about to write another one in the scope of “Getting them…” targeted for Product Owners (PO), however thought that before getting them (stories) out of the sprints it is crucial for sprint success how to get them (team members) on it right…
So story going to be about how PO influences team focus and instills feeling of urgency and what happens if he/she’s not…
To understand this we would need to get back to Sprint Planning meeting (SPM). When PO makes final accords, accepts team commitment and sends team out to the sprint it is very important for everyone to stay focused on the Goals PO presented.
If PO jumps in mid-sprint, having unplanned acceptance criteria, special circumstances, etc… this sends a message: goal is void, direction is being changed, things that had been agreed at SPM are not valid anymore.
Scrum is tense way of delivering software. Constructive tension comes from high commitment and builds up high velocity (aka deliver fast lean principle) that is impossible to achieve without addressing limited and fixed number of issues within timebox.
Let’s understand how this works…
Higher velocity is achieved by staying focused on what is most important. As soon as this vector changes, something that had been important yesterday, becomes less important today, or something else emerges focus drifts away.
But velocity is not single thing this impacts…
More drastic effect this has on team morale, since besides team has to conduct context-switch (that has it’s own impact: see another related post here), but also it throws team into “Less” vicious circle that is:
- Less focus that eats up energy and leads to …
- Less energy that impacts productivity and leads to …
- Less commitment that impacts desire to work and leads to…
- Less motivation that drain attention and lead to …
- Less focus …
- Etc …
Understanding this will help PO to plan sprints in the way to avoid de-focus, protect sprints from interference (and team members from de-focus) and minimize impact of unplanned issues.
Of course fire-fights happen, of course they are important, but it makes sense to dive in root causes and build real quality in rather than fight consequences… and eventually turn circle back into “More..” :).