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..” :).
“If you can not measure it, you can not improve it.” Lord Kelvin
I’d like to continue with “Getting them…” topic (see previous post “Getting them READY: user story life cycle and “Epic Box” principle“). Today we’ll be getting them (stories) through Sprint Planning Meeting (SPM)…
Assuming all stories are INVEST and backlog is prioritized according to value, return-on-investment, risk, etc..
Then it comes to sprint Planning Meeting (SPM) itself…
Here are steps that will help you to get stories through:
1. Be prepared
As Product Owner (PO) you should be quick with decisions as some estimates may be quite “surprising”. I recommend have “plan B” on every story in mind (see Negotiable from INVEST of previous post) as pre-decision what acceptance criteria (AC) it is possible to live without or separate and your idea of estimation prepared.
2. Present it. Sell it!
Start with presenting the goal of the sprint, follow up with idea behind the story and the problem it solves. Do it in the way to get team buy in. Of course it is your responsibility to decide what is important and what is not, but knowing WHY this is important is vital for correct story implementation and has positive effect on team’s feeling of urgency. Be ready for questions and address them with patience.
3. Applicably question
You should be ready to question estimates if they go beyond your expectation. This is important as empowers “constructive conflict” between parties (team and PO). But please keep in mind that you should be very careful doing this as it should not look like putting a pressure on team.
For instance, instead of asking “Why this is 13 (20, 40, …) story points?” that implies hidden context and will most likely lead to a defensive and broad technical answer you will not benefit from, ask “What makes it 13 for you?” or “How I could split this story so it takes less?” or “What AC make it like that?”, etc.., which is more direct question and assumes no hidden context. Most likely you will be provided with non-technical answer and will be able to judge on “expensive” functionality.
3. “Decode” estimates and implement PO Kaizen
Estimation process is valuable feedback to PO on stories quality and granularity and it makes sense to use it right. Why? Because as PO you will learn to improve your stories and size them the way it will lead to fast, stress-free sprint planning meeting as prerequisite for successful sprint.
How to “decode” team estimates
Here is my hint: as you know user story point is relative measure of work, but to me estimates have also different meaning that “signals”, I suggest to be interpreted by PO as follows (assuming that same team estimates continuously using same baseline):
- 0 USP (orange) – you may have no idea about your product, this functionality is in place;
- 1/2, 1 USP (yellow) – small (usually cosmetic) improvement. It is OK to group several such improvements in a single story if they contribute to the same WHY clause of story description;
- 2-3 USP (light green and green)– small to medium size functionality. All is well 🙂
- 5 USP (green) – medium size functionality. All is well 🙂
- 8 USP (dark green) – big size functionality, any way to make it easier or split into smaller? But all is well still:)
- 13 USP (orange) – do you understand WHY this cannot be smaller/indivisible?
- 20 USP (dark orange) – you should have very STRONG reason of having such a story. Make it smaller and simplify;
- 40 USP (red) – no way this will be done during a sprint. Understand what makes it that big and split;
- 100 USP (dark red) – damn big amount of work/ambiguous acceptance criteria/big doubts, serious problems, etc;
When turning those signals into color scheme planning poker logically turn into sequence, reflecting “estimate temperature”:
4. Track time
Besides, I recommend to track time spent per user story discussion (use hourglass or timer, or ask your scrum master to facilitate). My observation of sprint planning over 2 years proved that team usually able to estimate ~10 user stories per hour as average (3 teams of ~ 15 people in total). Of course it depends on the size of team and many other factors, but to me if a story takes more than 10 minutes to discuss, PO shall do something with it (question what causes doubts, remove story from planning completely or partially).
5. Ask for feedback
Asking for short feedback at the end of sprint planning also helps to improve. It’s good idea to hand over paper with INVEST acronym reminder where team members place comments on stories and quickly feedback to PO in the last 5 minutes of SPM, referring to particular quality of INVEST and particular story that had not meet this requirement. This is timeboxed to 5 minutes and helps to improve quality of SPMs a lot.
To be continued…
Knowing what drives yourself and your peers is an esssential key to manage self and people around you. Being it work or private life.
There are many different classifications of what keeps one motivated. I would like to share simple one I apply and found it practically useful to understand what can keep myself and my colleagues motivated (or de-motivated)…
It is based on 5 simple types of motivators – key motives (or incentives) that influence our behavior:
1. Achievement: I will achieve that (to prove myself that I can do it), to feel better. Get it DONE is important for me! Capitalization by investing into the self is usually a real driver for this type of motivator. A burning desire to achieve certain goal has some purpose (to get better, stronger, experienced, more professional, etc…) and constant challenge that keeps me “running”. If such a person lacks challenge or does not sees the “horizon” of self growth he/she starts feeling de-motivated.
2. Social: will do it to earn respect and praise of my colleagues (spouse, friend, etc..). People, having social motivator as a key one care for others opinion more and work towards shaping them to comply to their expectations. If socially driven person doesn’t get praise (or worse gets blame instead) for a while he/she starts get de-motivated.
3. Reward: I will do it to get a reward. The ‘carrot’ thing that can be money but also career growth, benefits, etc… This motivator is easiest to claim, while weakest to retain. Some roles do require reward motivator (e.g. salesguys), but beware of people that have only this motivator as a key one.
4. Process: I like it.I like to do my painting, knitting, etc.., primarily not for getting it done but for the process itself. I enjoy making changes and pace, creativity, investigations, etc. Key root of this type of motivation is freedom to act in the scope of desired and beloved type of activity. As soon as you put a pressure on such a person he/she gets de-motivated.
5. Idea: I believe in that. Strongest one (and only one that actually can be grown up). People do revolutions driven by idea. Those guys stay if company values match with their own value stream. They care less about other motivators if this is the case. If views of such a person do not match with employer/bosses he/she becomes de-motivated and eventually leaves the company.
There are no right or wrong, good/bad motivators. All that makes difference that different types of activities/roles at your company require different qualities (you know the best), that one needs to recognize and consider when staffing.
Here’re some examples of types of motivators that usually (but not necessarily) suit better different positions/roles:
- Sales guy: usually driven by Achievement + Reward motivators;
- Account manager: usually driven by Achievement + Process motivator;
- Programmer: usually driven by Process+ Achievement motivator;
- HR manager: usually driven by Social + Idea motivator;
- CEO: usually driven by Idea + Achievement motivator;
Usually each of us have 1-2 motivators as a key ones. The trick is how to recognize and motivate using that information (should have another post on this).
To be continued…
Thanks to Vlad Zavadsky (an inventor of the approach and business trainer at Runa Consulting group).
I would like to start with describing what cycle user story goes through before it becomes READY for sprint planning meeting and how PO handles this cycle.
For sure there are many best practices to get stories READY and write proper stories. Instead of focusing on story-writing itself, here I will cover PO workflow to them ready.
So, here are my 5 cents…
Assumption: user stories are part of shaped big wish (called epic), that is part of Agile release/roadmap and takes place on “storymap” that had been presented to development team some time ago.
What does this means?
This would mean that:
- Value brought by an epic (and future user stories) is clear to everyone;
- Possible big “underwater” problems it may cause surfaced (reworks, performance, missing data, uncertainty, etc.);
- High level estimates are given to an epic;
- Big questions are addressed;
As next step PO prepares epic further, splits into particular stories, sizes each of them and “hones” acceptance criteria (aka satisfaction criteria). To proceed we need to know what does INVEST mean.
What is INVEST?
Things PO should keep in mind when doing story-writing and story-splitting is “INVEST” rule. It stands for:
- Immediately Actionable – so that team can start working on it immediately;
- Negotiable – so that can be quickly made smaller/bigger by removing/adding scope of acceptance criteria (AC);
- Valuable – so that everyone understands what value it brings to an end user;
- Estimable – so that it can be estimated with user story points or ideal hours;
- Sized to Fit In – so that estimates fit in established iteration length;
- Testable – so that has understandable and achievable acceptance criteria;
Splitting an epic
Then it comes to the split itself. I suggest doing the following way:
1. Have a pencil and paper talk with your PO peer(s) on the epic before splitting:
- define overall description (As a WHO I want WHAT so that WHY);
- agree on the way to reach WHAT (draft acceptance criteria, aka AC);
- write AC down. You will end up having many AC, e.g. 30 or more;
2. Request, get and provide stories with everything that makes them immediately actionable (e.g. designs, data, clarifications, everything that has to do with 3rd parties, etc.);
3. Define story split logic, so that they all can be worked on quite independently and placed in a sequence that satisfy following criteria:
- upper stories do not require functionality of lower stories (and lower stories do not impede implementation of upper stories);
- functionality is split logically, trying to keep stories ~same size (remember, best sizing of stories is 3-8 user story points);
- upper stories allow user to see maximum valued functionality first;
4. Define each story description and split overall AC accordingly. Keep in mind that at this point new stories will pop up (I call them “conjunction stories”). The rule is easy to understand.
Epic Box Principle: “As soon as you start emptying virtual box of epic functionality, removing and shaping story after story out of it, you will find out something that is still there and was not your initial plan”.
If your plan was to split epic into 4-5 stories, you may end up with 7-8 or so. That is one of the reasons that explains why usually epic level estimates are smaller than sum of estimates of all corresponding stories.
Important hint: do not hesitate to split as combining is way easier. Splitting is good exercise because enforces to think through value->solution again and discovers potentially hidden problems, functionality etc. Another effect of splitting bigger stories into smaller is reducing doubt (and therefore risks) team will have associated with big story. It turns afterwards into saving user-story-points…
Therefore, it’s way better to have detailed backlog rather then let team estimate their doubt wasting story points on your inability to think through solution and side functionality that may popup during implementation of bigger chunks.
Remember: as PO you are in charge of what team does next and need to have stories prepared accordingly.
5. Peer review all stories with your colleagues after you consider them as READY to see what is missing, question how each AC may be interpreted, best guess on possible estimation;
6. Re-do steps 2-5 until stories are INVEST and READY for sprint planning meeting (SPM);
To be continued … (“Getting them through sprint planning….”)
I would like to continue topic of Expert Sales. See previous post – “Expert sales: part I – assessment“.
It covered decision making model when launching expert sales. But how to get there? How to retrieve those answers from your client?
Let’s make first very first step – first talk or meeting with your customer. Dealing with front-line requests you never know who is calling you/who is at your door, so need to act prepared in order not to miss your chance.
Let me take an example…
Imagine you have your phone ringing and a nice female (or male, your choice) voice asks for your service. What would you do? What questions would you ask? What and how will you tell/offer? What would be your next steps? What impression will you make?
First of all: make sure person who is speaking with newly called customer is qualified enough to start assessment. If not, leave clear instructions how he/she should act and what to tell/not to tell if such a person is unavailable at the moment.
I usually leave clear instructions if call reaches receptionist and no one from sales guys is available:
- Register person’s name, position, contact phone, e-mail;
- Ask how he/she learned about us?
- Ask to describe what service he/she is looking for?
- Ask what company he/she represents?
- Agree for suitable callback time of sales person.
Be cautious and NEVER at this point:
- Give any estimations on time, budjet, etc (even if person insists);
- Start “selling” yourself or your services/pushing/advertising;
- Say NO (after a while you may establish clear rules when you allow your front-line guy to say NO to assess already at this step);
Benefit applying such an approach is that that your sales guy will have time to prepare and gather information before the call, that could be:
- Surf client’s webpage/Google about company, their services and business;
- Analyze initial request and perform first step assessment if possible;
- Prepare questions you would ask to assess further;
- Obtain information about possible competitors of potential client;
- Obtain information about person you prepare to call to;
- Call back when ready and as agreed;
And finally, remember: you never get a second chance to make a first impression!
And whoever plays in your front line he/she makes that impression.
To be continued…