Diagnosing organisational problems with I-Messages

This article is part of my work on Conversation Patterns for Software Professionals

---

Typically conflict between people or teams is a symptom that indicates there something's up. The tool I use for that situation is based conversation patterns. With this tool you will be able to come to a bigger picture on what is really going between people.

There is very strong assumption behind this tool need to be accepted first: people are not problems on their own. A behaviour may be a problem, environment, lack of skills or even belief may be problems, but not a human being.

You-Message

In case of issues causing a conflict and lots of negative emotions people tend to express their statements in a specific way - they talk about others. Take a look on some real-life examples

• PM: Developers are always delayed
• DEV: PO must know what he really wants
• PM: The problem is team's velocity
• DEV: Requirements are not specific enough
• PO: Developers spends time on useless refactoring or something
• DEV: Business people are always changing their minds
• PM: They didn't tested all features

I have interviewed lots of people and mostly I hear same messages: He is..., They should be..., She don't... and so forth.

But what invariably surprise me most is that all of them seem to be true. Really! Spending whole day interviewing developers I came to conclusion - Damn, what the crap they deal with?. Same talking with business people I often think God, what a hopeless situation!. Every story I have heard make sense in its context.

I imagine this kind of communication something like that

The more individuals I talk to, the more chaos appears in my mind. It is really hard to understand what is going on basing on those stories.

Aha moment

Then I finally understood - all those people talked about themselves. They expressed their needs and expectations, but they do it in very indirect way. Talking with the You-Message makes other people the source of our problems and there are only two solutions in that situation: fight them or leave them.

I-Message

I followed this idea and I started using the Need Structure and Upward Generalization Pattern to lead my interlocutors to express their needs in the form of I-Message.

What are the I-Messages? These are statements where one expresses oneself, eg. I want..., I don't..., I like to..., I am lack of..., I need....

Be careful, statement I want you to stop is You-Message like not the I-one like. With I-Message you express just only yourself and nothing more, this is critical.

So, this kind of communication I imagine something like that

And some examples of transforming You- into I-.

You-Message	might mean / I-Message
Developers are always delayed	I need to close projects on time I don't want to work under time pressure I am accounted for time and budget I want to be kept informed of any problems which may cause delay as soon as possible
PO must know what he really wants	I don't fully understand what to do I need acceptance criteria for every user story I start to develop I want to be kept informed about new ideas as soon as possible I want to have an impact on the sales strategy

Notice that I-Messages express needs very clearly and it may turn out that all individuals want same thing eg. to be kept informed.

Putting people stories in the form of I-Message introduces lots of order to the communicational chaos. It's easier to see what is going on and what is needed.

Next I use Conversation Structure and Downward Specification Pattern to clarify acceptance cirteria of met needs and for negotiating the solution.

Local Adaptive Step

Every team wants to do good job, but almost always they face with some adversities. These may be: unclear requirements, delays, communication issues and so forth.

Let's say a team wants no extra features during an iteration. This is quite logical expectations, but... things are more complicated. Extra tasks comes from PO, PO is pressed by CTO, CTO is pressed by CEO and CEO is extremely pressed by impatient client.

So, applying the system thinking to this picture it turns out that cause of problems defined by a team might lay in The System organization, not always in the team itself. That's useful point of view and it helps to find a solution in many situations.

However it works, a team or a team leader might not have the authority to reorganize The System. Even if one were a client is mostly beyond of one's influence. So, from one side a team is sure the problems are: clients or salesmen or management:). It wants all of them to change and to follow strictly the Scrum, Kanban, RUP or whatever guideline. Sometimes it's possible, but those are rare cases. Frustration grows up. What to do then?

Maybe start thinking locally, here and now

Let's forget about formal methodologies for a while and think about a team as an agent in the context of some organization.

Now we may observe a team is responsive to surrounding forces.

Instead of implement a methodology causing lots of organizational change (and also mess), let's do a local adaptive step toward the state of balance.

A local adaptive step is actually searching for a balance between all forces surrounding a team. Do whatever needed. You need for Use Cases - do Use Cases, need for formal docs - write a formal docs, don't need for iterations - don't do it at all!. So, a team is not expected to be agile, but it's expected to be balanced.

There are some of my insights on constraints a team have to be assured to do a local adaptive steps.

• a team is fully responsible for expected results of its work
• a team is free to make all decisions needed to achieve results
• a team is free to reorganise its structure and process of work

The Developer and a developer

As an employer I have a privilege to decide who I work with. I hire people and also have fired some of them. I've noticed there is kind of employee who does right anything one has touched. And opposite: some people screw up even simple stupid tasks.

I cannot say what exactly is the difference, mostly I feel one is the right one. But I have some observations:

The Developer	a developer
is focused on the task	is focused on options of the solution or on 'the best solution'
is patient	wants to have things NOW
when failed feels a frustration or a sadness	when failed feels a guiltiness
assumes oneself of being a cause of one's mistakes	assumes others of being a causes of one's mistakes
argue with people	blame people
has own daily routine	does things impulsively
wants to know what was done right or wrong	afraids to know what was done right or wrong, so avoids it
takes things happened as a result of work and constant feedback	takes things personally
takes the responsibility for a relationship between involved stakeholders	takes the responsibility for tasks one was told to accomplish

Taking a responsibility

I always hear from team leaders: I want a developer to take a responsibility for assigned things. I was unable to understand what was 'a responsibility'. Now I think I should ask them: What are those 'things' you want a developer to take responsibility for?

Personally I am sure team leaders didn't mean responsibility for a task. A task is nothing. Having a task completed is not always directly related to increasing a business value. It may be, but this is not the rule.

Having said responsibility team leaders had in minds responsibility for a relationship. That's right. The core of being responsible for something is responsibility for a relationship between all involved stakeholders. Doing tasks is part of it. But meeting stakeholder needs and increasing business value always comes with taking care of relationship.

About payment

I won't write anything new. But spending our own money I convinced myself that cheap is expensive if about employee's salary. We used to hire employees only by reason of their financial expectations. Mostly they were unskilled. We invested our time teaching them. When they picked up some knowledge they left the organization. So we decided to hire the best people we can afford according to our business goals.

Software delivery organisational anti-patterns

It's good to have some electrical engineering background before reading this post ;P

I am confused every time I am asked what is the best way to manage requirements or which one is better: use cases or user stories, or how to ensure software quality by testing or how to evolve architecture properly, or does the *DD works, which design patterns are most wanted, what is better: agile or RUP. These are tricky questions, especially asked a consultant as I am.

Let's me try to explain what is a tricky part in these questions.

From IT point of view, the only goal of IT-Business collaboration is software delivery and nothing more. I like this term "software delivery" because it simply explains what we are responsible for. To achieve this goal we developed many tools which makes our work more effective. These tools address some difficulties we faced with when we collaborate with business people.


It is very important to notice these tools (show on the figure above) are not either-or dilemmas. You take whatever works and fits to a project context. Please read carefully at least:

• Writing Effective Use Cases by Alistair Cockburn
• Introducing BDD by Dan North
• Decisions, decisions by Dan North
• Specification By Example by Gojko Adzic
• Domain Driven Design by Eric Evans
• The Object Primer or agilemodeling.com by Scott Ambler

and you will see the tools are not competitors. Use stories are not compete with use cases, TDD is not competes with test-last approach, Scrum is not competes with free-style processes, DDD is not competes with simple anemic model, testing is not competes with test-free approach (really).

There is no "better", there is no "the best". Every single tools covers some aspect of IT-Business collaboration on software delivery. And everyone causes some benefits and consequences. But, you are responsible to choose a tool according to the project context. So yes, you should familiarize yourself with all of them.

The Source of All Evil

Problems start when one want to build a business around software delivery.

To scale the business one have to scale software delivery process to be more efficient.
So, one takes some of the tools and tries to compose The Process, for example: Analysis -> Architecting -> Implementing -> Testing -> Maintaining. So, tools becomes The Process steps and one builds teams around this steps.

You may say: ok it's old-school waterfall process. But, even organisations declaring agile approach have at least Analysis and Testing Departments. The rule is: the larger organisation is the more presented solution is applied. Where is a trick?

Software delivery is atomic. The only responsibility is to deliver software that is satisfying business needs and that's all. But scaling a software delivery we split this atomic thing into steps in a sequence.

We assume we may also split the Responsibility into small responsibilities of every single step. Moreover, we assume that Responsibility of whole software delivery is the superposition of the small responsibilities. In general it is not true.

You know, organisations where software is developed by programmers and tested by testers I may observe a lot of problems with a code quality and tension between Software Development Software Quality Departaments. Why? Because software developers are focused on their own responsibility and testers are focused on their own one.

Software Developers assume that testers will find all bugs and they are less motivated to test their own code. As a result tester have more and more work with bugs. And this a vicious circle.

