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
Tuesday, February 12, 2013
Monday, February 11, 2013
Pick up the rifle v2.0
Not sure who owns specific task, system functionality, who has a ball now? The simplest and usually the correct answer to this is You do!
A couple of things that all Scrum teams encounter is a task blocked by an external team - i.e. waiting for question feedback, waiting for review, waiting for approval, waiting for... Does this mean that the external team owns the task now? No - You still do
How to unblock such tasks? There's always a way, here are a few:
a) Talk about or at least mention all blocked tasks within your team every day on Daily Scrum meeting
b) Help ScrumMaster to summarize and report all blocked tasks to Product Owner after each Daily Scrum
c) Make sure you have an ETA for reply from the external team and remind them early and often
d) If not waiting for approval then attempt to workaround, try to resolve the task yourself vs. waiting indefinitely
Sprint cannot fail because a task was externally blocked because You own the task and your team headed with ScrumMaster have the ultimate responsibility to unblock it on time
What about Scrum unrelated system ownership - who owns support forum, who owns product source code, who owns posted defects? One would think these are all straightforward and implicit but let me still clarify by taking the latest as an example - ownership of all posted defects
Simply think of a posted defect the same as a QA owned Sprint task:
A) All defects are posted by QA ("tasks" are created by the Scrum team itself); others teams may in some cases create a few defects (Support for customers, developers for engines only) but defect priority ("task" estimate) is provided or modified by the QA team
B) Defect creator is current owner of the "task" and must follow through to the end - provide additional details, retest, close the defect
C) If a defect owner is not available to update the defect ("task" is blocked), QA team have the ultimate responsibility to unblock it by taking the ownership vs. waiting indefinitely on external teams to act
D) If there are defects created by Support and unverified, posted by former colleagues, made obsolete by new product versions, who's "sprint" will fail if they remain blocked indefinitely?
A couple of things that all Scrum teams encounter is a task blocked by an external team - i.e. waiting for question feedback, waiting for review, waiting for approval, waiting for... Does this mean that the external team owns the task now? No - You still do
How to unblock such tasks? There's always a way, here are a few:
a) Talk about or at least mention all blocked tasks within your team every day on Daily Scrum meeting
b) Help ScrumMaster to summarize and report all blocked tasks to Product Owner after each Daily Scrum
c) Make sure you have an ETA for reply from the external team and remind them early and often
d) If not waiting for approval then attempt to workaround, try to resolve the task yourself vs. waiting indefinitely
Sprint cannot fail because a task was externally blocked because You own the task and your team headed with ScrumMaster have the ultimate responsibility to unblock it on time
What about Scrum unrelated system ownership - who owns support forum, who owns product source code, who owns posted defects? One would think these are all straightforward and implicit but let me still clarify by taking the latest as an example - ownership of all posted defects
Simply think of a posted defect the same as a QA owned Sprint task:
A) All defects are posted by QA ("tasks" are created by the Scrum team itself); others teams may in some cases create a few defects (Support for customers, developers for engines only) but defect priority ("task" estimate) is provided or modified by the QA team
B) Defect creator is current owner of the "task" and must follow through to the end - provide additional details, retest, close the defect
C) If a defect owner is not available to update the defect ("task" is blocked), QA team have the ultimate responsibility to unblock it by taking the ownership vs. waiting indefinitely on external teams to act
D) If there are defects created by Support and unverified, posted by former colleagues, made obsolete by new product versions, who's "sprint" will fail if they remain blocked indefinitely?
Subscribe to:
Posts (Atom)