Antywzorzec Adrenaline Junkie

Cały czas zastanawia mnie skąd biorą się takie sytuacje, że jest generowana presja i napięta sytuacja w projektów. Jednym z powodów jest to, że większość projektów jest zwyczajnie złożona – trzeba dogadać kilka, kilkanaście czasami kilkadziesiąt osób, trzeba przewidywać i planować z pewnym wyprzedzeniem to co się wydarzy, jakie zasoby będą potrzebne. Jak gatunek ludzki wcale nie jesteśmy w tym dobrzy (vide: David Rock – Twój mózg w działaniu) – w szczegółowym planowaniu długoterminowym.

Drugi mechanizm, który dokłada swoją cegiełkę do choasu, to syndrom adrenaline junkie. Termin ten pierwotnie został ukuty w kontekście sportowym i dotyczy osób, które świadomie szukają aktywności, który podnoszą poziom adrenaliny, sytuacji z lekka niebezpiecznych, których spora część osób wolałaby uniknąć. Uwielbiają kiedy coś się dzieje, kiedy sytuacja wymyka się spod kontroli, bo wtedy są niezbędni, wzrasta poziom adrenaliny i jest zabawa. Sytuacja staje się bardziej subtelna, kiedy adrenaline junkie ma na sobie garnitur i chodzi pod krawatem, a przynajmniej chowa się za kierowniczym stanowiskiem – wtedy dodatkowo ma duży poziom wpływu, który daje spore możliwości, aby wywoływać zamieszanie. To działanie nie jest świadome – po prostu tak się dzieje. (W kontekście projektów IT zostało do opisane w książce "Adrenaline Junkies and Template Zombies")

Po czym poznać adrenaline junkie? Taka sytuacja.

Siódma rano pobudka. Jeszcze 5 minut. Drzemka. Kolejna drzemka. Kolejna. Ok. 7.30 trzeba już w stać, bo o 8.00 powinienem być w pracy. Mam umówione spotkanie. Już praktycznie nie ma szans, żeby udało mi się zdążyć. Szybko biegnę pod prysznic, mycie zębów, w pośpiechu ubieram się. Cholera – jeszcze muszę wyprasować te spodnie. Wychodzę 8.53. Na pewno nie zdążę. Ile się spóźnię? 20 minut? Może się uda. Dzwonię do osoby, z którą się umówiłem. Będę 8.15. Wsiadam do autobusu. Cholera korki na drodze. Fakt – zawsze były korki. Autobus się wlecze. Chyba jednak nie zdążę na 8.15. Tyle razy sobie mówię, żeby nie siedzieć do 4 nad ranem. Dzisiaj już na pewno pójdę spać wcześniej. Docieram na spotkanie o 8.25. Mój rozmówca jest zdenerwowany. Staram się żartami nieco rozbroić sytuację. Spotkanie kończy się o 9.30. Później mam następne. Później następne. Później następne. Do 16.30 mam same spotkania! A kiedy pracować? 16.35 coś by się przydało zjeść. Nie mam czasu. Idę do najbliższego sklepu i kupuję 3 batony. Ale co za dzień! Tyle pomysłów wygenerowaliśmy, szykują się nowe tematy w projektach. Fakt, że po całym dniu spotkań, trzeba to wszystko jakoś zebrać, maile powysyłać, pospisywać zeznania. Ale teraz pędzę do domu, a w zasadzie do szkoły, żeby odebrać córkę. Chwila czasu dla rodziny. W międzyczasie ktoś dzwoni. Musiałem wyjaśnić kilka szczegółów, których nie udało się dogadać w ciągu dnia. Próbuję bawić się z dziećmi, ale cały czas to, co się wydarzyło w ciągu dnia wraca i zaczynam analizować, co jeszcze można by zrobić. Znowu dzwoni telefon. Dzwoni zdenerwowany klient, który chce zerwać współpracę, bo jest niezadowolony. Przerywam zabawę z dziećmi. Po pół godzinie udaje mi się uporać z klientem – jest udobruchany. No dobra, żeby teraz tylko dzieci poszły jak najszybciej spać – mam jeszcze tyle roboty. 21.30 uffff. W końcu spokój. Muszę przejrzeć, co mam jeszcze do zrobienia. Roboty chyba na kilka godzin. Nie ma co marudzić – trzeba działać. 22.30 trochę oczy mi się zamykają. Zrobię sobie króciutką drzemkę. Pobudka 23.00. O jak mi się nie chce wstawać, ale jakoś się dobudzam. Robię herbatę. Przeglądam fejsa. Po pół godzinie jestem już na rozruchu. Pierwszy mail, drugi, trzeci. Czuję wiatr w skrzydłach – kocham tę robotę. Godziny mijają nie wiadomo kiedy – 1.00, 2.00, 3.00.  Nie zauważyłem kiedy zasnąłem. Budzę się z bólem karku siedząc nad komputerem. Ok. Pora iść spać. Jutro o 8 mam spotkanie – tym razem nie mogę zaspać.