One more example. Organisations where analysis is done by analysts (God, I'm trembling ever time I hear "Project Management Center") and development is done by developers, mostly have problems with requirements quality. It is happen that people don't know how to implement a requirement.

I think that problems listed above were caused by splitting what is unsplittable by the definition. Software delivery is unsplittable, it is atomic. We may use all tools to deliver better, faster or simpler. But we cannot split that tools into steps in a sequence. It doesn't work in that way. Once again: problems were not caused by the people or lack of competences. Problems were caused by the organisational anti-pattern.

Decoupled teams

Better idea is using tools around software delivery without splitting them.

Do you see the difference? Regardless of tools used the responsibility stays constant.
Ok, that was a metaphor but what about real world solution.

Solution is many stable Development Teams. A Team is responsible for delivering a complete working product. Moreover, there is no any dependencies between teams. A team is atomic.

Yes, I know there is more question than answers. How large a product should be? How to cooperate with other teams? How to build and develop a team? And so on, and so on.

The truth is we are in alpha-phase if about scaling agile teams on large projects and organisations. Some inspiration you may find in Disciplined Agile Delivery by Scott Ambler. Absolutely great case study is Scaling Agile @ Spotify. I believe the answer is out there and it will come soon.

Conversation Patterns: Polowania na czarownice i czarowników

This article is part of my work on Conversation Patterns for Software Professionals

---

(...) uzmysławiamy sobie tę prostą prawdę, że za wszystkimi komunikatami, którym dotychczas pozwalaliśmy brzmieć groźnie, stoją jedynie ludzie o niezaspokojonych potrzebach, którzy proszą nas, abyśmy coś zrobili dla poprawy ich samopoczucia, Marshall B. Rosenberg

A gdy już coś pierdyknie, to zaczyna się poszukiwanie przyczyny niepowodzenia. Skądinąd ta racjonalna idea opiera się na uproszczonym założeniu, że gdzieś istnieje single point of failure, lub double. No, skończona ilość pojedynczych przyczyn.

Jednak dyscyplina system thinking wskazuje, że niepowodzenie jest wypadkową złożonych interakcji w "systemie". Ciekawe studium przypadku w tym kierunku możesz znaleźć w Efekcie Lucyfera by Philip Zimbardo.

A więc szukamy winnych...

...ponieważ, czujemy potrzebę rozładowania emocji, z którymi sobie nie radzimy. Kolejne szczegółowe objaśnienie znajdziesz w Porozumieniu bez przemocy, skąd pochodzi początkowy cytat.

...ponieważ, to najłatwiejszy sposób do uzyskania poczucia, że problem został zrozumiany, i że w przyszłości będzie można go uniknąć. Oczywiście owo "poczucie", nie oznacza, że sprawa rzeczywiście została rozwiązana. Oznacza to wyłącznie tyle, że skoro polała się krew, to wszyscy zestresowani zainteresowani odetchnęli z ulgą, że oberwał ktoś trzeci i że sprawę załatwiono.

...ponieważ nie umiemy sobie radzić z "otwartymi" sprawami. Trudno zająć się czymś innym, gdy nurtuje Cię pytanie, na które nie znasz odpowiedzi, test, który nie przechodzi, czy //XXX, którego nie możesz namierzyć. Ta zasada jest podstawą każdej hmmm... metodologii efektywności m.in. 7 Habits of Highly Effective People, Getting Things Done, Personal Kanban, Awake the Giant Within, które dają przepisy na przekształcanie "otwartych" spraw w motywujące mierzalne cele.

Psikus z otwartymi sprawami polega na tym, że gdy czegoś nie rozumiemy i w dodatku mamy do tego mocno emocjonalny stosunek, to rozpaczliwie szukamy zamknięcia otwartej sprawy, choćby owo zamknięcie było najgłupszym z możliwych. W ten sposób zadowalamy się prostymi odpowiedziami na trudne pytania i preferujemy tanie suplementy intelektualnej diety.

Co z tym fantem?
Poniżej podaję kilka pomysłów, jak przeciwdziałać poszukiwaniu winnych. Nie są to rozwiązania instant, ale kilka z pewnością się przyda.

• Omawiaj wtopy po weekendzie; będzie nieco czasu na ochłonięcie
• Omawiaj wyłącznie fakty (ad rem). Fakty dotyczą tego, co do mózgu dostarcza nam jeden z pięciu podstawowych zmysłów, czyli to co można zobaczyć, usłyszeć, powąchać itd; szósty zmysł a więc wszelkiego rodzaju mind reading zostawiamy w spokoju
• Jak ognia unikaj zdań zawierających: jesteś (ad personem), zawsze, nigdy, ciągle, wciąż, żaden (kwantyfikatory)
• Jak piekielnego ognia unikaj ocen - ten punkt jest dla wielu z nas nie do przejścia. Zdanie Zobaczyłem, że to spieprzyliście nie jest stwierdzeniem faktu lecz oceną, bo czynności spieprzenia nie można zobaczyć, ale można zobaczyć, że: w połowie iteracji na tablicy wisiało dużo zadań z błędami, burn-up chart ma 20 schodków, ktoś zatwierdził kod z błędami itd.
• Omawiaj fakty tylko z pierwszej ręki. Zabawa w głuchy telefon jest śmieszna w przedszkolu i to tylko wtedy, gdy traktuje się ją jako zabawę; tymczasem dorośli traktują głuchy telefon śmiertelnie poważnie
• Najpierw zbierz wszystkie punkty widzenia, a dopiero potem je omawiaj. Z szacunku dla tajemnicy ludzkiego umysłu bezpiecznie jest założyć, że nawet gdy ktoś coś komuś zrobił, to każda ze stron ma świadomość tylko wycinka całej sytuacji. Najpierw zbierz wszystkie puzzle, a dopiero potem staraj się zobaczyć obrazek
• Rozwiąż problem lokalnie, a potem standaryzuj
• Trenuj Technikę pozytywnej intencji

Dużo piszę o faktach. Mówimy o faktach, ale wszystko to w obrębie empatycznego porozumienia, po które odsyłam do książki Marshalla Rosenberga.

Niezadowolenie ma sens

Product Owner, który "odpuszcza" w trakcie demo, działa przeciw zespołowi. O co chodzi?

Iteracja była trudna. Wyskoczyło sporo bugów, związanych z niezaplanowaną refaktoryzacją dawno zapomnianego kawałka systemu. Zespół pracował na najwyższych obrotach, a schodki na burn-up chart zdawały się nie mieć końca. W ostatnim tygodniu wszyscy z utęsknieniem czekali na piątek, a gdy już nadszedł, od samego rana czuć było podekscytowanie zbliżającym się demo.

Wysprzątany pokój, rozstawiony rzutnik, zespół w świątecznym nastroju. Brakuje tylko czerwonych goździków dla zasłużonych. Wszyscy z uwagą śledzą rozmowę PO z jednym z programistów, prezentującym implementacje poszczególnych historyjek. Scenariusz po scenariuszu idą jak z płatka i nagle..&^@%!@

W tym momencie w zgodzie z niektórymi teoriami Wszechświat się rozgałęzia i mogą wydarzyć się co najmniej dwa scenariusze.

Scenariusz A

Następuje chwila niezręcznej ciszy, podczas której PO patrzy na napięte twarze zespołu, na których między wielkimi, jak u Puszka Okruszka oczami, powiększa się nabiegły łzami znak zapytania.

Ktoś powiedział, że największe boje w historii ludzkości wydarzają się w zakamarkach ludzkiej duszy. Nie inaczej jest teraz. Po długiej jak wieczność chwili, na twarzy PO pojawia się miękki uśmiech.
- Ok - rzuca ciepło - powiedzmy, że jest zrobione. Dokończycie w międzyczasie ("międzyczas" - niepotwierdzony żadną poważną teorią bufor czasowy, w którym da się wykonać więcej pracy, niż w całym projekcie łącznie).

Wszyscy oddychają z ulgą. Znów jest miło. Po zakończonym demo ludzie w pośpiechu wymykają się z biura. Już weekend. Można odsapnąć i zająć się czymś innym niż to natrętne, kołaczące na skraju świadomości odczucie wewnętrznego "fuj".

Niestety historia lubi się powtarzać, więc i ta się powtórzyła. Po trzeciej podobnej repecie, idąc na demo ludzie zaczynają włączać autopilota itd., itd., itd.

---

Scenariusz A'

Nastąpiła pełna napięcia cisza. Cisza. Przeciągająca się cisza. PO wziął głęboki oddech i:
- Przykro mi, ale to jest DONE. Nie zgodnie z tym, co ustaliliśmy jako DONE.
- Ale przecież jest to tylko kwestia kosmetyki. Parę godzin i będzie gotowe. A ta druga historyjka jest gotowa, tylko jeszcze nie wdrożona. Projekt nam się za długo buduje.
PO popatrzył na rozmówcę wzrokiem Johna Wayne'a i powiedział:
- Gdybyś miał za tę pracę zapłacić z własnych pieniędzy, to zapłaciłbyś?

Niemal w tej samej chwili, Piotrek wybiegł z sali trzasnąwszy drzwiami, a w reszcie grupy, wybuchła gorąca dyskusja, od czasu do czasu ocierająca się o kłótnie.
- Nie - powtórzył twardo PO - Nie jest DONE. Nie odbieram.
Na tym dyskusja się zakończyła.

Gdy pył opadł, zespół zasiadł do retrospekcji. Mieli nad czym dyskutować, więc ledwo zmieścili się w założonym czasie. Ustalono, że: Paweł z Marcinem rozpoznają temat serwera CI i one-click building, koncept zadania zawsze będzie analizowany zespołowo, blokery będą omawiane na forum i w razie potrzeby zespół decyduje się na swarming, historyjki z najbliższego sprintu zostaną ponownie przeszacowane, refaktoring będzie robiony zawsze parami.

Ludzie wychodzili z biura w znakomitym nastroju. PO ich cholernie wkurzył, ale znaleźli rozwiązanie. Zawsze znajdują. Wprowadzili do swojej pracy niezbędne modyfikacje. To się już nie powtórzy. Nie ma prawa się powtórzyć. Po weekendzie zaczyna się nowy sprint. Każdy z programistów już widzi najbliższe demo i PO śpiewającego peany na ich cześć.

---

Wniosek

Czasem, nie chcąc sprawiać komuś przykrości, robimy mu krzywdę.

Niejednorodny zespół

Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule - napisali niegdyś mądrzy ludzie i zespół w tej postaci jest super. Jednakże robiąc przegląd inwentarza, możesz dojść do wniosku, że stan rzeczy rzeczy w Twoim zespole oraz zasoby, którymi dysponujesz, odbiegają od tego docelowego obrazka. Co wtedy?

Co jest?

Może się dla przykładu okazać, że "dostałeś" pięciu programistów, trzech testerów, analityka oraz Scrum Mastera z nadania, który ostatnimi czasy poświęcał się wyłącznie zarządzaniu.

W takiej konstelacji możesz się spodziewać następujących objawów:

• Polaryzacja między testerami a programistami; nie piszę "wrogość", lecz właśnie polaryzacja my-wy: wy zrobiliście błąd, wy skopaliście testy, my coś zaimplementowaliśmy, itp.
• Programiści mają chroniczny opór przed testowaniem
• Testerzy biorą znikomy udział w planowaniu
• Analityk nie za bardzo może znaleźć swoje miejsce w zespole
• Pojawia się zastanawiająco dużo spadów z poprzednich sprintów

Może się okazać, że po przeprowadzeniu małego śledztwa, ma miejsce następujący związek przyczyn i skutków:

Jak mogłoby być?

Długoterminowym celem mogłoby być oczywiście doprowadzenie do sytuacji, w której każdy jest wspomnianym "developerem", ale o tym na początku lepiej nie mówić głośno:)

