Archive for category Kaizen

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:

are-you-too-busy-to-improve2

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:

Team of Teams KAIZEN Sketch

  • 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 1st 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:
    • 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

Screen Shot 2018-12-16 at 12.40.06

 

 

 

 

 

Leave a comment

Emergent Improvements over managed changes

KaiZen.png

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.

Leave a comment

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

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

Screen Shot 2018-03-15 at 22.40.27

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.
      Screen Shot 2018-03-15 at 22.50.05
  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
      Scaledance_of_an_Aspect.png
  6. Proceed with the next Aspect
  7. Closure & Feedback – 5 min

Resources / Techniques / Copyrights / Thanks:

Leave a comment

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

scrum_master_8_aspects

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 🙂

, , , , , , ,

Leave a comment

6 Team Building Retrospectives for steel-strong teams

Team BuildingI 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:

Leave a comment

10 Tips to undermine Agile team ability to deliver

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

, , , , , , ,

1 Comment

So willing to SUCCEED that not seeing FAILURE coming: the difference between urgency and panic

Defer Commitment + Deliver Fast!

Recently I observed an interesting trap one team fall into. When asked how confident guys feel about hitting the target, they was almost jointly saying they’re absolutely confident, however burndown chart  trend told me they won’t make it.

Well, I am absolutely sure that this is what we all want to have – 100% confidence, however here’s the dangerous trap.

We may stay satisfied and oversee problems (or pretend that tomorow the problems will be gone). Or try not to rise them. Or feel uncomfortable rising them. Or think that others will feel uncomfortable if we raise them, etc…

But, they will NOT disappear. Problems usually have tendency to pile up… And when such a team recognizes that, it’s already too late…. and painful.

Kaizen mindset and “Toyota way of Lean Leadership” cultivate culture of  “continuous crisis” that requires continuous improvement . Only having daily cultivated feeling of urgency and need, maintains the rhythm of tense and productive environment that reduces risk of facing a FAILURE.

As Toyota management team stated in 2010:

“We realized we need to develop a grater sense of urgency, in our business. Success is good, but without urgency serious weakness sets in, customer focus declines, creative ideas dry up and before you know it, you’re in trouble”.

So here is the trick to recognize: before you know it, you’re in trouble.

But the word and concept has negative tone and may have de-motivating impact on a team. How to make it distinct and positive?

Here is an advice…

Unlike panic or hysteria, urgency is a constructive, ordered and focused sense, therefore it should not de-motivate. Simply because it results in targeted and the only correct decision and action. Deffer commitment + deliver fast, guys!

To illustrate this imagine fighter aircraft pilot that needs to make the only correct decision and act accordingly within 10 seconds left before he may crash. And here is the difference that also proven by multiple real-life cases:

  • Panic: an ordinary pilot most likely starts to hit all buttons around (maximizes focus and work-in-progress) or worse, thinks about death (we will fail…), not believing that this happens to him (we will not fail, I do not see problem, it’s not about us/me…);
  • Urgency: trained pilot usually freezes for 7 seconds (analysis, defer commitment), makes decision, then within 3 remaining seconds quickly does (focused, fast) the only correct action to stabilize aircraft;

Feel the difference?

A takeaway is simple: stay open-eyed with reality, constantly challenge your confidence, do not fall into trap of satisfied optimism, distinguish among your will and reality, spread urgency around and stay hungry © for constant improvement.

, , ,

2 Comments