To typowy dzień adrenaline junkie. To typowy dzień niejednego kierownika projektu, właściciela firmy czy ambitnego lidera. Dla tych osób to co się dzieje, jest ok – przecież musi się coś dziać, żeby doprowadzić tematy do końca. Ciągle nie mają czasu, ale też ciągle generują sobie nowe tematy, nowe wyzwania, nowe zadania. Gdy poziom aktywności, a co za tym idzie, adrenaliny spada – robią się apatyczni,  niezainteresowani, znudzeni. Z drugiej strony są to często ludzie, którzy napędzają działania, są motorem napędowym zmian, lubią kiedy jest im niewygodnie, uwielbiają poświecenie się na 150%. Dlatego duża część z nich zostaje właśnie kierownikami czy dyrektorami, ale bardzo często oczekują podobnego poświęcenia od innych.

Adrenaline junkie to antywzorzec w kontekście pracy nad projektami czy produktami, ponieważ dla tego typu osób, produkt czy projekt jest drugorzędny, jest głównie pretekstem do tego, aby generować energie, poziom napięcia, wtedy pytania o sensowność czy wartość działań schodzą na drugi plan, bo ważniejsze jest to „żeby się działo”. Oczywiście w czasie realizacji działań, kiedy dużo się dzieje, tego nie widać w żaden sposób i powstaje sprytne złudzenie, że to co robimy jest ogromnie ważne i musimy to robić. Plusem takiej postawy jest generowanie energii, napędzanie innych do działania.

Powstaje oczywiście pytanie, co można z tym robić. I muszę przyznać, że nie znajduję łatwej odpowiedzi. W pierwszym odruchu chciałoby się powiedzieć: „zwolnić”, „pozbyć się”, „wymienić na kogoś innego, bardziej zrównoważonego”. Może to być trudne, jeśli dana osoba jest sponsorem czy też pomysłodawcą przedsięwzięcia. Takiej osoby nie będziemy w stanie przekonać o jej destruktywnym wpływie na całość. Zmiana tego typu postawy jest bardzo trudna, nawet jeśli tego dana osoba chciałaby coś z tym zrobić. Z dużym stopniu wynika z budowy i specyfiki układu nerwowego i hormonalnego. Spora część tego wzorca jest zakodowana w genach. Można by zasugerować, aby swoją energię upuszczali gdzieś indziej – na bieganiu maratonów, triathlonie czy sesjach boksu tajskiego. Ale prezesowi tego nie zasugerujemy, no chyba, że pijemy z nim wódkę. Osobiście, gdybym dostał się pod jurysdykcję takiego delikwenta – albo bardzo mocno ćwiczyłbym stawianie granic („OK, gościu – jeśli chcesz i cię to nakręca, to generuj sobie masę zajęć, natomiast ja chcę pracować 8 godzin. Kropka.” – powiedziane w ten lub bardziej dopasowany do rozmówcy sposób) albo zwyczajnie bym się zawinął, szukając bardziej przyjaznego miejsca.

Życzyłbym sobie, żeby takich adrenaline junkies było jak najmniej, bo takowi swoimi działaniami mocno erodują system. Z drugiej strony wiem, że gdyby nie oni, wiele fajnych rzeczy być może nigdy by się nie wydarzyło. Takie życie. Nic czarno-białe.