Co pomiędzy?

Sądzę, że w takiej sytuacji kluczowe jest, nie tyle męczyć ludzi, aby byli idealnym zespołem, co wydobyć tu i teraz to, co najlepsze. Bardzo dobrym początkiem będzie przeorganizowanie sposobu planowania. Otóż:

• Planujcie podgrupami dzielonymi względem testerów, np. tester+2*programista
• Każda grupa otrzymuje swoje US, które dzieli na zadania
• Analityk chodzi i doradza :)
• Wyodrębniajcie zadania: programistyczne, testerskie, analityczne
• Po zakończeniu dekomponowania grupa przedstawia swoje US, a reszta zadaje pytania kontrolne Czy uwzględniliście to, a to? i jeśli nie, to dodajemy kolejne zadania (uwaga celowo jest tu odwrócenie: grupa nie przedstawia swoich zadań, lecz odpowiada na pytania kontrolne zespołu, gdyż w przeciwnym razie zamęczycie się i zanudzicie

Pytania retrospekcyjne po wprowadzeniu w/w zmiany (po jednej bądź dwóch iteracjach):

• Jak oceniam współpracę między testerami a programistami?
• Czy wciąż mówimy o sobie my-wy?
• Czy będziemy mieli spady w najbliższej iteracji?
• Jak dużo zadań doszło w trakcie iteracji? Jakiego rodzaju były to zadania?

Kilka słów o roli analityka
Analityk bywa w Scrumie czasem zagubiony. W jaką rolę ma się wcielić Proxy Product Owner, Scrum Master, Product Owner? Jedną z powtarzanych przyczyn zmieszania analityka są te cholerne straty w projekcie. No bo jeśli jedyna wartością jest "działające oprogramowanie", reszta to strata, a jemu kazali pisać dokumentację, to ma poczucie, że wykonuje bezsensowną i bezwartościową pracę.

Myślę, że te "straty" wymagają małego komentarza. Analityku, jeśli w założeniach projektu stoi napisane, że ma być dokumentacja analityczna w projekcie, bo tak wymaga klient, ustawa czy ktokolwiek inny, to dokumentacja również jest wartością w projekcie i również dodaje punty do business value.

Przykładowe zadania, w których analityk może wspierać zespół:

• współpraca i mediacje:) z PO
• backlog grooming
• prowadzenie Product Canvas; ciekawe linki: tutaj, tutaj i tutaj.

Ćwiczenie dla zespołu

Retrospekcje dość często opierają się na wrażeniach. Dyskutujemy o naszych spostrzeżeniach i o zmianach. Wrażenia dają wiele informacji, lecz dla równowagi chciałbym zaproponować Twojemu zespołowi retrospekcję opartą na liczbach.

W najbliższej iteracji podejmijcie jedną praktykę: ilekroć karteczka trafi do kolumny IN PROGRESS, oznacz datę umieszczenia w tej kolumnie oraz datę umieszczenia w kolumnie DONE.
Podczas retrospekcji wybierzcie zadania, które przebywały w IN PROGRESS maksymalnie jeden dzień (typ A) oraz te, które przebywały tam trzy dni i więcej (typ Z), i odpowiedzcie na następujące pytania:

• Ile było zadań typu A? Ile było zadań typu Z?
• Na ile początkowo były szacowane zadania typu A oraz Z?
• Dla których zadań, A czy Z, błąd oszacowania jest mniejszy?
• Czy zadania typu A są sformułowane inaczej niż zadania typu Z? Na czym konkretnie polega różnica?
• Które z zadań są formułowane pełnym zdaniem? (z czasownikiem i rzeczownikiem)
• Czy któreś z zadań sformułowane jest w trybie rozkazującym?
• Które z zadań przechodzą Test Copy-Paste?*

I na koniec wnioski: w jaki sposób następnym razem należy formułować zadania.


*) Test Copy Paste - to dość dobry sposób weryfikowania konkretności zadania. Jeśli przeniesiesz swoje zdanie do innego kontekstu i wciąż ma ono sens, to prawdopodobnie jest mało konkretne. Na przykład zadania: Napisz test, Przygotuj dokumentację, Zaimplementuj serwis wyszukujący pasują wszędzie. Nieważne czy pracujesz nad CRM, portalem e-bankowości, czy sterownikiem klapy od sedesu - te zadania mają sens, w każdym z wymienionych kontekstów. Aż się prosi o ich zdekomponowanie.

Lecz zadania: Napisz test do porównywania dochodów klienta na wniosku z danymi biura nieruchomości, Zaimplementuj podgląd wniosku windykacyjnego zdefiniowanego w BAF po przeniesieniu do innej przestrzeni problemu tracą swój sens. Tracą go ponieważ ich sformułowanie jest na tyle związane z tym konkretnym kontekstem, że bez niego trudno jest zadania zrozumieć. Takie zadania mają bardzo wysokie actionability, są na tyle konkretne, że łatwo je wykonać OD RAZU. Oczywiście Test Copy-Paste nie jest zero-jedynkowy, lecz wyznacza pewne continuum konkretności i actionabilitności :) zadań.

Kanban On The Fridge Door

Perhaps in your case it is different, but when my family grew bigger, I started to have a backlog of household tasks. In fact, I couldn’t make it, my task lists were bursting at the seams and todoist.com frightened me with prompts every five minutes or so. As we all know, backlog leads to another backlog. The more you try to put something off, the more afraid you become. The more afraid you become, the easier you put it aside, etc. This is the initial stage that I was in.

Stage 1: What is really going on?

So I determined to do something about it. Although I did not have any idea what exactly would change, I thought to myself that if I did something – anything, whatever – at least I would see if it helped or not. Than I would have at least one thing less to test.

To gather more information, I talked with a colleague of mine who has a couple of years of experience in bringing up two children. She gave me the following hints:

• Lack of time is not a consequence of you having children or not having them. Lack of time results from the number of things that you cannot foresee. Therefore, be more precise in your foresight.
• Don’t add up tasks to your everyday routines. Instead, you should plan and complete one task, because if you start doing seven things at the same time, you will end up having them unfinished and you will definitely feel irritated that you haven’t done anything.
• Keep your things always in the same place. Take this example: the night comes and you have to change the nappy. You start looking for it everywhere, make a lot of noise and wake the baby up. And this is the end of your night, thank you, now you can only dream of yourself sleeping, not to mention the tot. Therefore, always keep your things in the same place. After you have done 3 steps with your eyes closed, you have to have all the necessary equipment at your elbow.
• Sometimes you just won’t be able to do anything. Accept it.

After some consideration I came up with the following rules of conduct: plan, limit your WIP, improve your flow, be more self-understanding. And that’s how my thoughts reached Kanban.

I came home like a whirlwind and the only thing that I could think about was to paper the kitchen walls to visualize the work process. The negotiations with my wife ended up with me having the fridge door at my sole disposal. Ok, it’s better than a poke in the eye. The first board had three columns: TO DO, IN PROGRESS, DONE.



I took action.

First effects

The change was really huge. I couldn’t pass by the IN PROGRESS sticky notes indifferently. Oh, I just couldn’t. Due to the fact that I see my fridge every day, I did not have to write the start date and monitor the progress with any special attention. I just knew when my tasks got stuck and I felt that it was just too long.

What is more, it turned out that tasks I had postponed earlier, seemed more frightening than they really were. For example: when my daughter was born I was already for some time engaged into bringing order to my documents that I had decided to thematically group in folders. For about 5 months I did not have time to finish it. This thing really bothered me and I estimated that I would need at least one whole weekend to complete this tasks. When the time for this sticky not came, it turned out that… the documents were already in order and I just had forgotten about it. Really! When I stopped working with those papers, I just didn’t complete this task in my head, so it still bothered me. When I started doing it again, after 10 minutes I felt proud to put this sticky note in the DONE column.

I started to catch up on my backlog and within two months I was there – with no overdue tasks to do.

Stage 2: Where is business value?

One evening it occurred that it all didn’t work as good as I thought. My wife told me that she saw that I did complete my tasks and that I really cared, but for her nothing changed.
-Umm… How is that possible?, I asked.
-Nothing changed. I still don’t have enough sleep, I am tired. she said showing me her task list in GoogleTask. And I don’t have time for anything. You do your job, but it does not change our situation.


And then I experienced enlightenment once again: our situation. How could I forget about it? A family is the most natural kind of team on earth! When one member of this team performs, the others get stuck. It became clear that we need to use the pull model.
My wife got her pile of orange sticky notes and I asked her to put some tasks on the board. We agreed that we would deal with them whenever any of us would have time. That is how our improved version of board came into being. The board finally involved the entire team – not only me.



