ERF - Expectations, Results, Feedback

The first badge for leading and sharing is awarded for successfully leading your team to achieve defined goals, and for maintaining transparency of team progress while sharing new experience and knowledge with peers and seniors

However the second badge for leading and sharing is more challenging and requires sharing to new colleagues how they can share-and-lead

Here is a proven good way to earn the second badge through ERF (set Expectations, review Results, provide Feedback):



When in doubt, just follow the three ERF steps:
  1) Set Expectations - clearly explain what is the final goal of the deliverable, why do we need it, what is the epic story behind it; provide a system description or example of similar work from before; go back to your own goals and don't interfere
  2) Review Results - once the results are in, dedicate time to review them in details, what is good, what is not so good, and make notes for everything; don't fix the results yourself
  3) Provide Feedback - take all your notes from the previous step, dedicate more time to make them as clear as possible before sending; finally send all the feedback and repeat expectations - go back to step #1 and repeat the full cycle until finally results match expectations


Also there are multiple ways through which you will never achieve the second badge, i.e.:

Don'ts to watch out for:
  1) Don't expect results without first setting expectations and clarifying them
  2) Don't yell when results are not matching expectations - instead just provide actionable feedback and repeat expectations
  3) Don't set deadlines based on how much time you would need to complete the same goal; however make sure to always have clear ETAs and to follow up on time as needed
  4) Don't fix low quality results yourself - instead ask for resubmission after providing feedback
  5) Don't confront when you identify a problem - instead ask for clarifications and observe
  6) Don't IM or voice-only your feedback - instead share it so that it can be traced back easily on G+, emails using #hash[tag]


How will you know if you have succeeded in mentoring new colleagues? They'll be the ones to achieve defined team goals and to share new experience and knowledge with you

Actionable inter-team deliverable approvals

Every Scrum team has either asked other teams for help with deliverables review or has provided assistance by reviewing deliverables of other teams

This inter-team collaboration encouraged as it will in turn improve inter-team communication, speed of deliverable reviews and most importantly quality of deliverables

However before Product Owners can accept a deliverable as approved, we'll need to see that the team performing the review has actually invested time to provide constructive and actionable feedback, or we'll automatically assume that deliverable isn't to expected acceptance criteria

What does this mean in practice:

Scrum team being reviewed - help reviewers to help you:
   a) Explain to the review team the intent behind the deliverable
   b) Specify areas that must be reviewed in a structured way
   c) Note what kind of feedback you need in order to have the deliverable approved

Team performing the review - provide full information in your reply:
   a) What has been reviewed
   b) What should be modified/updated/clarified, or
   c) Why nothing should be modified/updated/clarified (less likely)
   d) Recommend whether the reviewed deliverable should be approved or not by PO

Why should a team spend time to review other team's deliverables if they are not direct stakeholders? Our Company values statement says that Everyone serves: "Treat everyone as a customer, internal or external, and make responsiveness part of your personal brand. Build effective working relationships with a focus on being positive, informative, actionable, and helpful."

 

Leave-me-alone type of replies such as "Approved", "We have nothing to add", "This is good", and similar won't count as reviews at all when doing Sprint review

Efficient customer support chain

To have an efficient chain of help from customer and all the way down to developers teams should make sure to not skip steps and seek shortcuts as they will prevent internal growth but also unwillingly consume more of team time on the long run making the support inefficient and time consuming

 

 

What does this mean in practice?

 

   1) Support - don't be a hero, you cannot isolate all bugs by yourselves as this will suck up your time and you won't be able to work on anything else that day; pass complex support cases down to QA to isolate and reproduce the issue when you define the problem itself; not passing cases down to QA will also deny them of the opportunity to grow hard skills and help you better/faster in the future

 

   2) Support - make sure you do define what the problem is about when the customer first contacts you; this means you shouldn't forward received customer email directly to QA if you don't know the answer immediately - try to at least define the problem before pushing it down the chain to QA to isolate and report a bug

 

   3) Support - some of you have tendencies to contact devs and discuss directly with them whether a customer report is a bug and whether or not devs can fix it easily; don't go to devs but go to QA instead because going to devs without a defined bug will only waste time for both teams

 

   4) QA - although you no longer have unattended assistance metric this doesn't mean you should contact devs for every single support case and definitely not repeatedly when similar issues show up - I can hear directly from devs which QA team is doing better job isolating technical support case bugs

 

   5) QA - you can and should contact customer directly when you need additional help to isolate a complex problem; contacting customer through Support will only waste time of both teams and prolong solving the case

   6) Devs - help QA grow by giving them pointers what to research, check and isolate; if you always roll down your sleeves, dig down into code and isolate a problem for them, you'll be stuck doing this indefinitely while we'll have consequential impact on our product releases

