Hard sh** and smart sh**

Great GSD ("Get Sh.. Done" as ApexSQL Nis office central poster says) = consistently have both short term and long term transparent results

Some teams are working using Scrum work organization through goals (answer to what?) and tasks (answer to how?), while others have monthly goals / quotas to achieve by making daily and weekly progress in smaller increments

We often forget about the goals while focusing exclusively on the tasks at hand to get them finished no matter what, forgetting about what is actually needed in the end and in what time

Now I'm not saying that focusing on daily tasks is wrong - one of my own email quotes from the early days said:

"Focused, hard work is the real key to success. Keep your eyes on the goal, and just keep taking the next step towards completing it." - John Carmack

 

We must always keep in mind both the goal and have Daily deliverables at all times

But in order to grow, besides working hard we must also be cognizant of the end goal at all times and be able to work smart to achieve the goal

GSD has two levels:
   1) Hard Sh**: daily deliverables, things we must all do our part and complete in order to make daily progress, i.e. fix stubborn bugs, test bug fixes and report new bugs, write TS articles for unfixed bugs, publish articles, communicate with stakeholders, share your progress daily, etc.
   2) Smart Sh**: make a dent in the universe by aligning all action with end goals and complete the goals with a reasonable amount of effort in a reasonable amount of time

How does Smart Sh** translate to your everyday work?

   a) Dev teams should realize that customers don't have a use for 50 bug fixes in code and would much rather prefer 20 bug fixes in a product build they can actually download - know when to cut and deliver.
   b) SQA should invest time to understand product usefulness, to learn about it and to use it as customers use it in order to test the product well, to never assume they know everything, to write about it in non-hamburger helper way, and to excel in customer support.
   c) Everyone should be investing time into ERF mentorship with new colleagues so that they can start contributing back and in turn save time to you.
   d) Everyone should automate repetitive work - currently a huge soft spot in multiple teams.

What does automation have to do with working smart?

A lot: one of the funnier historical examples is several devs going rogue and writing a software that fully automates sending Daily Scrum Summaries - while other teams were taking hours of time weekly to manually compile good Scrum Summary emails, these devs took one day and created a two-click solution that in turn saved them days of time; I always received spotless Scrum Summaries from their teams which was a mystery to me until I found out about the "plot" ;) (devs are good guys, they were planning to distribute the software to everyone when we stopped sending these emails daily)

 

Time is a limited commodity so by investing some in order to automate repetitive work (smart vs. hard), devs gained more time to focus on what really matters: to write better code and to deliver great products to the customers in order to make a dent in the universe. I'm also sure devs had more fun in the process ;)

Ultimately whatever we do we must ask ourselves:

   A) Can I complete the task at hand more efficiently with less effort and time?

   B) What goal will be closer to completion when I finish this task today?

   C) What will I deliver to customers when the goal is completed?

   D) Will the customers pay me for the deliverable?

 

If no one will pay you in the end, why would you do it in the first place? ;)

Success is a science

The perfect candidate for an open position is an average one. Doesn't make any sense? Read on

A new employee is like a new product:
   A) We must do candidate testing (analysis) before the decision to go ahead, but no matter what we decide, results can be surprising. This is why the analysis must be focused/concise, as objective (scientific) as possible and most importantly fully comparable/relative between all the candidates
If subjectivity is still present in the end, it must be qualified with a quantifiable relative property for all candidates

   B) Outcome is unknown until we measure and see Growth Over Time - can be high ROI or can be a black hole with negative ROI. In the end we cannot know for certain what will happen no matter how extensive the analysis was, but we can make sure to have objective way to track GOT and again to compare it relatively between all hired candidates ("new products"). This is our main data point and is critical in any decision making process

   C) The best candidates can fail and the average ones can succeed; given a good system and large enough sample of average and easy to find candidates, success is inevitable. Our job is to take in all the objective data points and be decisive - exclusively select one of two options:
      a) Pivot - change the direction we're headed, part ways (drop/change further product development)
      b) Persevere - incentivize, keep on in the same direction with minimal changes that can again be measured when the time comes

   D) Do all the above in short and quick cycles; the sooner we succeed or fail, the shorter the cycle will be but either way we'll learn something new and be able to apply it in the next cycle

Production roadmap demystified

To escape the arbitrary process of determining production roadmap we need to instate a scientific and clear system to satisfy business needs and have unambiguous priorities for both products and their functionality. Production roadmap will be defined in few simple steps:
   1) Create empty slots for product releases per each developer team based on business (EPO) needs
   2) Perform Research and Analysis to determine clear priority list for new/existing product and their functionality
   3) Fill out the roadmap slots by following previously defined product/functionality priorities

Step 1 - empty slots creation
Owned by: COO with assistance of CEO/Sales

Business needs that guide creation of production roadmap empty slots:
   1. One possible release slot per core developer team per month (12 per team)
   2. 75% of empty slots are to be allocated for new High ROI products (9 "green slots" per team)
   3. Release one new major version for existing products each year