Then I started to think how I should know that everything is OK. How to notice that we deal with the “right” tasks – how to recognize our business value? Due to the fact that I did not know how to identify it and I did not want to create anything artificial, I decided to start with the issues that I discussed with my wife. I decided to measure our business value with two questions:

• Do I have time to myself?
• Do I feel tired?

Because of the fact that my team does not feel convinced to (and interested in) the Fibonacci number and consecutive two squares, I decided to use smile index that you can see on the image.



That was a go! Both me and my wife could intuitively measure the business value of our team. We still do it – from time to time, when we walk through the kitchen, we show the level of satisfaction that we currently feel. As you can see on the image, there is some progress :)

The questions that I mentioned are also useful when we need to decide if a given task should be done now. Assuming that we will do it now, will it turn out that we have more time and we feel less tired?

Stage 3: The value stream appears

We reached the point at which our expenses rocketed. We just went too far and we realized that it wasn’t the only month that we went too far with our spending Although I used kontomierz.pl, this issue just slipped by. I was wondering how it was possible that I had had no control over our expenses. I realized that some bills had waited to be recorded for so long that the month would already be over and I either still did not have them there or I tried to catch up with recording them in a hurry.

I came to a conclusion that we have to change it as well and keep our financial activity under control. I came up with an idea of an additional swimline called FINANCES. Now that my wife felt somehow committed to this teamwork, she agreed to relocate the board from the fridge to the wall.



So we formally introduced the BACKLOG section and items from this group are regularly evaluated and we move them to the WORTH DOING section. We divided the IN PROGRESS column into three parts: FOR NOW, FOR TODAY, PENDING. We have also added the already mentioned FINANCE swimline

The new board has become more transparent, which gave us a wider perspective and… a new quality. I have soon noticed that some tasks are distinguishing in comparison to others – they are as if bigger, and when we complete them, they do not bring any major consequences. Consider the following tasks:

• Fix the bathtub baseboard
• Register the expenses
• Buy tickets for a trip to the brother-in-law

and compare them with these:

• Organize holidays
• Find a new flat
• Find a new flat

Urgency and importance rediscovered

Obviously, the second group of tasks implies something bigger to be done and I am aware of that. But you know what, you won’t see it until you notice it. Look at the picture below. Those fat tasks are put on violet sticky notes and I circled them in red.



For a couple of months I was working with the board, but when I finally saw it as a whole, when I saw the map of my work, I noticed the difference between these types of tasks. I noticed it in a different way than I used to notice it. I felt it to the bone. Take a look at it and you will see that the number of violet sticky notes is small if compared to the rest. It is incredible to see how many other things wait to be done and how hard it is to decide which are the priority. Those most important ones make up the so called value stream. For some of them it would be good to open a separate swimline or create a separate table.

The thing is that when you complete tasks day after day, all the tasks that you are engaged in here and now seem important – you have to complete it.
How can you not buy a ticket for a trip to the brother-in-law? Once you see everything that you do on the table, when you see the entire process of your work, you start to see some patterns. In your life you finally start to feel things that you only knew about. It has a great impact on your motivation, time management and awareness of what is important and what is not, which in turn enables you to develop a crucial skill – the ability to resign.

Additionally, we have placed a new and experimental visual representation of our spending.



http://kontomierz.pl, as I have already mentioned, is a very handy tool to keep a retrospective control of our expenses, but currently I am searching for some methods to have a prospective control. But this is another cup of tea :)

What have I learnt?

First: don’t try to come up with a great upfront solution. You need time to start noticing what you really deal with. However, you should remember that to notice you need to look at, examine and visualize your work.

Second: even in a well-knit team any change takes place gradually. It’s nice that you have a vision, but others may not share it. Start from small things, show that they work and support them with some new practices. Start from the fridge. If it works, you will soon end up having the wall :)

One more thing about urgency and importance

I have the impression that it is all not about something like: how to avoid urgent and unimportant tasks or how to delegate them (since we do not have any subordinates). It really often happens that all in all you have to complete these tasks (hands up who’s not cleaning at home?). Usually the number of such tasks is so great that you run out of time to deal with the “bigger” ones. The whole idea is about finding time for some rare important tasks. It is about completing the urgent ones without neglecting the important ones.

Kanban vs. GTD

For a number of years as my main framework I used Getting Things Done. GTD is exactly about getting things done. When you use it, you do everything that you deem important. GTD does not allow to set priorities the way we understand it. Instead, it focuses on the ways to optimize your activity through an emphasis on a clear definition of actions that you need to take, contexts in which you have to take them, and the optimal procedures that will allow you to work.

In contrast, Kanban gives you a perspective and, according to the author of the Personal Kanban book, an instant kinesthetic feedback. You see your own business process, which gives you a chance to analyze and revise it – and, of course, a lot of satisfaction from putting the sticky notes in various columns:)

I still see the great value of GTD. It really defines a lot of detailed techniques that are missing in Kanban. Here you will find a good comparison. Not to repeat myself I will just list those things that I would like to enrich my Kanban with:

• Definition of actions to be taken; a task has to be actionable, because then it is easier to complete
• Decomposition of tasks to make them unambiguous (more information about this technique is presented in the chapter about specification in this book)
• Very “thick” division of actions which makes them more actionable
• Work according to FIFO
• Brainstorming
• Work contexts
• Fresh head :)

These are the major elements. I really encourage you to read both David Allen’s book and Jim Benson’s book. However, please remember that to have the knowledge does not mean the same as to know how to use the knowledge.

Wstęp do mierzenia efektywności zespołu

Szerszy artykuł na ten temat możesz przeczytać w bieżącym numerze programista.pl.

Środowisko pracy

Kluczowym czynnikiem wpływającym na efektywność zespołu jest środowisko, w którym pracuje. A zatem:

• Wymagania
• Klient
• Architektura
• Typy zadań
• Charakterystyka zespołu
• Technologia

Aby poprawić efektywność zespołu, w pierwszej kolejności pracuj nad poprawą środowiska pracy. Nawet najefektywniejszy programista będzie nieefektywny w nieefektywnym środowisku.

Nie porównuj ze sobą zespołów, które pracują w różnych środowiskach.

Efektywność zespołu

Efektywność zespołu to jego zdolność do zrealizowania celów, z których rozliczany jest lider zespołu przez swojego przełożonego. Właśnie tak, nie wierzymy w bezwzględne miary efektywności. Takich miar zostało zdefiniowanych setki. Każdy lider ma taki pogląd na efektywność, który wspiera realizację celów, z których on sam jest rozliczany.

Lider chce, aby zespół zrealizował jego cele. Sposób wpływania na zespół zależy od lidera, definicja efektywności i miary również. Dwóch różnych liderów (np.: transakcyjny i transformacyjny) realizujących te same cele, będzie miało inne pomysły na zespoły.

Jeżeli w ogóle można porównywać ze sobą zespoły to nie za pomocą miar, lecz poprzez to czy i jak realizują cele swoich liderów.

Ponieważ cele wyznaczane liderom się zmieniają zatem i definicja efektywności wraz z miarami musi się zmieniać. Miary mają sens "teraz", "później" mogą już go nie mieć.

Dostajesz więcej tego, co mierzysz

Jeśli mierzysz ilość linii kodu, otrzymasz więcej linii kodu. Czy aby na pewno o to chodziło? Dobieraj miary tak, abyś dostawał więcej porządanych zachowań.

Miary skupiają uwagę

zespołu na tym, co jest mierzone. Czasem, choć nie jest to regułą, czynność mierzenia może sprawić, że ludzie staną się uważniejsi i zmniejszą ilość określonych zachowań.

Miara agreguje wiele czynników

Miara to wynik zagregowany. Najczęściej zawiera w sobie kilka informacji, nie tylko jedną.

Rozliczanie rozpoczyna grę

Każda forma rozliczania ludzi z osiągnięcia współczynników skutkuje stworzeniem gry, której celem jest uniknięcie kary lub zdobycie nagrody, a zasady gry polegają na osiągnięciu określonych wartości współczynników. Więcej o powstawaniu gry znajdziesz w artykule W co gra się w projektach?

Tworzenie miar dla osób zwiększa ryzyko rozpoczęcia gry. Tworzenie miar dla zespołu zmniejsza to ryzyko.

Używanie miary

Używaj miary do obserwowania postępu, jako przesłanki do zadania pytania "dlaczego?", wskazówki do rozpoczęcia coachingu. Nie używaj miary do oceniania ludzi.

Weryfikowanie miary

Gdy już zdefiniujesz miarę, która pomoże ukierunkować zespół na osiąganie przydzielonych Ci celów, zadaj następujące pytania:

1. Co właściwie mierzy miara? Jakie wielkości agreguje?
2. Czego otrzymam więcej?
3. Jakie gry mogą się rozpocząć?

A następnie zastanów się, co należy zrobić, aby zminimalizować negatywne skutki wprowadzenia miary.

Od czego zacząć?

Od mierzenia. Jeśli nie masz żadnej miary dla zespołu, zacznij od określenia niezmienników. Niezmienniki to pewne ustalone wielkości, które dla zespołu i projektu będą zawsze stałe. Niezmienniki są bazą względem której będą odbywać się pomiary. W pierwszej kolejności rozważ następujące niezmienniki:

1. Fazy procesu dostarczania
2. Typy zadań
3. Długość iteracji
4. Granulacja zadań

Scrum jest trudny...

Sam nie wiem od czego zacząć:) Może najpierw przeczytaj artykuł Kiedy Agile nie zadziała

