O znaczeniu regularnychspotkań one-to-one jako krytycznym narzędziu zarządzania zespołem dla managerów napisano wiele książek w tym m.in. polecaną przeze mnie „High Output Management”. Jest to też wdzięczny powtarzający się temat dyskusji wśród społeczności managerów np. na Slacku u Bartka Pucka.
Jest to wspaniała metoda, by pomóc wzrosnąć swoim współpracownikom oraz budować prawdziwie efektywny zespół, a przez to i osiągać ponadprzeciętne rezultaty. Podobno jest to jedna z najważniejszych technik w arsenale managera. W takiej sytuacji przewrotne pytanie brzmi – kiedy wstrzymać się z regularnymi spotkaniami one-to-one z współpracownikami?
Widzę jedną powtarzający się schemat, w których lider powinien zastanowić się dwa razy przed wchodzeniem w takie zobowiązanie:
Gdy sytuacja prywatna lub zawodowa nie pozwala menadżerowi się skupić (1) i nie ma możliwości zaadresować potrzeb (2) swojego współpracownika.
Znam anegdotki od sfrustrowanych pracowników, którzy łapali managerów w trakcie one-to-one’ów próbujących załatwiać sprawy na telefonie czy komputerze. Inne powtarzające się opowieści, były o źle zrozumianej wersji 1on1nów, gdy managerowie oczekiwali skokowego wzrostu produktywności swoich podwładnych, ponieważ słyszeli że „jest to modne”. Chyba jednak najbardziej smutne są historie o pracownikach, którzy mimo prób, nie byli w stanie uzyskać pomocy od swoich liderów. Nie była to złośliwość, po prostu liderzy nie mieli umocowania w organizacji, by móc realnie pomóc swoim podwładnym.
Wchodząc w taką relację trzeba mieć świadomość z wagi takiego zobowiązania, to truizm, ale ludzie mają emocje i dobrą pamięć do uraz. Nie można podejść do tego iteracyjnie, trzeba spróbować zrobić to dobrze za pierwszym razem i umiejętnie zarządzać oczekiwaniami swoimi (co mogę zrobić?) oraz współpracownika (czego może oczekiwać?). Powodzenia!
What would you do if you feel that you have a fantastic opportunity, but following it would mean a betrayal of your values, and not following it would hurt your career? Questions like this repeat themselves in multiple stories since the dawn of ages. In them, the protagonist resists the urge and stays true to themselves, which leads to a happy end.
In reality, humans often act differently – this is why this trope is so often used. A significant number of couples cheat, entrepreneurs lie to their customers, leaders break their promises, and employees play dirty games.
Playing dirty is easy, and it feels damn good to trick the world („I deserve this” and other forms of self-deception to justify this is another topic), but such a decision comes with a guaranteed cost. The cost is your integrity.
While it isn’t valued by many, integrity is a crucial factor which differentiates true leaders. Staying true to yourself gives an emotional strength, clarity in decision-making, and makes other people trust you. We are social creatures. This is why people hate hypocrisy in others, as it means that this person can’t be trusted. You will not follow such person, as it is much riskier than you will be betrayed.
In most cases, your unethically achieved benefits will fade, or to keep your new status they will require additional shady decisions. Sunk cost fallacy can lead such person to an awful place in life. Of course, it might not happen, and it can turn up great. However, the damage which you do to yourself will stay with you and your memories forever.
If you are a person between such decision remember to check with yourself if it is worth it. Ensure that you will be able to live happily with seeing your face in the mirror, after selling out your values.
Every wannabe agile organisation tries a different approach to estimating using Story Points, which is the standard way to measure work in Scrum. It is hard to start, and after few sprints, teams tend to go back to estimate in hours, even as estimating in Story Points gives more value for the team in the long run. Additionally, this „Story Points” are confusing for external or internal stakeholders, as non-agile people usually estimate effort through hours.
So the first step for confused developers, managers and customers should be linking Story Points and hours in some way, so this measurement is valuable for Scrum team and comfortable for all sides. To achieve that I tend to explain that Story Points are a series of ranges of the probabilities of delivering task in a given amount of time (see the table). It seems to work, so I decided to write it down. You can use it for teams that start working in Scrum, but it might be beneficial for every organisation which earns money by selling hours of developers work.
Humans & estimating
Humans sucks at estimations using abstract values, example: how much grams does this apple weight?
We are much better in comparisons between objects or events, example: is this apple is bigger or smaller than orange?
More obvious the differences the easier is us to decide which option is closer to the „truth”, example: are oranges looks more like mandarines or an apple?
This is why values like Story Points, with big differences between each levels are better tool for estimating than hours.
Exponential complexity
The less you know, the (much) bigger is unknown of possible fuckups.
Complexity of task, and time needed to finish it, tend to it grows exponentially not linearly.
We need to perceive SP and effort like a category on their own.
Values of estimations
This is why Fibonacci-like sequence are so popular as, they aren’t linear which helps our brains to treat it diffrently.
The smaller scope of the task, less SP, the smaller effort variation between other tasks estimated in the same value will be.
I found SP values of 1, 2, 3, 5, 8, 13, 21 – as the most useful for every day work in weekly or bi-weekly Scrum sprints.
Real life anchors
No issue which take less than 15 minutes to do should be need to be written.
Even simplest tasks worth writing, tend to take around one hour. This is my lowest anchor, and I give this type of tasks 1 SP.
The biggest issue which should be in the sprint scope should be possible to finish in one week sprint. This means it should take around 40h. So for this type of tasks I set 13 SP.
For bi-week sprint the time we have is 80h, so I set this to be 21 SP type of task
Story Points values
„Linear” time
„Exponential” time
„Average” time
Real life anchor
1
0.25h (15 min)
1h
0.625h (38 min)
„Less than an hour”
2
1h
3h
2h
„A few hours”
3
3h
6h
4h
„Bigger part of the day”
5
6h
12h
9h
„Around a day”
8
12h
24h
18h
„Two-three days”
13
24h
48h
36h
„Around a working week”
21
48h
96h
72h
„Around two weeks”
Story Points example values
Tips & tricks for the future
It will never be a perfect way to predict the future.
Avoid 13 & 21. Try splitting them, as the smaller issue is the lower uncertainty you will have.
With time this time ranges will evolve, and this is healthy! Feel free to adjust them after your team knows themselves better.
Developers should be challenged and accounted for their estimations. Let them learn on their mistakes – this is the most crucial part for creating self-improving teams.
Be careful into creating more detailed estimation ranges, as they make the whole process longer, and more stressful for developers while providing just illusion of better control for management.
As a manager, deciding where between „Linear” and „Exponential” hours on average tasks will be is your way to take into account project risks.