Clueless QA Q&A

Unless you're finding tons of bugs each day and feeling primeval hate toward high entropy and other teams' imperfect work, you'll want to check out some of the use-case based Q&A below

Q1: I found a bug but my team members say it is not actually a bug and that I shouldn't report it
A1: What would a customer say after encountering the same issue in production?
Just ignore your team members, report the bug and let product owner worry about resolving reported bug one way or another

Q2: Product issue I found obviously seems like High priority but I'm afraid that team members and/or management will think I'm just inflating my monthly found bugs score
A2: What would a customer say after encountering the same unfixed issue in production that you didn't elevate?
Set the priority guidelines and use common sense, but always err on the side of customers. Don't worry, if I see priority inflation you'll hear from me

Q3: I used our Product B to help me while we're testing Product A and I found a bug in Product B; I don't think I should report Product B bugs at this time
A3: What would a customer say after encountering the same unfixed issue in Product B?
I don't remember when I saw some product bugs reported outside of regular test rounds - remember that everything is always in testing: all products, entire website, keyboard you're typing on, chair you're sitting on, this blog post you're reading now

Q4: Support asked me to help out to isolate a customer reported bug but I don't think I should talk to customers as my English skills aren't so good
A4: What would the customer say if the bug isn't isolated and isn't fixed in the next product version?
Think about it - customer is giving you a free bug and they are usually High priority, all you need to do is ask for details

Q5: I don't like how our new product is designed because it is confusing and hard to use, however it must be how developers, support, management and God thought it would be best so I won't report this
A5: What would the customer say to the same confusing or hard to use design?
Raise such issues early as bugs, if you think something is wrong then it most certainly is

Q6: One of the product menu items doesn't seem to work, but this is less used part of the product so it doesn't deserve a Test Case because Test Cases should only result in High bugs
A6: What would the customer say after encountering unfixed issue in production because if was simply missed and not reported as there was no corresponding Test Case?
Note that customers don't give a damn about our internal Test Case rules
 
Q7: I'm concerned that the bug I found cannot be fixed by developers and it should be fixed by another team so I don't think I should report it
A7: What would a customer say after encountering the same issue in production?
If you're so concerned about developers, ask them if they'd like a coffee and a cake, or just a foot massage instead of a bug report; OR you can just forget entirely about who should fix a bug and focus on reporting the bug itself
 
If you didn't notice a pattern above how to resolve QA concerns, please contact me directly to organize a special training for you

Everyone strives 101

Recent latest addition to our company values statement says that Everyone strives meaning everyone should be productive, focused, driven, and motivated. What does this mean during your everyday work?

 

   1) Focus on results - always know your end objective, whether you are working on a sprint goal or you have an unplanned ad-hoc task to finish. If at a time you feel like you don't know where to start or what should be the next step to get to the finish line, stop for a second and remember your end objective (new product build, analysis recommendation sent, documentation written and published, etc.)

 

   2) Expend the effort / go down with a fight - for various reasons we all get into time crunches to deliver. If you're already under pressure, worst thing you can do is to give up by "knowing you cannot finish on time" or that your "core hours have passed"; I've heard this far too many times, everyone is suddenly an oracle (no pun intended) and prefer to give up rather than go down fighting.