Zawsze gdy chciałbym z pełną odpowiedzialnością powiedzieć Tak, Scrum Wam pomoże. Go! mam pewien dreszcz niepewności. Wynika on stąd, że osoba która jest odpowiedzialna za wdrożenie Scruma chciałaby wiedzieć: po czym konkretnie poznam, że Scrum działa? po czym konkretnie poznam, że jest lepiej niż poprzednio? jak długo potrwa zanim zobaczę konkretne efekty? no i, ile to mnie będzie kosztować?.

Może się zdarzyć, że po wdrożeniu w jednym zespole, w drugim oraz po przeszkoleniu, jak to się ładnie mówi" propagatorów zmiany, nic się nie dzieje. Dlaczego? Mam parę tropów.

Samoorganizujący się zespół

Samorganizujacy się zespół jest możliwy. Nawet dwa czy trzy takie zespoły w życiu widziałem, a w jednym miałem przyjemność pracować. Ale to jest naprawdę duże wyzwanie stworzyć samoorganizujacy się zespół. Aby zespół się samoorganizował najpierw trzeba go świadomie zaprojektować, wyhodować. Mimo dużej wiary w ludzi trzeba uznać, że nie wszyscy ludzie w zespole mają jednakowe kompetencje. Nie każdy zespół, nie każdy jego członek podejmie odpowiedzialność.

Samoorganizujace zespoły się zdarzają. Najczęściej dziwnym zbiegiem okoliczności odpowiedni ludzie spotkają się w odpowiednim miejscu, gdyż tak jak wspomniałem, rzadko kiedy konstruuje się zespół w planowy sposób nie tyle pod kątem kompetencji technicznych, lecz pod kątem kompetencji "zespołowych" właśnie. Konstruowanie zespołu to kosztowna akcja wymagająca zaawansowanej wiedzy HRowej albo superwymiatacza z doświadczeniem, który zrobi to "na wyczucie".

Zawiązywanie się zespołu, przejście procesu grupowego to jakieś trzy miesiące. Scrum nastawia się na hodowanie zespołów i przydzielanie do nich projektów. W ilu organizacjach proces biznesowy jest tak ustawiony, że to jest możliwe? A w ilu zespół jest powoływany per projekt i rozwiązywany zanim jeszcze zdąży okrzepnąć.

Samoorganizaujacy się zespół to naprawdę wspaniała idea. I w dodatku idea, która bardzo dobrze działa. Ale to jest trudne...

Iteracje

Gdy zapytałem jednego kolegę w trakcie szkolenia, czy nie może odmawiać wykonywania zadań spoza iteracji (wszak Odwaga to jedna z wartości Agile), odpowiedział następująco: "Kiedyś próbowałem, ale mój manager powiedział ::Ok, pośmialiśmy się, a teraz do roboty::".

Iteracje pozwalają na wybranie najistotniejszych rzeczy "na teraz", dostarczenie ich z możliwością używania. Acha, no właśnie: potentially shippable increment - czy Twoi klienci rzeczywiście używają funkcjonalności w swojej pracy, od razu gdy im dostarczysz? Czy pracują może "na starym" a "testowy" używają do poklikania?
Albo jak często zdarzają się wrzutki w trakcie iteracji i co one powodują? Jak bardzo można skrócić iteracje, aby być bardziej responsywnym? Na ile można je skracać, zanim się okaże, że testy, testy regresji itd. są zbyt kosztowne przy tak krótkich iteracjach?

Praca w zamkniętych iteracjach jest świetna. W dodatku to naprawdę działa w niektórych organizacjach. Ale to jest trudne...

Dlaczego trudny?

Dlatego, że wymaga dość dużych zmian organizacyjnych, nie mówiąc już zmianie w sposobie myślenia. Scrum daje gotowy framework, który należy zaaplikować. A co ze skalowaniem? Tak, wiem, że wymyślono dobrze brzmiące nazwy. Ale skalowanie Scruma jest wciąż w powijakach. Czasem w ogóle się nie udaje i Scrum jest tylko z nazwy, czasem udaje się wystarczająco dobrze z pewną pomocą Prince2 albo PMI, a czasem udaje się znakomicie. Tak, są organizacje, którym udało się przeskalować Scruma. Ale to jest trudne...

Zmiany organizacyjne są długie, kosztowne i mogą się nie udać. Tak jak napisałem, Scrum jest naprawdę super, ale często okazuje się zbyt trudny do wdrożenia z zachowaniem oczekiwanych rezultatów.

A może Lean?. Nie chcę przypinać się do konkretnej implementacji Lean w wytwarzaniu oprogramowania, więc piszę po prostu Lean.
Punktem skupienia Lean jest optymalizacja procesu dostarczania, nie gotowy proces do wdrożenia, lecz jego optymalizowanie. Wychodzi nam, że dużo łatwiej zespołowi przestawić się na Lean. Ok, zespół jest również ważny, ale skupienie się na procesie dostarczania, pozwala jakoś żyć gdy zespół jednak trudno się samozorganizuje. Zazwyczaj pierwszym kluczowym krokiem jest przekonanie zainteresowanych do zredukowania WIP i coś już zaczyna działać. Gwoli wyjaśnienia: Lean nie jest oczywiście remedium na całe zło, ale po prostu start jest łatwiejszy niż ze Scrumem.

Koder kodzi, architekt architekci

Na 4Developers odbył się Panel dyskusyjny nt. architektury, architektów i architekcenia:). Trudno powiedzieć, żebyśmy udzielili odpowiedzi na jakieś konkretne pytania, ale było miło. Chociaż padało pytanie o rolę/stanowisko architekta i jego miejsce w procesie, to wydaje mi się, że byłem odosobniony w zdaniu, że bez tradycyjnego architekta można się obejść. Podłapałem tę myśl od Scotta Amblera i po moich doświadczeniach z różnymi zespołami jestem przekonany, że to ma sens.

Ankietowałem kiedyś obsesyjnie, architektów (różne stanowiska różnie się się w firmach nazywają i mimo istniejących jakichś tam typologii, każdy nazywa je sobie po swojemu), aby namierzyć, co konkretnie robi osoba określana jako "architekt". Zbiorcze zestawienie przedstawiam poniżej.

Jaki jest Twój zakres obowiązków jako Architekta?

Odpowiadanie na pytania dotyczące struktury systemu Definiowanie interfejsów do/z systemów powiązanych Decydowanie o wykorzystywanej technologii na poziomie systemu Projektowanie deploymentu systemu Decydowanie o organizacji i rozmieszczeniu komponentów? Który kod umieszczany jest w bibliotekach, programach, gdzie są zewnętrzne biblioteki, co jest ładowane statycznie co dynamicznie? Utrzymywanie dokumentacji dotyczącej architektury system Zdefiniowanie struktury dokumentacji Określenie, które domeny biorą udział w danej funkcjonalności (co zapisują, co trzeba odczytać), jakie nowe interfejsy trzeba udostępnić, a jakie zmienić Prowadzenie prac R&D

Z jakimi pytaniami należy zwracać się do Architekta?

Ja ma odbywać się interakcja pomiędzy modułami/częściami systemu? Jakiej technologii najlepiej jest użyć do dostępu do bazy danych? Jak zabezpieczać pliki konfiguracyjne w systemie/aplikacji? Jaki model konfiguracji serwerów (np. Tomcat) przyjąć dla produktów/aplikacji webowych? Jak należy definiować zewnętrzne interfejsy systemu? Jakie elementy systemu i według jakich kryteriów mają podlegać walidacji? Jakie są główne komponenty systemu? Czy wymiana danej technologii mogłaby wspomóc działanie systemu? Jakich zmian wymagać będzie wprowadzenie danej funkcjonalności? Jak wygląda flow w danym komponencie (np. przetworzenie wiadomości w kolejce)? Jakie są wymagania funkcjonalne dla danego produktu Jak konkretny proces biznesowy realizowany jest w architekturze? Jak wygląda zużycie zasobów sprzętowych i programowych w danym okresie czasu? Jakie narzędzia i skrypty należy wdrożyć, aby usprawnić proces wytwarzania oprogramowania? Jak zorganizowana jest infrastruktura sprzętowa (jakie hosty? jak są powiązane?) i programowa (jakie wersje? gdzie?) systemu?

Z jakimi pytaniami NIE należy zwracać się do architekta?

Czy ta funkcjonalność działa poprawnie? Jakie projekty idą na najbliższy realese? Jaki będzie koszt projektu X? Jak działa ta funkcjonalność? Jak z korzystać z tego pakietu/biblioteki? Do jakich zadań planowany jest Pan X? Kiedy wypada deadline testów systemowych Jaki algorytm wykorzystać do…? Czy następujące zachowanie systemu jest poprawne?

Jeśli popatrzeć na wymienione obowiązki, to trudno oprzeć się wrażeniu, że z niemal wszystkimi z nich może sobie poradzić zespół jako taki i nie potrzeba do tego wydzielonego architekta. Jedyna różnica między w/w architektem a "zwykłym" programistą jest taka, że ma on architekt większe doświadczenie (ale nie to mierzone w latach) i większą wiedzę o systemie.

Wydaje się, że potrzeba powołania osoby w randze architekta wynika z potrzeby rozwiązania następujących problemów:

• niedostateczne komunikowanie architektury w zespole i pomiędzy zespołami
• brak nazwanego procesu rozwoju architektury działającego obok procesu dostarczania; o tym procesie pisaliśmy/mówiliśmy w Ewolucyjna architektura: Jak zorganizować proces rozwoju architektury?
, Ewolucyjna architektura, Ewolucyjna architektura
• Brak użytecznej (nie wciąganej z kodu przez EA) dokumentacji architektury; o tym pisaliśmy nieco w Dokumentowanie architektury, Dokumentowanie architektury cz.2