(image source: http://www.galwaydailynews.com/wp-content/uploads/2014/06/101001junkie_302.jpg)

Read More

Unknown 12:32  No comment

Perspective of the other side

While working with leaders I come accross the similar issue many times - they want somebody else to change their behaviour. For example:
How to deal with people that criticise my ideas?
How to force boss not to micromanage the team work?

We would like someone else to change, because we know that we are right, we have good intention and want to improve the work and the other side just disturb us. We believe that Agile/microservices/Product focus (not project)/whatever is the only idea that can help and everyone who doesn't agree is an enemy that should be ceased.
If somebody critices my ideas - must be wrong. If my boss try to micromanage he is an ignorant, because every book about management describe it as an antipattern.

But let's be honest - all ideas like:

• (the power of) teamwork
• limit work in progress
• authonomy (instead of micromanagement)
• timeboxing
• agile/kanban/lean
• TDD/BDD/ATDD/Spec by example
• (...place your lovely idea here...)

are just ideas. They are supported by a set of believes, but mostly subjective believes. You believe it or not, but you can't prove they are right. They are just models, theories, hypothesises, patterns, heuristics, strategies. Because they are applied in complex enviroments, there are contexts where they will be beneficial, and there are contexts where they will not, and sometimes it will be very difficult to evaluate their real value. So everytime you meet someone else who doesn't agree, be aware that s/he can be right. It is a first step neccessery to deal with the issue. It is secondary what you believe in, much more important is how you react when sb doesn’t agree or follow.

The most important obstacle to tacle the challenge is our tendency to look at the situation only from one perspective - "I" perspective. This perspective is subjective, because it is based on our current believes, expectations, state, knowledge and biasases. This is why it is so difficult to solve problems between people. If we really want to find a win-win solution, we need to try to see situation from the perspective of other side ("you" perspective).

If a person critices your idea, just try to find an answer "why"? But beware because we like to see negative intention in other people's behaviour. "He critices me because he wants to diminish me". In some rare cases it may be true but it is not the root inention. The root intention is in most cases positive, at least from the other side perspective.
S/he may criticise your idea because s/he wants ensure that the best possible solution will be applied. Or want to warn about potention problems that may arise.

In the second example, if boss want to micromanage, just ask "why is it important". He may want to ensure that work will be done correctly or will be done in standarized way. When you know the intention, it is easier to find a solution - different way how boss can ensure it not micromanaging.
If you just say "Micromanagement is evil", you will try to take something away from him what is important and give nothing instead.

So the next time when you don't like someones behaviour or attitude, try to look at the situation from its perspective asking question "why is it important for him/her? what is a positive intention" and then it will be much easier to tacle the situation. And remember most of the stuff you think is right way of doing things is just set of believes, subjective belives so don't be too much attached to it.

(Of course the subject is not specific only to technical leaders but can be attributed to whole human race.)

Image source: http://www.etcfn.com/wp-content/uploads/2015/04/Rainbow-over-Rabbit-Ears.jpg

Read More

Unknown 17:53  No comment

Simple things. Simple things. Simple things.

I have been yesterday to a great concert. The band is called domowe melodie. Here you can find one of their best know song. Of source the music was great, performance was great. But these things were not the only.

What hit me the most - these guys attitude to what they do. They just have a lot of fun from what they do. They play with it. They enjoy it and this is great and they do it in their own cute way. Just watch one of their videos. You get influenced immediately.

This reminded me what makes the juice of life. I wish we had so much fun and pleasure in our everyday jobs. The leaders (and everybody is a leader) can support making this happen. Be more emphatic, more smiling, more open. Life would be greater.

Don't do anything that isn't play - Marshall Rosenberg.

Read More

Unknown 15:16  No comment

Meetings in a hurry are not effective ones

The timeboxing is a fundamental technique for many Scrum activities. I can see a misunderstanding that meeting should be fast, a facilitator start to hurry up everybody to finish the meeting in the timebox. In the end problems are not discussed well and many uninformed decisions are made.

Time boxing in this case is about something different. It is for making conscious decision on choosing what and what not to talk about during the conversation. It is more for eliminating than for being in a rush.

In order to have effective timeboxed meeting as a facilitator:

1. ensure everybody agrees what is the goal of the meeting, what is expected outcome and what decisions should be made (eg. planning meeting - we want to have items discussed with defined acceptance criteria, estimated and have brush design),
2. ensure that agenda (structured) is agreed,
3. keep an eye on time,
4. if time is in danger, say it aloud and remind the goal, expected outcome and decision,
5. ask what participants think they should focus on or eliminate in order to get the results in the timebox,
6. if time is about to exceed the timebox, make an agreement for another time box (eg. we exceed the meeting for 30 minutes),
7. sum up the results,
8. sometimes it may be useful to make a short retrospective afterwards to find ways to improve the meeting.

image source: http://hubpages.com/health/How-to-Time-Box-your-life-Be-happier-and-healthier

Read More

Unknown 12:25  2 comments

Have a clear vision, stick to the intention and adjust the implementation

No matter if you are tech lead, Scrum Master, Product Owner or just (why just?) a member of the team, if you want to make your idea a reality I have a very simple (and of course very difficult to implement) advise:
Have a clear vision, stick to the intention and adjust the implementation

Let's consider an example. Let's suppose you believe that incremental work is cruciual and want to influence the team to work this way.

1) have a clear and strong imagination of the target state
The first thing is that you yourself really have to believe in it. And you have to be able to imagine what it would be like for your team .How the team could split the work into smaller increments, how to verify if something is a good small increment. You need some kind of reference in your experience, then it is much easier to have such a clear vision. If you don't the only thing you can do is getting more inspiration about the subject (reading the articles, books, listening the podcast, watching conference talks or just taking part in a conference) and then suggest an experiment. You can use Disney strategy to get more clearance.