Step 2 - R&A rank lists
Owned by: DPD with assistance of other technical teams (Support, QA indirectly)

Singular system similar to what we use in HR - evaluate specific properties of each candidate, summarize, sort and create a clear rank list of recommendations to fill the "buckets"

We can distinguish 3 sets of properties* for 3 rank lists we need to fill out the empty Production roadmap slots:
   1. Possible new High ROI products (green slots)
   2. Existing products (purple slots)
   3. New/existing product changes/functionalities; prioritized list of features needed for each of the products we'll use to fill the allocated slots

*Specific properties for R&A product/functionality ranking will be detailed separately

Step 3 - filling the empty slots
Owned by: COO with assistance of DPD

With clearly defined business needs and R&A rank lists, filling the slots is objective process:
   1. Fill the green slots based on new High ROI products R&A list of priorities
   2. Fill the purple slots based on existing products R&A list of priorities
   3. Assign a minimum and maximum feature set to each product release; minimum feature set must be met, maximum only if there is enough time and resources allocated but not for the expense of delaying the release
   4. Proof the estimates with developer teams to establish a commitment of both sides: no changes on requirements side and no delays on developer side


Do's and Don'ts
   A) Do apply lean techniques for new releases: make each new product release as short as possible with minimum possible feature set needed to determine the success of the product; analyze first version results and make a clear decision to pivot or persevere

   B) Do plan and proof estimates conservatively to make Production roadmap predictable and solid for the entire year

   C) Do use priority pairs to determine the weights of business needs if something's got to break; i.e. New High ROI products > one major release for all existing products each year

   D) Don't assume available development resources are fixed but think outside of the box to satisfy all business needs

   E) Don't push back planned releases but instead cut out lower priority features to release on time

Scrum tales - Part 9 - The Five Whys

When the sprint ends we expect all committed goals to succeed which unfortunately is not always the case. Scrum teams must meet to discuss what went wrong and to discover the flaws in the process vs. just toss the blame around

Scrum teams meet to conduct a Sprint retrospective meeting with the main purpose to identify and analyze the issues in the Sprint process and to figure out how to fix them in the future sprints. Sprint is an iterative process and no matter what goals fail there is always a reason why they failed and it is not due to one team or one person's fault but due to a flaw in a process; this underlying flaw is what teams almost always fail to identify and skip finding a way to resolve it in the future sprints

Let's reflect on what great companies already did before us and use it to our advantage - specifically the Five Whys lean manufacturing technique will help us explore cause and effect relationships underlying specific issues we encounter and to finally get to the root cause of a problem or in our case a failed sprint goal

How do the Five Whys work? The team meets to discuss an issue and iteratively asks five times "Why?" or more specifically "Why did the process fail?" followed by determining a Proportional investment how to solve the issue going forward. Best to illustrate this with an example applicable to Scrum and the everyday goals we have:

Developer team sprinted and Product backlog item saying "Get new product maintenance version approved for production" failed. During the Scrum team retrospective meeting, the following questions should be asked and answered:
   1) First Why
Q: Why wasn't the product approved for production?
A: Not all High priority bugs were fixed in time to get the approval
Proportional investment: This is not a preferred solution, but if it comes down to a time crunch, you will roll up your sleeves for a weekend and catch up

   2) Second Why
Q: Why weren't all High priority bugs fixed?
A: New bugs were discovered during the unplanned third static testing round
Proportional investment: You will always assume there will be maximum number of static testing rounds when planning a new Sprint and never raise everyone's expectations by committing to releasing the product if the goal is too risky

   3) Third Why
Q: Why did the product go into three static testing rounds?
A: The product was of lower quality than expected even though it is a maintenance release
Proportional investment: You will always plan ahead for better internal self-testing before sending a new build to a static test round to catch and fix the low hanging fruit before it goes over to QA and results in unexpected new bugs

   4) Fourth Why
Q: Why was the product of lower quality than expected for a maintenance release?
A: Some of the engine code was rewritten in between test rounds in order to fix a specific bug that a customer requested to be patched
Proportional investment: Always first raise a hand when you see large code changes are needed and review with Product owner vs. hacking away at previously tested code and in the middle of product testing, no matter if the Almighty asked for the patch in person

   5) Fifth Why
Q: Why was the engine code rewritten between during final product testing phase?
A: We have to fix ASAP all bugs forwarded over by Support team that customers need fixed, no matter if we're in final testing phase or not, we have team performance goal to achieve
Proportional investment: No, you don't; this means our system is flawed and the product will be delayed meaning all customers will have to wait or risk getting lower quality build for one specific bug fix. Let's make a rule not to patch anything during product testing phase and instead do it immediately after the release to production if deemed necessary

To help out with asking and answering the Whys, I will volunteer to be the Why Master for all Scrum teams meaning you need to invite me in all Scrum retrospective meetings if your sprint goals failed to quickly discuss how to improve our processes and prevent future sprint goal failures