Można odnosić wrażenie, że tego typu architekt został wymyślony po to, aby wyousourcować w/w problemy. Sęk w tym, że staje się on wąskim gardłem procesu. Po prostu nie nadąża z pracą. Wtedy trzeba powołać kolejnego i kolejnego i kolejnego. Po pewnym czasie okazuje się, że architekci zajmują się głównie sprawami organizacyjno-konfiguracyjno-spotkaniowymi, a programiści przestają czuć się odpowiedzialni za architekturę, gdyż ta "należy" do architektów. I wtedy koder zaczyna kodzić, architekt zaczyna architekcić, a architektura zaczyna dryfować.

Kiedy misja, wizja, wartości działają na szkodę architektury?

Misja, wizja, wartości to jedne tych narzędzi, w których lubują się organizacje za radą modnych strategii zarządzania. Pisaliśmy o tym w kontekście zespołu w artykule Brakujący 1% – Zarządzanie zaangażowaniem programistów. Dla przypomnienia, krótka tabelka, co jest czym i o co chodzi. Dla ustalenia uwagi posłużę się przykładem portalu, który znalazłem w sieci po wpisaniu "misja, wizja". Jest to portal studentmed.pl (btw: nigdy nie miałem kontaktów zawodowych z tym portalem)

Wizja	Jak wyobrażamy sobie świat z perspektywy biznesu, w którym działamy	Za 6 lat każdy student w Trójmieście objęty będzie kompleksową i bezpłatną opieką medyczną w STUDENT-MED
Misja	Jaka jest nasza rola w urzeczywistnieniu naszej wizji?	(...) przynoszenie ulgi w cierpieniu i chorobie w dogodnym dla Studenta czasie. Zapewniamy pełną opiekę medyczną – nie tracisz czasu na bieganie między różnymi przychodniami (...)
Wartości	Co musimy stawiać na pierwszym miejscu, aby realizować naszą misję?	Zdrowie, czas, spełnianie oczekiwań, pozytywne relacje, profesjonalne usługi, dobro pacjenta, wygoda pacjenta
Zasady	Tego na studentmed.pl nie ma. Chodzi o operacjonalizację wartości, czyli co konkretnie mamy robić, aby w/w wartości realizować w naszej pracy?	Tu wymyślam: Umawiamy pacjenta zawsze na konkretną godzinę, a czas oczekiwania wynosi max. 10 min., Nasi pracownicy prowadzą krótkie small talks z pacjentami, Wstępny wywiad prowadzimy telefonicznie, być może uda się postawić wstępną diagnozę, bez konieczności stawienia się w przychodni

Podobne sformułowania stosowane są również softwarehousach i organizacjach mających w swoich strukturach zespoły programistyczne. Jeśli rozejrzysz się po korytarzu w swoim miejscu pracy, to z pewnością zauważysz kolorowe plakaty z wartościami Twojej organizacji. Być może nawet masz je na wygaszaczu ekranu...

Koledzy, z którymi rozmawiam, często nie traktują tego zbyt poważanie, żartują sobie z tego wewnętrznego PR, ale jako osoba z zewnątrz muszę przyznać, że to działa. Ludzie tym przesiąkają zwłaszcza wtedy, gdy wartości są konsekwentnie komunikowane. Gdy otrzymuję zlecenie zawiązania zespołu i pracujemy nad wspólnymi wartościami, to niepostrzeżenie w tym, co wypracowują uczestnicy pojawiają się komunikowane wartości organizacji. Tak więc ludzie tym przesiąkają na wskroś i zaczynają zgodnie z wartościami działać.

Sławomir Lachowski, twórca pewnego banku, miał następującą recepturę na sukces: rekrutuj ludzi, szkól ich, zaufaj im. Szczególną wagę przykładał do rekrutacji. Stawiał na rekrutację tylko tych ludzi, którzy pasują do organizacji. W swojej książce Droga ważniejsza niż cel napisał, że ludziom którzy popełnią błąd zawsze trzeba dać drugą szansę. Jednak z ludźmi, którzy nie wyznają wartości organizacji należy się rozstać. W ten sposób, po pewnym czasie organizacja skupia programistów, którzy w jakimś zakresie utożsamiają się z wizją, misją i wartościami organizacji oraz postępują zgodnie z wyznaczonymi Zasadami.

Co z tego wynika dla architektury?

Kłopoty zaczynają się wtedy, gdy wśród wartości pojawiają się sformułowania w stylu:

• Zadowolenie klienta jest zawsze na pierwszym miejscu
• Nigdy nie pozwalaj klientowi czekać
• Klient jest najważniejszy
• Spełniamy marzenia klienta

Same sformułowania wyglądają super i pozornie mają sens na kapitalistycznym rynku, wszak klient nasz pan. Sęk w tym, co robią zespoły wyznające podobne wartości i do czego to doprowadza. Na rysunku znajduje się diagram RCA, w którym wyszedłem od problemu ze złą jakością kodu. Okazało się, że jej skutkiem jest to, że klienci od nas odchodzą, a powodem to, że Zadowolenie klienta jest zawsze na pierwszym miejscu. Hmmm...czy to nie sprzeczność? Nie, to po prostu kaskada skutków i przyczyn, które zainicjowane wartościami, działają w organizacji.

W/w wartości lokalnie mają sens, lecz jednocześnie działają antysystemowo. W szerszym kontekście i w dłuższej perspektywie mogą doprowadzać do pogarszania tego, co zamiarowały poprawić.

Co z tego wynika?

Choćby to: dobieraj wartości tak, aby wspierały działanie całego systemu (organizacji) oraz analizuj systemowy wpływ misji, wizji, wartości, zasad na to co robią i wytwarzają zespoły.

No i na koniec: co w zamian? Jakie wartości będą miały bardziej pozytywne systemowo działanie niż wymienione. Celowałbym w następujące rzeczy:

• zamiast "klient" promować nastawienie na "klienci; być może skupi to uwagę na takim zorganizowaniu zespołów, aby brać pod uwagę "całość" klientów, a nie tylko tego "na teraz"
• zamiast nastawienia na "zadowolenie klienta" promować "skupiamy maksymalny wysiłek na tym co jest najważniejsze"; być może zbuduje to przyzwolenie na limitowanie WIP
• zamiast nastawienia na "klienta" promować "skupiamy najwięcej uwagi na najważniejszych klientach"; sad but true, szacowanie klientów to normalka i nie ma się czego wstydzić
• zamiast "spełnianie marzeń klientów" promować "odnajdujemy to, co przynosi naszym klientom największą korzyść"; ponownie skupienie na priorytetach

Wiedza odpływa z organizacji

Nie wiem, czy kryzys rzeczywiście był, czy go nie było, ale widzę skutki plotek o kryzysie. Departamenty IT dostały bana na zwiększanie kosztów stałych, czyli na zatrudnianie programistów. Backlog rzadko kiedy się skurczył, więc aby sprostać wymaganiom biznesu zastosowano najbardziej narzucające się rozwiązanie outsourcing.

Outsourcing jest ok, bo nie zwiększa kosztów stałych organizacji, lecz powiększa koszty projektów i jako taki jest widoczny w innej kolumnie arkusza kalkulacyjnego. W skutek tego "finansowego" zabiegu niby mamy programistów, ale ich nie mamy. Proste? :) No, na tym poziomie abstrakcji, to wszystko wydaje się proste i korzystne. Przyjrzyjmy się implementation details.

Skąd organizacja outsourcuje programistów? Ano od ousourcera, tylko że nie nazywają się już oni programistami lecz konsultantami i kosztują odpowiednio więcej. Excelowa kolumna kosztów projektu jest bardziej elastyczna niż kolumna kosztów stałych, więc w czym problem? W tym, że taki outsourcing ma swoje zasady:

• Konsultanci wykonują większość prac programistycznych
• Etatowi programiści nadzorują pracę konsultantów
• Jeśli dla konsultanta przez pewien czas (np. tydzień) nie można znaleźć zajęcia to trzeba go zwrócić do puli
• Konsultanci działają na zasadzie stateless, więc jeśli znów potrzebujemy konsultanta, to dostajemy nie poprzednio zwróconego, lecz pierwszego wolnego

W skutek w/w praktyk etatowi programiści przestają programować, a zaczynają "zarządzać". Właściwie to ich główne zadania polegają na:

• przyuczaniu konsultantów i nadzorowaniu ich pracy
• routowaniu maili między biznesem a konsultantami i ew. zewnętrznymi podwykonawcami
• przygotowywaniu dokumentacji wynikającej z procedur organizacyjnych, których początki są tak stare, że chyba już skamieniały
• analizowaniu logów systemowych, gdy coś się wywali

Gdy przez dwa i więcej miesięcy nie rozwijasz kodu systemu, nad którym pracujesz, to zagadnienia, które wcześniej były oczywiste powoli zasnuwa mgła niepamięci. Dzień po dniu niepostrzeżenie zaczynasz wkraczać na orbitę około systemową z perspektywy której hurtownia danych i hurtowania makaronów to prawie jedno i to samo. Wszak i to i to jest hurtownią.

Utrzymujący się taki stan rzeczy ma następujące skutki:

• Konkretna wiedza systemie, jego architekturze, problemach w kodzie migruje od programistów etatowych do konsultantów
• Rotacja konsultantów sprawia, że wiedza techniczna w ogóle odpływa z organizacji
• Nikt nie jest odpowiedzialny za rozwój architektury, która zaczyna dryfować
• Dla podkreślenia: nie, etatowi programiści nie zajmują się architekturą (choćby nawet takie były początkowe ustalenia) bo niby co to oznacza? rysowanie umli? etatowi programiści zajmują się organizowaniem zajęcia dla konsultantów
• Jakość kodu zaczyna się dramatycznie obniżać
• Dryfowanie architektury sprawia, że z każdą funkcjonalnością coraz trudniej dodawać nowe i modyfikować istniejące
• W pewnym momencie pojawia się osobliwość, czyli taki moment, w których za pomocą metod inżynierskich, architektury nie da się już naprawić; o czym pisałem trochę tutaj

