Scrum your Improvements back within 4 Sprints

“Make everything as simple as possible, but not simpler.” 
          – Albert Einstein

I am going to tell you a story of continuous improvement and how we have enabled those recently in our team of teams… I have picked this story up because situation at many companies is often quite similar:

The Problem:

Although many of them understand need for continuous improvement it gets hard to plan those together with features… and in practice implementations are often missing or poor:

• There is an increasing demand to deliver..
• Development teams are treated as “feature factories”,
• And no time to improve, no time to “sharpen tools” to be more efficient
• More pressure… risking improvements

And all this creates: feeling we are stuck, frustration, demotivates, affects efficiency and quality in longer run… and gets more complicated in multi-team environments… as it also includes agreements and collaboration factors between several teams…

We have tried many things and eventually were inspired by Jeff Sutherland’s Cycle of Scrum Master from Scrum@Scale …and here is what we have done …

But let us understand circumstances first… and how does process look from a single team perspective:

• Development team plans and runs their 2 week sprint…
• That ends up with DONE product increment
• And a delivery of it together with other 5 teams
• These 6 teams are sharing codebase, decisions, tooling and environments together + they deliver in the same cadence
• They talk regularly as Team-of-Teams to Inspect & Adapt their delivery process aka Team of Teams Retrospectives
• In the past they were trying to implement findings of those retrospectives, immedeattely but only few were really managed…

Sprint 1: so this made us thought how we can Scrum those improvements back in sprints…..

• We have obtained an agreement with Product Owner team to let each team pull at least 1 SMALL Task from that backlog per team / sprint and that this task shall be prioritized as a part of the default sprint goal 
• We have also agreed within teams to file their improvements as tasks marked accordingly that comprise so called Kaizen Backlog

We have put these decisions into actions and felt results almost after a sprint…

Sprint 2: why we must wait to come up with improvements?… 

• Apart from those any team at any moment can propose an improvement and for that thy can use SoS to share their ideas with peer teams
• Those ideas after acknowledged by other teams are also parked in the same backlog

Sprint 3:  how to make sure Task is READY? Development of that lead to…

• Distribution of tasks happens latest 1^st Scrum-of-Scrum of the sprint for the sprint after current. This we have done for creating enough pace for the teams to refine / groom those and size them so that they are SMALL.

Sprint 4: after a while we have noticed that it would be good to prioritize that backlog…

• Besides regular intervals ToT also joins forces in validating this backlog, checking prioritization, etc. This we call “Kaizen Triage Meeting”. After a while we have looked together at this backlog and understood that we have there 4 types of improvements:

1. • ProdQuality – Quality of Production (Live Product) is ensured, i.e.Monitoring, Logs, Live Tests
   • DevQuality – Quality of Development (or soon to be released) is ensured…
   • Efficiency – Saving Time for Development, …
   • ProdPerformance – Performance of the product for end users

On top: We have also thought about some symbolic celebration …

• After team implements an improvement task, they get a STAR
• Default expectation 1 star per team per sprint, but in practice some try and did more…
• After each sprint we acknowledge how many STARS we have produced all together!

Results are:

• Many small practical improvements fast
• Feeling of continuously “steering” our technology
• Increased motivation and feeling of ownership in teams
• Was measured by tickets inflow / outflow + happiness

This worked because:

• improvements were small, easier to plan, implement and deploy them
• therefore, they are also less risky to do
• process is simple lightweight, easy to follow
• shorter improvement cycle allows faster response
• queue of the backlog is short and manageable

 

 

 

 

 

Emergent Improvements over managed changes

Changes towards better is what most of organization are seeking for.

We often hear that Scrum Masters and Agile Coaches are referred as “change agents”. It is important to understand it is much more challenging and required for those “shoes” to master change management than e.g. change managed by supervisor.

I like word “Improvement” more, however…. Maybe this post helps to explain why…

There is difference in the way change is accepted by teams in case it is:

• Originated / introduced by management – these changes are often seen as “enforced” rather than owned. When communicated fully, transparently and explained these changes are followed / implemented usually
• Emerged from self-organizing teams – these are changes that are owned by teams. Therefore, level of involvement, contribution and ownership to the success is much higher.

So, what are the magic ingredients to make improvement happen? And what is required for it to have positive effect?

Set the Goal

In terms of Agile this means understanding the lack of fit of something. This is essential. Without exploring lack and creating shared understanding and contribution towards Goal nothing will happen.

After exploring the lack convert problem into goal. Keep in mind this is pivotal point as goals usually seen as something positive (unlike problems).

Clarity about goal is essential. When this is unclear people best case not “buying in” and worst case confronting change or acting ”passive-aggressive”.
Key question here is: and what do we want to achieve instead?

Communicate

This is very delicate one. Language and transparency is very important. Humans do not like changes. Do not communicate problems or that “we are changing”, communicate goals or that “we are improving X” instead. You will be facing much more resistance otherwise.

Reason is problem sends out “we are bad” and creates frustration, while goal sends out “we are improving gradually” and creates motivation.

Example: there are people that do not like to “play according to the rules”. Proven by practice that you will face huge resistance from those “Mavericks” if you will name your change, let’s say “switching to Scrum” because this could be interpreted as “what you had here is bad”, vs. “Improve the way we work” with post-factum acknowledging that aha, btw it looks pretty much like Scrum.

At the same time communication is important as when changes are implemented subtly you will face much more resistance, resulting from lack of transparency and comfort leading to many false assumptions.

Experiment

No changes are done forever. We do series of experiments to see what works, what works better… We inspect and Adapt and practice constantly. It is important to cultivate mindset of constant experimenting and improvement. Then change will not be something negative, rather permanent positive state (Kaizen).

Constant experimentation also requires measurement and validation. This is another important aspect that is sometimes neglected.

Ally

Get opinion of people that will stand with you when improvement is being implemented. Present it in terms of their benefit. Get them on your side.

At the same time, you will unavoidably face some resistance. It usually comes from the fact that some team members either afraid of change (they think to “loose” something or end up with less comfort, etc.…). You need to manage this resistance.