1b) try to find as many WHY answers as possible.
First try to answer the question WHY yourself. Why is it really worth the attention?

Why increments?

• because it is easier to finish it in a short period of time
• because if you have many small pieces your overall estimations will be better
• if the increments are going to be very small, you may not need estimation at all
• increments (slices of functionality) improves your ability to finish done work
• you need to improve the way you work to be able to work in increments

Ok. But but then look for other resources - articles, books, blog posts and so on. And look for other arguments.
And then face these arguments (at the begging only in your mind) with your team. What would they answer? How that matches to the things important to them.

2) be patient and stick to intention
No matter how good arguments you have and how good they match team needs and how clear vision you have, others may not buy it. That's ok. Be patient. You just didn't find good enough way to show the value*.

Listen to the objections and look for the needs behind them.

Maybe they don't believe that they can organize work in increments. Maybe they don't know how to do it. Maybe they don't believe it is effective. Look for the way how to show it. Look for the way how to measure and compare both types of approach to items. Look for more inspiration.
Stick for the intention but not to solution. If you think about increments your intention is to slice the work vertically so that it can be integrated and deployed and the exact solution like BDD, TDD, the best slicing method are not so important. Be free about the implementation of the intention. Suggest the experiment, not the final solution.

3) adjust the implementation
If you managed to organize an experiment - do regular retrospectives (get feedback) and adjust the implementation. Maybe slicing one thing into 36 small items is not the best way. Let team find (and decide) a balnace in slicing.
No matter how the experiment is doing, regularly ask, what works, what not and why. What your team ca change to do it better. Getting back to the intention and revising  the implementation is your job. Local failures are just next step on the path of learnings. Failed? Just figure out what you learnt and make adjustments.

4) have a clear vision, stick to the intention and adjust the implementation
Yep, repetition. Repetition is mother of skills. So ... have a clear vision, stick to the intention and adjust the implementation.

* There is also a possibility that vision you have and/or share with others might not be a good option, so don't be eager to validate it from time to time.

Read More

Unknown 10:01  No comment

Two structuring meetings patterns

As I describe it in my book it is good to structurize meetings (or parts of meetings) so that they get more effective. Here you can find two examples useful for Planning meetings (Scrum examples that can be easily adopted to other situations).

Structure: Expose the options

During the planning meeting there was a moment when the overall group energy was very low, but there were three guys intensively discussing about the subject having different opinions what to do next. There talked about their argument so passionately that it was very easy to get lost and miss the point, and I am afraid they also weren't sure what the other side is talking about. Then I suggested:
- Only three people are discussing here, the others are bored. Let's name the options you present and whole the team will vote and choose the solution.
And one of the team member got the pencil and started to write on the board:

1. let's do the task as much as are able to, let's hope we will finish it in this sprint
2. let's divide it into smaller items, and choose the subset we will do for sure
3. let's take it to the refinement and we will do this item in the next sprint

It turned out that it was not so easy to express the intent clearly and it also turned out that one person didn't understand what the other wanted to say. Because all the team were suppose to vote they engaged in the discussion so that they could make a handy decision and the energy group was back.
Five people voted on second option and two people on the third. The decision was made.

What kind of structure you can find here?

When: group or just a few people are discussing intensively
Then:
1) notice that you can see not everybody is engaged or the decision far from being made
2) ask for naming the options (it would be great to write it so that everybody can see it)
3) vote on the options (you can do it similarily to the planning poker game)
4) if there is a draw: draw the option (or have any other arbitrary method to choose the option)

Structure: Structuring Planning meeting

When the particular type of meeting tends to be chaotic it is good idea to introduce structure to organize it.
When I thing about Scrum Planning meeting I like to seperate the steps of planning (a few selected steps):