Nie oddawaj core własnego biznesu

Z perspektywy organizacji, która nie jest softwarehousem takie postępowanie ma sens. Tworzenie oprogramowania nie jest core biznesu, więc spokojnie można je oddać komuś do podwykonania. Mam jednak wrażanie, że próbuje się z jednej strony mieć marchewkę i zjeść marchewkę. Z jednej strony chcemy sami tworzyć soft, aby móc go dostosowywać i być elastycznym (kolejne po "architektura") słowo-wytrych. Z drugiej strony chcemy outsourcować, aby zapłacić za to jak najmniej. Ostatecznie wydatkujemy więcej za kiepski produkt.

Przeciwdziałanie

Można przeciwdziałać odpływowi wiedzy z organizacji przestrzegając pewnych zasad. Oczywiście nie jest to tak banalne jak poniższe sformułowania. Najtrudniejsze jest przecież wdrożenie i konsekwentne trzymanie się n/w wytycznych. O następujących rzeczach warto jednak pamiętać:

• zatrudniaj konsultantów na długo i nie zwracaj ich do puli, gdy przez kilka dni nie mają nic do roboty
• dbaj, aby konsultantów było nie więcej niż etatowych programistów
• etatowi programiści pełnią tymczasowe role teamliderów w miniprojektach powoływanych na wdrożenie konkretnych funkcjonalności
• teamliderzy implementują jakąś część ticketów (tak, wiem, że kiedyś twierdziłem inaczej, ale złagodziłem nieco to zdanie
• dbaj, aby działał nazwany proces rozwoju architektury, czyli podczas dostarczania, można realizować itemy techniczne

Ostatecznie idealnym rozwiązaniem jest wyodrębnienie core domain i w jej rozwój zaangażowanie etatowców, a supporting domains oddanie do konsultantów bądź podwykonawców. W tym przypadku, prócz samej analizy może pojawić pewien NP-trudny problem: core domain nie ma albo nie istnieje ona w takiej postaci, aby wymagała by prac programistycznych. Słowem nie ma sensu utrzymywać zespołu programistycznego. Ups! Przymierzam się do wpisu nt. analizy domen, chwilowo godzina jest zbyt późna:)

Jak radzić sobie z błędami ludzkimi?

Ostatnio na grupie WJUG pojawił się wątek Jak zmienić człowieka?, w którym do pewnego momentu dyskutowano o programiście, który nie trzyma się standardów zespołu. Potem, jak to na forach bywa, dyskusja zahaczyła o tematy metafizyczne, by po jakimś czasie odbić w kierunku swobodnych skojarzeń z tematem.

Choć jestem zdania, że lepiej (taniej) nie zmieniać ludzi, a zamiast tego zatrudniać właściwych, to pozwoliłem sobie pominąć dominującą w wątku myśl jak właściwie znaleźć konsensus, aby nie wylać programisty z kąpielą i zastanowiłem się nad pytaniem: Jak radzić sobie z osobami, które masz już w zespole i według Ciebie nie działają tak, jakbyś tego oczekiwał. Na przykład popełniają błędy, których nie akceptujesz. Oczywiście takie rzeczy zdarzają się każdemu, ale przypuśćmy, że akurat u tej osoby charakterystyka błędów mocno odbiega od dopuszczalnej.

Współpraca z ludźmi, to zawiła sztuka i konkretne sposoby postępowania nie są remedium na wszystko, aczkolwiek poniższe pomysły mogą pomóc.

Sklasyfikuj błędy

Dowolną ilość czasu możesz spędzić dyskutując, czy ktoś popełnił błąd, czy nie. Dlatego, prócz standardowych zasad definiowanych dla zespołu, proponuję od razu wprowadzić pewną klasyfikację błędów i określić sposoby postępowania na wypadek każdego z nich. A zatem mamy błędy:

Przypadkowe	Zdarzają się w wyniku okoliczności, na które mieliśmy znikomy wpływ. Nie mamy pretensji o takie błędy.	Uwidocznij
Wynikające z podjętej decyzji	Programista podjął decyzję i była to błędna decyzja. Dobrze, że ludzie podejmują decyzje. O te błędy też nie mamy pretensji.	Udziel informacji zwrotnej (@see poniżej)
Symptomatyczne	Pojawia się regularnie w podobnych okolicznościach. Nie mamy o niego pretensji, ale coś z nim trzeba zrobić	Zdiagnozuj problem Napraw błąd lokalnie, a następnie przemodeluj proces, aby błąd więcej nie występował podejmij coaching z programistą
Wynikające z zaniedbania	Programista wiedział jak postąpić i tak nie postąpił. Powinien mieć pewną wiedzę, ale jej nie pozyskał. Zrobił coś, lecz od początku było wiadomo, że robić tego nie powinien. O takie błędy mamy pretensje.	Udziel informacji zwrotnej wyciągnij konsekwencje służbowe

Udzielanie informacji zwrotnej

Tak jak pisałem kiedyś w udzielaniu informacji zwrotnej nie chodzi o to, aby na siłę być milusim i też nie o to, aby być chamem. Dla uproszczenia sprawy na początek trzymaj się następujących kroków:

1. Udzielaj informacji zwrotnej wyłącznie w cztery oczy i cztery uszy
2. Przedstaw fakty - fakty, nie twoje oceny; fakty do sformułowania, które odpowiadają na pytania: jak? gdzie? kiedy? z kim? co powiedział? co napisał? co usłyszał? co konkretnie zrobił?; zatem jeśli informacje przekazywane przez Ciebie bardziej odpowiadają na pytania: dlaczego? po co? to nie są to fakty, lecz twoje/czyjeś opinie; lepiej wtedy zakończ spotkanie i na spokojnie spisz fakty na kartce
3. FeedBACK - Przekaż co najmniej cztery informacje zaczynające się od Dobrze zrobiłeś, że...
4. FeedFORWARD - Przekaż tyle ile to konieczne informacji zaczynających się od Następnym razem oczekuję, że...
5. Poproś o podsumowanie, tego co przed chwilą powiedziałeś

Coaching

Większość z nas namiętnie uprawia co najmniej dwa zawody: doradcy i psychologa. Odpuść.
Prowadź coaching tylko, gdy ktoś o to poprosi, albo przynajmniej wyrazi zgodę.
Najprostsze formy "coachingu" to:

• Wysłuchanie - słuchaj i potakuj. Nic nie mów tylko potakuj
• Zadawaj pytania konkretyzujące (jak? w jaki sposób? po czym poznajesz, że?) - Zadawaj pytania i czekaj, aż rozmówca dozna olśnienia
• Zadawaj pytania dlaczego? po co? w jakim celu? - zadawaj tak długo, aż rozmówca dozna olśnienia

I przede wszystkim nie doradzaj i nie oceniaj, bo więcej do Ciebie nie przyjdzie. Jakkolwiek by to nie brzmiało: to co w tym momencie masz do powiedzenia jest absolutnie nieistotne:)

Nadmiar miłych słówek szkodzi

Czy zdarzają się ludzie, którzy nie umieją robić pewnych rzeczy, nie mają wiedzy albo doświadczenia? Pewnie, że się zdarzają. W każdej firmie. Dla ich dobra i dobra ogólnego muszą oczywiście ten stan rzeczy zmienić. I tu się zaczyna irytująca zabawa w konwenanse. Słyszałem już następujące eufemizmy na niekompetencję:

• obszary rozwoju
• rezerwy
• deficyty kompetencyjne
• ograniczenia

Nie mówimy już zatem: Kolego, według zebranych przeze mnie informacji musisz nauczyć się tego i tego oraz zmienić to i to zachowanie, teraz mówimy: Kolego masz fantastyczne rezerwy w tym i w tym. Czy ktoś widział lepszy sposób na ogłupianie ludzi?

Wydaje mi się, że czasem przesadzamy w owczym pędzie za byciem milusińskim. Trzeba wyraźnie powiedzieć, że udzielanie informacji zwrotnej nie polega na byciu miłym. Szok, co? Tak samo jak software craftmanship nie polega na pakowaniu wzorców wszędzie tam, gdzie się da. Tak zwana pozytywna informacja zwrotna nie polega na spijaniu sobie z dzióbków. Pozytywna oznacza to, że informowany osobnik wie dokładnie jakich zachowań się od niego oczekuje. Czyli nie mówisz Kolego, nie potrafisz pisać czystego kodu. Dziękuję, lecz analogicznie do przykładu w poprzednim akapicie: Kolego, oczekuję, że Twój kod będzie napisany zgodnie ze standardem spisanym w...

Eufemizmy, miłe słówka blokują rozwój ludzi, bo dają im złudzenie, że wszystko jest w porządku, podczas gdy nie jest. Jeśli więc jesteś szefem i po udzieleniu po raz setny "miłej" informacji zwrotnej zwalniasz programistę, to wiedz o tym, że to ty ponosisz winę za tę sytuację. Dbając o to, by było miło uniemożliwiłeś człowiekowi poprawę.
Rozwój to proces przechodzenia przez fazy komfortu i dyskomfortu. Jeśli zawsze jest ok, to rozwoju nie ma.

Żeby nie przegiąć w drugą stronę. W/w nie oznacza bycia "nie miłym", nie oznacza złośliwości i braku delikatności. W/w oznacza przede wszystkim bycie rzeczowym, mówienie wprost, odnoszenie się do rzeczy a nie do osoby i troskę o ludzie.

Gdy programista zostaje liderem