According to studies resistance is consequence of brain that protects us against dangers and tries to maximize our satisfaction (Minimize Danger and Maximize Reward). One should therefore take this into consideration to manage these basic social needs (known as SCARF model

Involve

This is fundamental. Not just rely on ally, … Involve. People embrace changes much easier when they contributed towards ideas, participated, asked for opinions and feel part of. Easiest way to convert potential opponents into allies is to involve them into getting it done.

But most important is that involvement creates empowerment that not only reduces resistance but raises awareness, creates feeling of a team, improves collaboration and as result amplifies possible success of the change.

Act small

Change requires energy, think of it as of a ladder that needs to be “climbed”. No one likes changing for changing. “Prize” must be bigger than “price” to pay for “climbing up”. Therefore, it is more likely you will succeed with smaller and singular changes at a time.

Start with small/local experiments. This way you will be able to prove your theories better and get more motivation for scaling up.

And scope changes the way teams are capable to achieve. In other words, meet people and teams where they are, not where you want them to be. Take into account things such as: business constraints, people capabilities, current situation, motivation of people, etc..

Think of short-term wins, those are indispensable to “feed” motivation for changing further…

I have summarized all above in Agile-like Lean Improvement Manifesto:

Lean Improvement Manifesto:

• Emergent Improvement over change as a goal
• Small Creative Experiments over “big bang” theories
• Getting Involved Early over following change late
• Empowered Co-Ideation over top-down pushed decision

References

• David Rock, SCARF Model – Influencing Others with Dr David Rock, 8. Aug 2010.
  see: http://www.youtube.com/watch?v=isiSOeMVJQk (8 min:16 sec)
• David Rock, Your Brain at Work: Strategies for Overcoming Distraction, Regaining Focus, and Working Smarter All Day Long, HarperBusiness, Okt 2009.

Scaledance of Team Healthcheck

To keep the body in good health is a duty,
otherwise we shall not be able to keep our mind strong and clear.
–Buddha

Every self-organized team requires periodic “healthchecks”. With this idea I have started to surf web in search of the best tooling that could help me with the agenda for my team’s Teambuilding retrospective….

 

At the same time team was “storming” and needed help to get into Solution-centric thinking …

My search resulted in making mix of two techniques and I would like to offer ready retrospective script to Scrum Masters. So, “retrospective-cocktail” I am coming up with here “mixes” “Team Barometer” & “Scaledance of an Aspect” techniques serving team to imprive key aspects of Teamwork.

Team Barometer

This is survey-workshop format excerscize adressing 16 team characteristics, packaged as a deck of cards. Download the cards, print them, and cut them out. You want one deck for each participant. Click here to download the cards.

You also need voting cards. Original script reccomends one green, one yellow and one red card but I have used 3,2,1 and 0 planning poker cards (yes, I’ve intentionally modified and introduced the 4th state not to result into “let us take golden middle everywhere”).

Each card has a headline naming a characteristic of a team, and a green and a red statement. Excerscize is to read them out loud one by one, give people a couple of seconds to think and ask them to “poker” this aspect, collecting sum of all votes and NOT discussing estimates like in classical planning poker. Attached you can find list of aspects with an example estimates Team_Healthcheck_Aspects

Scaledance of an Aspect Approach

Idea is as simple as 0-to-10 scale with 10 representing the desired goal and 0 representing its opposite. It provides three focal states for the conversation:

1. NOW: Where we are now? (value=N, current state) – an account of all that is currently contributing to that future, including past successes
2. GOAL: Where we want to be in the end? (value=10) – description of a best possible future
3. STEP: Where we would like to move to? (value = N + 1) – exploration of possible progress in the immediate future

Example:

Powerful questions and methaphors for those 3 states are:

NOW (methaphor: let us look back):

• Where do we stand at this moment?
• What works already so that you are already at N rather than lower?
• And how it is now?
• What is happening now?
• How did we manage to be at N?
• What was our contribution?

GOAL (methaphor: let us look back from the future position):

• What will be different, when we reached 10?
• How will others notice that we reached it?
• Suppose we reachedit, what will we do differently?
• How does the “bright” future looks now?

STEP (methaphor: imagine we are already at N+1):

• On this scale, where do we want to be, for example, in 1 month?
• Imagine we are at N+1 now. What is different?
• And what else our collegues, management, etc. might notice?
• ….

Key here to first talk about states (and not immedeately jump to actions). In Scaledance exscerscize states seen as “goal setting” tool.

Retrospective Script

1. Introduction & Agenda – 5 min
2. Checkin / Warmup – 5 min
3. Healthcheck: aspects estimation – 15 min
   • Write aspects on the board / wiki/confluence page and record sum of estimates
   • Make sure you do not record individual estimates, rather how many 3,2,1 and 0s we have
   • Make sure you do NOT ask “whys?” to the estimates
   • All that counts is the sum of estimates of all team members
4. Healthcheck: prioritisation – 5 min
   • Here you can ask each team member to come up with the “backlog” of their desired top 3-5 aspects they would think team would benefit most discussing
   • Then you can ask team to collaboratevly produce joint backlog of top 3-5 aspects
   • This is important step as lowest estimate of an aspect does not mean this is the most important one, some of them are in realtion to one another and this relation totally unique for each team, so only team members can choose what would they benefit from the best.
     
5. Scaledance of an aspect – 30 min per topic
   • Running Scaledance for desired aspect: Now, Step
   • As aspect – card already represents 0-state and 10-Goal-state you do not have to specify them
   • Ask team to Describe NOW, e.g. by giving them 3 minutes for producing sticky notes
   • Brainstorm together to define how N+1 looks like
   • Derive Actions to make N+1 happen
     
6. Proceed with the next Aspect
7. Closure & Feedback – 5 min

Resources / Techniques / Copyrights / Thanks:

• Crisp’s Blog: Team barometer (self-evaluation tool)
• sinnvollFÜHREN: Leading Solution-Focused Retrospectives

8 Key Aspects of Scrum Master Role

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.
Bruce Lee

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….

Facilitator

• 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

Team Builder

• 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

Team Guardian

• 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.…)