Working a few more hours killed no one and most of the time it is just enough to achieve your goal; even if the goal isn't achieved on time, you'll be able to finish it more quickly in the next sprint / next day

 

   3) Use time efficiently / demonstrate consistent productivity - on the contrary to the popular belief that you must always work overtime in order to deliver, simply remove time spenders from your everyday work; distinguish activity from productivity, just ask yourself: "What would happen if what I'm doing right now never gets done?" - this will help you uncover time spending tasks that lead nowhere

 

   4) Prioritize effectively - this is easy once you get used to it; just focus on your priorities - top PBI in your sprint, High priority bug, High importance email, etc. and you can never be wrong. Working on a lower priority task just because it is easier or quicker to do is always wrong - this happened so many times and although you may have a deliverable in the end, it will never be the right one

 

   5) Identify risks early and work to overcome roadblocks - "It was blocked by XYZ" is the most common reason for not getting something done on time; again in most of the cases it could've been prevented if this same goal was better prioritized and raised early. To fix this just use your brainpower to think of risks and prioritize those tasks before you start working - using brainpower afterwards to think of an excuse is a waste of time

 

   6) Single task - focus on exactly one goal and complete one task at a time before moving on to the next one. Yes, it is that easy

 

   7) Focus on daily deliverables - if you're about to shutdown your workstation, ask yourself: "What all have I delivered today?" - if you're having hard time thinking of an answer, reconsider the shutdown

 

   8) Set expectations realistically and expend the effort required to meet them - in almost all cases you have the freedom set your own ETAs - these are sprint Task estimates defined by entire Scrum team on sprint start, or ad-hoc task ETAs you provide when answering an email. Still it happens that you "overcommit" making it the second most common reason for not getting something done; even if you do overcommit, it is your responsibility to kick it into a higher gear and achieve the objective, but also to learn from it and improve your estimates in the future

Scrum tales - Part 14 - Spike goals

Almost all teams currently sprinting have encountered predictable work they can plan ahead but with a twist: work cannot be estimated until the work itself starts which defies a Scrum principle that all sprints must be time-boxed and that all work should be estimated during sprint planning

In a relation to previous post validating addition of research tasks to sprints, let's start using a specific Scrum element going forward whenever a research is required in order to estimate work needed to provide a deliverable - a Spike goal

Spike goal is a PBI that will have a specific deliverable which is not necessarily what Product Owner needs but what the team needs in order to estimate another linked goal that will eventually lead to a concrete deliverable requested by the Product Owner

Each Spike goal must be estimated ahead and time-boxed during sprint planning. The team will only commit to a Spike goal on sprint start. After the Spike is done, related concrete goal will then be estimated and added to the sprint / committed to

Typical workflow involving a Spike goal:
   1) Product Owner requests a deliverable (PBI goal) that is new or unknown to the team and cannot be estimated based on past experience or currently available input data
   2) Team creates a corresponding Spike goal, links it to the base goal and makes sure that the Spike is just above the base goal priority-wise
   3) During Sprint planning, the team time-boxes the Spike to i.e. 2 days in conjunction with Product Owner's approval, and creates corresponding tasks and estimates; team is now committed only to the Spike goal but not yet to the base goal
   4) As soon as the Spike goal is done, team will create tasks for the base goal since now there will be enough input data to estimate tasks leading to the concrete goal deliverable
   5) Sprint is groomed to make room and/or insert now fully estimated base goal and the team commits to deliver the base goal by the end of the sprint

Depending on the Spike goal outcome, it may be clear that the ongoing sprint won't be enough to complete everything needed in order to deliver to the base goal - in such cases it is best to discuss with Product Owner splitting the base goal and committing to deliver at least one part of the goal in the current sprint

Concise bugs for improved revenue

There's a whole chain of inefficiency spawned by each poorly qualified bug:
   1) QA reports a bug with a title not matching the actual issue close enough
   2) The bug slips through spot-checks with incorrect priority assigned due to inconclusive title
   3) Developers spend time to fix lower priority bug or miss fixing higher priority bug
   4) Support team cannot fix/define release note correctly and spends much time including getting help from QA
   5) Marketing team spends time copy-editing poor release note grammar or semantics
   6) Finally customers get lower quality release or delayed release with incomprehensive release notes

Solution - QA

Peer-reviews: if devs can peer-review code, QA can also peer-review new bugs
   a) Make pairs, i.e. team member 1-2 and team member 3-4
   b) Define review schedule - each day, just before sending test summary (this is up to you)
   c) Suggest corrections to your team pair about all bugs that don't look correct

Once we get the final summary, both the bug owner and the bug reviewer will be held responsible for poor bug title, incorrect priority, stds issues, etc.

Apply the same to new test cases

Solution - Support

As prime owners of release notes you shouldn't bow your head down and keep nagging while rewriting poor release notes
   a) For each release note you need to open a corresponding bug in order to rewrite it, write down the bug owner name
   b) Compile a simple rank list (leaderboard) 1, 2, 3, 4 - from most to least frequent bug owner who you needed to correct
   c) Include the leaderboard along with each corrected and approved release notes