Napisano już tony książek na temat leadershipu i efektywności, które z pewnością masz gdzieś na dysku. Nie będę się więc silił na sformułowanie ogólnych zasad do wszystkiego, bo albo ktoś to już zrobił albo takowe nie istnieją :) Mam jednak parę spostrzeżeń na temat, tego o czym warto pamiętać, gdy do tej pory byłeś przede wszystkim programistą, a teraz zostałeś liderem programistów.

1. Akcja powoduje reakcję

Bywa, że programista zostający liderem, w przypływie entuzjazmu zaczyna mylić proaktywność z hiperaktywnością. Często myśli sobie: "do tej pory znosiłem ten kod, ale teraz wszystko się zmieni" i zaczyna zmieniać.

Sęk w tym, że każde rozpoczęte działanie, co jakiś czas "domaga się uwagi". Jeśli komuś coś zlecisz, to w końcu przyjdzie on z jakimś pytaniem na temat zadania. Im więcej działań rozpoczniesz, tym więcej aktywności będziesz musiał później podejmować - wykładniczo więcej. Świeżo upieczony lider, próbuje wprowadzić zmiany zakładając, że zmiana jest to proste przeprowadzenie stanu aktualnego w stan docelowy. Tymczasem jest to nieco bardziej złożone. Model wprowadzania zmiany podobny jest do tego przedstawionego na rysunku (w tym poście tylko skrótowo). Zainicjowanie zmiany to tylko początek, po jakimś czasie przychodzi kryzys, przez który należy zespół przeprowadzić. Bez aktywności lidera, zespół wróci do stanu początkowego, gdyż wtedy "jest źle, ale przynajmniej wiemy co trzeba robić". Z tego względu początkowa hiperaktywność prowokuje zbyt wiele kryzysów w zespole. Lider nie jest w stanie ogarnąć wszystkich i zmiana się nie udaje. Młody lider ma zazwyczaj wyrzuty sumienia. Myśli, że się nie nadaje do nowej roli i chce znów być programistą (@see kryzys w zmianie). Problem zazwyczaj nie tkwi w konkretnej osobie, lecz w niewłaściwym działaniu. Zacznij więc od wprowadzenia jednej zmiany, a gdy się ustabilizuje, pomyśl o kolejnych. Zanim zaczniesz jednak zmieniać, zastanów się co? i po co?.

2. Naucz się rezygnować

Tak to już jest, że najchętniej lubimy robić rzeczy, które nam wychodzą. Jeśli jesteś świetnym programistą i uczysz się jak być liderem, to będziesz często odczuwać pokusę, aby osobiście implementować zadania, z którymi nie mogą poradzić sobie programiści albo będziesz przydzielał sobie tyle samo zadań programistycznych co do tej pory. O tym, czy lider zespołu powinien programować i jak to godzić z zadaniami wynikającymi z roli lidera toczy się wiele dyskusji i jest wiele podejść do tego zagadnienia. Ja jestem przekonany co do jednego: niezależnie od tego, czy programujesz, czy nie Twoja optyka powinna być zawsze nakierowana na zespół. Twój sukces nie oznacza już sukcesu indywidualnego, lecz wprost zależy on od sukcesu zespołu, któremu przewodzisz. Możesz mieć co do tego pewne obawy, więc napiszę o nich wprost. Tak, nie będziesz programować tyle, co do tej pory. Tak, będą okresy, że nie będziesz programował w ogóle. Tak, możesz przestać być na czasie z nowinkami technologicznymi. Tak, szczegółowe zagadnienia dotyczące technologii, frameworków, mogą zacząć blaknąć w Twojej pamięci. Nie, nie zapomnisz jak się programuje. Tak, zaczniesz zauważać, że pewne klasy problemów rozwiązuje się w podobny sposób. Tak, jeśli wprowadzisz proces wymiany wiedzy, będziesz korzystał z wiedzy i doświadczenia programistów, aby na ogólnym poziomie być zorientowanym w temacie. Tak, będziesz zauważał, że niektórzy programiści popełniają błędy podobne do tych, które ty popełniałeś. Tak, rozwijanie umiejętności innych jest równie fascynujące jak rozwijanie własnych.

3. Nawyki są ważniejsze niż cele

Żyjemy w obsesji celów. Na każdej rozmowie rekrutacyjnej pytają o największe osiągnięte cele i porażki. Cele same w sobie są nudne. Większość z nas posiada umiejętność "spięcia się w sobie" i osiągnięcia jakiegoś tam celu. Jest jednak coś ważniejszego niż cele - nawyki. Gdyby nawyki i cele położyć na szali, to relacja między nimi jest taka, jak relacja między wartościami po prawej i po lewej stronie w Manifeście Agile. Czyli: wiemy, że cele są ważne i doceniamy je, lecz nawyki cenimy bardziej. Ironia polega na tym, że osiąganie celów bez nawyków (czyli jednorazowe pospolite ruszenie) może być męczarnią. Ale dzięki nawykom cele osiągają same. Jaki z tego pożytek dla lidera programistów? Ano, na przykład taki:

• nie zmuszaj ludzi, aby wymienili się wiedzą i za dwa miesiące byli zespołem cross-functional (jak to zmierzyć?), zamiast tego wprowadź zwyczaj regularnych (dobrze określonych w czasie) spotkań i dyskusji na tematy techniczne
• nie baw się w strażnika, który zagania ludzi do pracy, zamiast tego rób codzienne stand-up meetings
• nie ogłaszaj, że za pół roku system ma być zrefaktoryzowany w całości, zamiast tego wprowadź zwyczaj code review.

4. Wielkie problemy biorą się z małych zaniedbań

Nie chodzi o pedantyzm graniczący z obsesją. Chodzi o świadomość, że nasze działanie to niezliczone ilości ciągów przyczynowo-skutkowych, a końcowy skutek może stać się przyczyną dla kolejnych ciągów przyczynowo-skutkowych. Zupełnie jak to domino. Kiedyś napisałem wpis o refaktoryzacji "Myjcie swoje kubki", w którym chodziło o to, że lepiej regularnie robić drobne refaktoringi (@see nawyk), niż raz na jakiś czas wybebeszać pół systemu (tak, wiem, czasem jest to nieuniknione). Z perspektywy lidera jest podobnie. Jeśli coś Ci się w funkcjonowaniu zespołu rozstraja, reaguj od razu. Nie zwlekaj do momentu, aż drobny kłopot stanie się przyczyną kolejnego ciągu, i kolejnego, i kolejnego, aż możliwość reakcji przekroczy Twój zakres kompetencji.

5. Wielkie osiągnięcia biorą się z małych ulepszeń

Lider często ma marzenie, aby poustawiać wszystko tak, aby było dobrze i niech to to tak już zawsze działa. Po pierwsze nie ma żadnego "dobrze" i nie ma żadnego "na zawsze". Próba zorganizowania pracy zespołu tak, aby potrafił wykonać każde zadanie przypomina trochę implementowanie superelastycznych rozwiązań "na wszelki wypadek". Rzeczywistość tak niestety nie funkcjonuje, co nie oznacza, że jesteś tu bezradny. Pilnuj dwóch głównych zasad:

1. Szybko rozwiązuj problemy lokalnie
2. Lokalne rozwiązania standaryzuj tak, aby stały się częścią całego procesu

6. Wprowadzaj FRAMEworks i workFLOWs

(Nie mówimy teraz o bibliotekach programistycznych) Główną perspektywą patrzenia na zespół są procesy w nim działające. Słowa "framework" i "workflow", których częścią jest słowo "work" elegancko oddają, jak lider powinien organizować ową "work" w zespole. Przede wszystkim dla pracy powinien być zdefiniowany "frame". Ludzie muszą widzieć, że coś się dzieje według jakiegoś schematu. Na przykład tablica scrumowa nadaje "frame" pracy zespłu - "coś (karteczka) gdzieś musi się znaleźć (tablica), to coś na jakiejś podstawie (definition of done) przechodzi do kolejnego etapu (done), itd". Ludzie wiedzą: co mają zrobić, jak mają robić i kiedy skończyli.
Drugie słowo uwypukla "flow" procesu. Proces ma być płynny, bez zbędnych przestojów, bez zatorów, z optymalną ilością wykonywanej pracy. Na przykład "flow" w Scrumie stymulowane jest poprzez narzucenie stałych iteracji, mierzenie prędkości zespołu, nacisk na regularność, rytm, szybki feedback.

7. Działa tylko to, co robisz

Na koniec najcenniejsze, ale jak to zazwyczaj bywa - najbardziej oczywiste spostrzeżenie - żeby coś zadziałało, musisz to robić. Zadziwiające, że czasem gdy pracuję z zespołem omawiamy konkretne techniki, to wszyscy kiwają głowami - tak to jest ok, to jest ważne, a potem nikt nic nie robi i jednocześnie wszyscy są przekonani, że nie działa. Entuzjazm po szkoleniu trwa jakiś tydzień, potem się kończy i często kończy się noworozpoczęte działanie (@see kryzys w zmianie). Pamiętaj, konkretne techniki działają jeśli je robisz. Jeśli ich nie robisz, nie będą działać. Na przykład Daily Scrum. Zespoły, często robią, potem trochę im się spotkania przeciągają, czasem spotkanie odwołają, a w końcu stwierdzają, że wystarczy jedno w miesiącu. Jednocześnie wszyscy mają miliony racjonalizacji dlaczego to jest ok. Owszem, powody są nieraz ważkie, ale powiedzmy jasno: nie, nie, nie i jeszcze raz nie. W ten sposób Daily Scrum nie będzie działał. I to nie Scrum jest zły, tylko ktoś przed zastosowaniem nie przeczytał ulotki i teraz jest zaskoczony, że pojawiły się skutki uboczne. Myśl długo nad wprowadzeniem danej praktyki do zespołu, ale jeśli już wprowadzisz, to konsekwentnie ją kontynuuj i daj jej szansę zadziałać.