Reflector

• 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 🙂

6 Team Building Retrospectives for steel-strong teams

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

this earlier).

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):

1. Cool guy, team member of my dream 🙂
2. 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):

1. How do I feel myself in the team?
2. How I would like to change it?
3. How I would like that person X changes certain behavior (how do I feel)?
4. If X changes that what do I offer in return?
5. 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:

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:

Part 2:

• Because of what you have just said, it appears to me that you are someone who is / has / can….
• 1.
• 2.

Then again ask to share findings with pair and think together to answer part 3:

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

member.

Brainwriting exercise: My communication style (underline what is more relevant to you)

1. Do I prefer read or listen?
2. Am I fan of short statements or do I prefer long reports?
3. Do I want long meetings every month or prefer short meetings more often?
4. Do I like to know entire story, every single bit, or do I want to know just the headline (big picture)?
5. 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

1. Does my colleague prefer read or listen?
2. Is she/he I fan of short statements or prefers long reports?
3. Does he/she want long meetings every month or prefers short meetings more often?
4. Does she/he like to know entire story, every single bit, or wants to know just the headline (big picture)?
5. Is it sufficient someone says something to me once or do I have to be reminded several times until I notice?
6. 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)

See also:

• Teamleads, “Storming”, Self-organization and Entropy
• Team DNA: how to Brand up your team
• TEAM: 7 indispensable ingredients for “Together Everyone Accomplishes More”

Scrum Master Dojo

“Knowing others is intelligence; knowing yourself is true wisdom.
Mastering others is strength; mastering yourself is true power
Lao-Tzu

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 …

Master Neutrality

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!

Master “Storming”

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.

Master Yourself

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.

Master Clarify

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

Master Conflicts

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”.

Master Agreements

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:

1. They may be not compatible
2. 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!

Master Presence

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

Master Positivity

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!

Inducting Quality In with Quality Retrospectives

As in Mathematics, so in Natural Philosophy, the Investigation of difficult Things by the Method of Analysis, ought ever to precede the Method of Composition. This Analysis consists in making Experiments and Observations, and in drawing general Conclusions from them by Induction, and admitting of no Objections against the Conclusions, but such as are taken from Experiments, or other certain Truths.
For Hypotheses are not to be regarded in experimental Philosophy.
— Sir Isaac Newton

Quality is by far the most crucial aspect of software development.

I would like to bring  life tested approach of retrospective practice focused on Quality – ceremony to focus on elimination of defects by understanding core issues and addressing required preventive actions, leading to less time spent on fixing those and gaining more time spent building features. Let us call them bugs (negative features that make software functioning not as expected).

As any Retrospective…

it has it’s 5 steps and here is how those are mapped to practical actions:

• Set the stage – focus on reviewing bugs resolved during period (e.g. past iteration);
• Gather data – prepare in advance extract of bugs;
• Generate insights – gathered during retrospective as soon as team passes bugs one by one;
• Decide what to do – preventive action agreed and written, having assignee (es);
• Close – short summary of the reviewed bugs;

What helps to make it efficient:

• Agreement on scope: what bugs are to be reviewed (production, staging, development, what severities, etc…)?
• Right people in: depending on scope and nature you may need to have not only development team members but also release coordinating operations engineers, product managers, etc.;
• In multi-team environment you may need to involve only some team members of every participant team, given who had participated and/or who is best addressing, lead engineers, etc.;
• Prepare in advance (e.g. take iteration, release, etc.. extract of all bug resolved, pre-sorted/pre-groupped by severity, …);
• Have mandatory field when resolving bug with your bug-tracker (e.g. Jira) that must contain technical reason for the bug + projected preventive action to be reviewed further by retrospective. Having this is very valuable as decreases time spent on “gather data” and provides more “space” for “generate insights”;
• Keep it short:  60 minutes is usually enough/sufficient if everything is properly prepared in advance and practice is regular;