1) The team browses the items that
a) have been refined recently
b) weren't finished in the last sprint
c) are at the top of the backlog
Browse means to remind very shortly intention of the item and not going into details.
2) Product Owner supported by the team prioritetises (expressing why) and chooses the items that are the strongest candidates to be chosen to the current sprint. In many cases it means that the weakest candidates are removed.
We do it so that we will not discuss about things that are not going to be developed in the sprint.
3) Starting from the top (the highest priority item) Product Owner presents (or reminds) acceptance criteria for the item and the team estimates it (supposing that items are refined enough to get estimated). This is also time to talk about details if it is neccessary.
Other version:
Product Owner presents all the items (one by one) and then the team has time on its own to do some brush desing and make estimations.
4) Team chooses how many items they can do so that they can make a reliable commitment.

No matter what kind of structure you use it's important to keep the borders of the steps clear - especially not to talk about details to early (or maybe not to talk at all).

Read More

Unknown 23:20  No comment

The Hacker Way

.
.
A few days ago Paweł Wrzeszcz sent me an Erik Meijer’s talk  „One Hacker Way” https://www.youtube.com/watch?v=FvMuPtuvP5w from GOTO Conference that took place in Copenhagen. It is a very provocative talk and that is very good. It questions the (mostly) the Scrum method and it is good that such point of view stands out because as Scrum became the main process framework for software development it is very healthy to look at it in a critical way. As a industry we have 20 years of Agile experience, Agile became a big business machine (which I am also part of) and it is very easy to destort the core ideas what really happens especially when doing Agile at Scale (take a look at Dave Thomas’ Agile is Dead talk https://www.youtube.com/watch?v=a-BOSpxYJ9M).

So the Erik’s talk is about ending status quo about Agile.

What I don’t like about it is the form it is presented. It is very manipulative and Erik’s presents one way thinking. Some examples:

• ·      he compares Scrum to McDonalds (process, average predictible quantity and quality, any teenager can work there) – which programmer wants to work in McDonalds? A biased metaphore;
• ·      he builds attractive identity – the Hacker identity in opposite to Agile team player;
• ·      „I prefer build software (coding) than doing standups” – is it in oppoiste?
• ·      Scrum is about controlling Hacking is about freedom and innovation - really?;
• ·      „every minute of talking about software is lost” – it reminds me an old programmers antipattern of just going into the code not thinking much about the context.

What kind of antidote Erik wants to recommend? The hacker way:

•      Focus on impact – solve the most important problem;
•      Move fast – you can learn only by doing;
•      Be bold – take risks, experiment;
•     Be open – be transparent about decisions;
•     Build social value – bring what you did to community.

What I can see in the above values? Exactely values of Agile and Scrum.

• Focus on impact is about creating business value;
• Move fast – inspect and adapt;
• Be bold – courage;
• Be open – transparency;
• Build social value – I can’t see anything directly connected to it, but I think it is very aligned with agile.

What I also don’t like much about the talk is that it lacks of context. Erik’s worked for Microsoft, Facebook and these are the sources of his expriences. He presents a view of software company that has its own product. (I know that he claims that in the future the biggest companies will be the software ones). What about software companies that outsource their services, what about companies that just have their IT deparment with a bunch of developers? The hacker way is a developer-centric idea, which can be applied in companies that are developers-centric and having its own product. Why having its own product? Beacuse hacker way is about doing experiments (more than planning in any way) and taking what was done (Eric Meijer’s says „Be a beekeeper. Let programmers make the honey and take what they did). Experiments are about having a time buffer to do it what is not much possible when you just have a small profit margin from programmers work (when you do B2B services). Developer-centricity also mean that you need very skillful programmers. To summarize up, the context for The Hacker Way is:

• ·      a developer-centric software development company;
• ·      having its own product;
• ·      having top programmers on board;
• ·      where the core business is about innovation.

What more can we get from this? What is the meta-level message of Erik Meijers?

In my opinion some part of community (industry) is a little bit tired of Agile/Scrum/whatever you call it. It moved towords a management method more than to Software Craftsmanship (and this is also the reason why the Software Craftsmanship emerged). I can hear the voice, that programmers got involved into planning, talking about requirements, micromanaging and are not much happy about it. They want to code. Although the goal of introducing Agile is to ease the process, it is still quite heavy when we come to the meetings (what is also my observation after years of practicing Scrum), especially in Scaled implementation of Agile. And I think that it is important to hear this voice and find the way how to tune it. It is kind of „inspect” message and it is time to adapt.

Read More

Unknown 10:51  2 comments

Technical Leadership book is available

It is a great pleasure for me to share the information that today is my "Technical Leadership" book premiere. You can buy it from Helion and I also encourage you to visit book companion site http://technicalleadership.pl . I am going to develop a technical leadership knowledge base there, so be in touch.

Read More

Unknown 09:58  No comment