Inductive approach (during retrospective):

As team is passing from most to less severe production bugs, they review each and make sure technical reasons are understood and proper preventive action(s) agreed. Then team decides who will own the preventive actions (given team setup this may be teams or individuals). In obvious cases like: bug was not detected by automated and/or unit tests when it should have been, bug is simply stays opened until action is in place (as it is best practice to have those as bug “definition of fixed”).

As soon as bug is discussed team analyses possible patterns for the reasons of the bug by writing down short summary of the bug’s origin.

And moves on with the next bug, etc…

Since approach is inductive: moving from the specific to the general here interesting findings emerge from reality and most “aha-s” and bigger problems become visible.

Here are real-life examples of bugs “patterns”:

• “release misconfigs”
• “old legacy codes”
• “hardware issues”
• “story misunderstandings”
• “quick = dirty fixes”
• “3rd party misconfigs”
• “localization issues”
• etc…

Of course it is good to prevent same bugs popping up again by addressing required preventive action(s) but is not just enough if you want to address the core issue.

The inductive approach here will allow team to focus on systematic problems and start effectively eliminating bugs by coming from particular life-cases, reality (reasons) to more “patternized” reasons and risks of having future bugs of the same nature/origin.

As an example Quality Retrospective may have also outcomes / actions like those:

• 3 compatibility issues / define list of supported browsers (+agree not to support the others, thus do not file bugs;
• 3 old legacy code issues / address with your architect (team), consider reworking;
• 3 misunderstandings / address with your product team how those occurred and refine story writing, grooming to avoid/reduce possible misunderstandings in the future.
• 2 design issues / agree to address design issues incrementally (stop demanding their fixes as bugs, …);
• 2 release miscofigurations / review release notes collection and approval mechanisms, reduce human factor;
• 2 translation issues / address with your product team how those shall be handled;
• etc…

Team may decide to address them from having biggest impact or from more severe issues or more systematic, but at this level they will be fixing the root cause rather than just a symptom (particular bug).

Advice to facilitators: manage time in the way to avoid burning all of it reviewing all bugs (you may not be able and/or it may be not even needed), rather focus on most important ones + detect “patterns” as early as you can.

How to address preventive actions and follow up

As in any retrospective, I’ve seen two approaches working here depending on the efforts:

• in next sprint task approach – action owner plans a task (or time, depending on action nature) in the next sprint. Usually works when effort is quite small;
• “top story” approach – for “bigger actions” plan a story of top priority in the subsequent sprint;

Consequently follow up is done either at the sprint review or on the next retrospective.

Some “Side findings”:

• You will figure out that some bugs are not actually mistakes as from the coding perspective rather than “logical gaps” in user flows;
• Some bugs are unavoidable and you may not need to prevent them (e.g. the risk of having them is acceptable from business perspective or preventive actions are too expensive compared to the consequences, …);
• Some “Invalids”, “Cannot reproduces”, “Duplicates”, “Won’t fix-es” and “Works for me-s” causing development team distraction and eating up time – at some extent this is still unavoidable but keep an eye on if you have increasing numbers of those;
• Some do not fit into any pattern (just exceptions);

Good luck inducting quality in 🙂

What goes up must come down: Sprint “Descent” Point

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”).

Daily stand-ups: second scenario of effective alignment

I’d like to share the way I used to run daily stand-ups. Depending on the case I use two models.

Team members attending mode

Usual team stand-up to align on daily progress. Yesterday-today-impediments questions applied to each team member.

But there is a second scenario that also works …

Work Items attending mode

When this is useful: imagine more than one Agile team is working on the same product/running same sprint and need to be aligned.

For this particular case I apply model to serve as peer management tool (for Scrum of Scrums aka SoS) with work items “attending”, where the yesterday-today-impediments questions is still used but will be from the perspective of the work item, rather than the person.

To run this one efficiently here is what I do:

• I prepare list of aspects of product, teams have to address in common (e.g. regression bugs, functional tests, integration tests, unit tests, non-functional requirements and anything else teams consider as important);
• I list them on the whiteboard beforehand (we have pre-agreed order of addressing those);
• I invite max 2 team members per team to SoS to avoid long talks (one is also an option, however I’ve found 2 is optimal since in case particular team would need to make an on-going decision, another peer will help). Those guys are to talk for a team and report back to their teams whatever decisions were made, statuses changed, etc. in SoS;
• Then I go through the list during SoS one by one (as if not teams attending, but “topics” and ask if each team has to align their peers on specific topic or has any related questions clarifying in which state topic is in presently);
• I ask to share stories states not by default, but only in case there are questions or things that affect peer team(s) or causing dependency;
• Then I ask if teams has anything else to discuss (and if that is technical, leave them alone);
• Last but not least I ask if they have any impediments or may/are causing impediments to other team(s);
• And of course I time-box to 15 minutes as max;

Agile is verge of productive conflict: controlling gap between demand and offer

Before everything else, getting ready is the secret of success.
Henry Ford.

Many of us doing Agile do not understand that it is primarily business mindset, rather than just another methodology to deliver software. Balance and sustainability of constructive conflict (key driver of any prosperous business) is the secret sauce to implement Agile successfully.
Let me explain it from practical business perspective. I will drift away from IT and software now…

Imagine you’re running business delivering…. car repair services to your customers.

It is your interest to deliver services fast and having quality in, so that you retain your customers and attract more (as it’s known that satisfied customer may bring 1 or 2 others, while dissatisfied one may stop other 8 coming to you). On one hand the more services you deliver, the more money you get, so you will push for more. But if you start pushing harder than your team is capable of, your service quality will start to suffer and this will obviously cause problems with your customers.

So you will try to get as much as possible given your conditions, while keeping quality in.

Now let us look at it from your customers perspective…

They want to have their car repaired cheap, fast with quality in. When you say your’re busy this week and cannot take their car, they will consider someone else’s services, rather then agree waiting that log (reality of market competition);

So, there is conflict of interests and mismatch between demand and offer.

It drives 2 things:

• Your business development (we need to improve our service to deliver faster/more/cheaper);
• Your customer’s expectations (maybe these repairs are not doable that fast/that much/that cheap);

Two consequences out of that:

• When there is no demand, why should you care to do more/faster/cheaper?
• When there is no chance to change your customers expectations either you’re doing poor job or your customer won’t likely get any better services with reasonable price anywhere else (task for your client managers to drive customer’s expectations).

So mismatch of those two creates conflict of interests that drives change.

The art is to understand to what extent you’re capable to improve things at your business given your current circumstances, while managing your customers expectations in the way to have control over gap between your offer and your customer’s demand.

Controlling this implies another important thing: ability to recognize challenge that you will fail taking (you should constructively resist) and challenge you’re able to overcome (and should take) to improve and continue managing “the gap”.

If you do not understand this you will end up bad. Either you will not be able to deliver quality in to your customers or you will be “beaten” by your competitors. In both cases you will end up being out of business :(.

Now let’s come back from cars to software and Agile

Customer is Product Owner (PO), while your business is your development team. The more you think business-wise and consider your team a business the better your team will be satisfying your PO.

So it is as easy as managing just 2 things:

• Your PO’s expectations;
• You development (quality and predictability);

Agile is just business common-sense mindset, nothing else! So to implement it right start from considering that you run a business in a highly competitive market with goal to satisfy your customer.

And mind that there is difference between pleasing and satisfying your customer, so argue, stand for your point, do not let compromise quality, do never over-commit, protect your ability to deliver, manage expectations, and … satisfy. If you do not follow these simple business rules and will focus on just pleasing your customer (or PO) just as in business you will end up not being able to manage what you’re responsible for – QUALITY.

Good Luck 🙂