First a disclaimer: I’m describing here (yet another) method that uses “group wisdom” to bring order to a set of things to be done. There’s time and place for methods like this as there are times and places for a more structured approach. Neither is a silver bullet and your mileage may will vary :)
Now, down to business…
Suppose you have a bunch of (work) items to prioritize with respect to when you should start working on them. They don’t necessarily need to be user stories, could be on different levels of detail like an initial “shopping list” of everything that you want to have done eventually.
Now pick a random item and put it in somewhere around the middle of the future column.
Let them work and don’t be afraid of long pauses and silence until either:
I’ve tried it today, on a hunch, first time ever with a newly formed team trying to work with an initial “shopping list” of stuff the project should deliver. It worked really well.
I didn’t stick 100% to the rules described above. Once I’ve noticed it is working and most of the items were prioritized I’ve let them add to the initial list, split items etc. but still killed all discussions until all the items were sorted. Once they were sorted there was no need for discussion :)
Basically, the silent part worked exactly as with grouping on an affinity diagram: it took surprisingly little time and we completely avoided diving into details unless it was really a contentious point. Given that the mechanism worked so similarily I bet it should work in principle. I’m definitely going to use it in the future.
I doubt it will work as an excercise when sorting an artificial list that people are not invested in.
Edit: I’ve tried it again with a different team—it worked :)
This time we have encountered the back and forth item swapping early in the process. Each time we noticed that we marked the pairs and parked them to revisit once the rest has been prioritized. The subsequent discussions were short and, in essence, were about more precise understanding of the wording (scope, really) or splitting the item into phases which then were easy to fit between other items.
If you are an agile coach contemplating on taking a particular job or a manager trying to breathe some motivation into your people, take a good and honest look whether the organization fundamentally trusts the employees. If not, you are probably going to waste your time and/or money.
Some time ago I had a rather spirited conversation with an eminent gentleman in charge of a software company. His company operates in a very particular niche is doing fairly well financially: the business is stable, probably no cash-flow problems, generally no stress—at least in comparison with other companies in the business of writing software for others so we were talking about employee motivation and retention.
Prior to owning his own company this gentleman has a history of work at a renown university and a bunch of large companies of which the McKinsey & Co. serves him as an example of a company culture delivering excellent results. And when we dove into what that meant the discussion got spirited.
The discussion took quite a while and I’m not sure I was able to get my arguments across—I was going for Pink’s mastery, autonomy and purpose triangle—but it certainly left me thinking and made me realize something rather fundamental.
When you go through any literature about “the new way of shaping the company culture” it, roughly, prescribes the same cure: empower the people and give them responsibility, purpose, praise and sense of achievement. What I haven’t seen anywhere explicitly stated is that before any of the above can be done you must simply trust them.
If you and me have ever talked (because I don’t think I’ve ever written that) you might have heard me mentioning something similar: that all the agile ideas are based on an assumption that you have hired the right people. People who actually do want to work for you, are not stupid, terribly lazy or dishonest. But I was wrong, it is not the correct assumption.
The real assumption is whether you trust that your people do want to work for you, are not stupid, terribly lazy or dishonest and whether you treat them in such a way.
This is where your corporate background or reality may hinder your most honest efforts to bring the creativity and motivation out of them.
Many corporations have this very weird split personality disorder and hire “passionate, self-motivated people who help them shaping a better future for the company and the whole world” but only have unscrupulous employees whose every hour in the office must be strictly recorded, every pen and sheet of paper accounted for and every task supervised and approved. How come that a simple act of signing an employment agreement transforms them from the first kind to the latter? And the greatest showstopper is that these organisations often don’t see this discrepancy. They want their employees to be creative because that’s the essence of their jobs yet manage them as Taylor would on a 19th century boring and repetitive production line.
So, if you really want to change your organization take a good and honest look at the trust issue. If it is lacking you are in for a long fight. I believe it can be won but it will not be easy and if you just implement new mechanisms and methodologies without addressing the underlying presumptions (or are they assumptions?) the chance of making a lasting change is, in my opinion, zero.
]]>Here’s an actual case I’ve heard about very recently:
I’m a proponent of agile approach over strict adherence to one methodology or the other so I don’t think there is anything wrong with this approach. The team have been developing and improving their way of working over a year and a half and reportedly arrived at a solution that was working fine. They have achieved the right balance between being responsive and having the time to keep working on their own projects—which was the major problem they were addressing throughout their agile journey—and overall it sounded like a success story. The only thing that kept nagging me was why, the hell, they were still having these planning sessions. Their progress on their products (the internal tools) was not tracked by the rest of the organization which seemed to care much more about their responsiveness. In my experience the planning session could be long and sometimes painful and they certainly didn’t need it to keep the responsiveness up, Kanban does not require it… I couldn’t let go of this question and approached the guy after the talk and asked.
I suspected that the planning sessions were just a left over form their Scrum days but, to my surprise, they were not and the guy actually knew exactly why they were left in place. It was a way for the team to be able to “smuggle in” certain items they wanted to work on even if the rest of the organization didn’t think it was important enough to bubble all the way to the top of the backlog. The situation was that all the requests that came from the other teams were marked by them as “must have” while the items pertaining to the tools the team was working about were all marked “nice to have” by the team itself. The problem was that a) the team knew that not all the backlog requests were really a must, and b) the team knew that working on the incoming requests only was deadening like hell and they would not be able to sustain it for longer than an iteration or two in a row so by at the beginning of the sprint they were picking from the backlog whatever combination looked fine at the time and, as Scrum suggests, refused to change it later on. Or not since some of the incoming requests were truly urgent and would be inserted into the sprint backlog anyway… making 60–70% of the tasks for any given sprint.
So, after we have discussed for a while what was really happening we figured out that the team was actually, although unconsciously, mudding the process of prioritizing work to be done just to feel better. Again, I’d say that’s not necessarily a problem as long as the result is fine but by doing it in this inconspicuous way the team have deprived itself of having an important aspect of their operation to consciously control and fine-tune.
It seems that the real problem at hand is a thorough prioritization of tasks. And by thorough I mean one that takes all important aspects into consideration, not only the urgency and importance as perceived by the “client” but also including team perspective since it is really important. Stick to clients opinion only and you will have a burned out (or worse: empty) team on your hands. And on the client’s hand too, by the way, so it is in no one’s interest. So if you know that there certain aspects that keep the team motivated, productive and sane bring them out to the light, inspect and deal with transparently. You don’t have do advertise it outside the team but on the inside you should act upon them consciously. Only when you manage transparently you have a chance to act when things don’t work anymore.
]]>At first I found it interesting and a fitting counterexample to an ”industrial goal” that can be achieved in a predictable and repeatable way but after some consideration I think it is a wrong approach and it stems from the confusion between means and ends.
I would like very much my ends (a.k.a. goals) to be concrete and never fuzzy, especially in business. Otherwise how am I supposed to know when I have reached them? Or, at least, that I am on the right course—or, in other words, I am using the right means—to have a chance of getting to them? I believe that the goals we set are always ”solid”—as opposed to ”fuzzy”—even if sometmies we don’t realize that conciously. Most often we just don’t take enough time to figure out what we really mean. Let’s take an example: who wants to be unhappy with his or her life? I haven’t met such a person so I can safely assume that all the people I know have a very clear and solid goal: they want to have a happy life. In my book it is not a fuzzy goal at all: it is very conrete and it can be even easily measured but what is fuzzy, especially if one doesn’t reflect on the subject, is the path to this goal.
In business, this is way easier. In business the goal is way easier to define and more often than not it has already been defined before we take on a project. The business must bring money in order to survive, one’s bosses need to be satisfied, one’s subordinates mustn’t be exhausted all of the time, the product must be shipped… What is fuzzy about these goals? Not much. What is unclear in the ”knowledge work” era is what should we do in order to achieve these goals and, clearly, there is no single recipe that will guarantee success in all possible circumstances. Nevertheless there is an approach that will guide us in the general direction of success and it sounds like this:
Figure out your real goals, put a number on them if you can1 and while you are going about your project keep an eye on your goals and frequently check if you are getting closer to them.
Let’s go back to the ”Gamestorming” the book for a moment. They say ”In the knowledge work we need our goals to be fuzzy”—that’s exactly why old-school execs have a problem accepting the ”new way of working”. And from where they look, they are right. We, the ”disruptive” and the ”creative” consistently do not communicate one thing: what our way of working is going to deliver. We say what’s wrong with the old way, and we can prove it on many different planes but the problem is that the old way have worked for years and we have difficult time showing what exactly we will better and prove that it worked after the fact.
1. You really can put a number on (quantify) any goal but that is a subject for a speparate post↩
]]>— Przepraszam, że przeszkadzam ale jestem w rozpaczy. Nasz zespół działa już od trzech miesięcy, nasze sprinty trwają tydzień, staramy się jak możemy i tylko trzy dowieźliśmy na czas i w całości—co robić, Gandalfie?
— Na czym polega problem, młody Esemie?
— Jak to, Gandalfie?
— Słyszałeś mnie dobrze: w czym leży problem?
— Nie rozumiem, Gandalfie. Zespół zobowiązuje się do zadań, stara się jak może ale zwykle na końcu sprintu mamy tylko 80–90% wykonanych zadań.
— W takim razie zobowiązujcie się do 80–90% tego co Wam się wydaje.
— Jak to?
— No dobrze, młody Esemie, pójdźmy po kolei. Tak na marginesie powinniśmy wymyślić jakiś inny tytuł dla Ciebie i Twoich kolegów. Stary Mistrz Tom ma rację, że słowo ,,master” powinno być zarezerwowane dla prawdziwych mistrzów—słyszałeś zapewne o regule dziesięciu tysięcy godzin? Obawiam się jednak, że Ojcowie Założycielowie będą się sprzeciwiać… Taaaak… Gandalf zamyślił się na chwilę. — Ale wróćmy do rzeczy. Powiedz mi młody Esemie czy Wy aby czasem nie szacujecie backlogu w czasie?
— Nie, Gandalfie.
— To dobrze, mój drogi. Powiedz mi zatem dlaczego tak się robi i jaki to ma związek z prędkością zespołu (velocity)?
— No… bo łatwiej jest oszacować wielkość zadania przez porównanie go z innym niż zgadnąć ile czasu zajmie jego wykonanie.
— A prędkość?
— Pokazuje ile tych punktów zrobiliśmy co sprint.
— Mhmm. I…?
— I… to już wszystko, Gandalfie.
— Byłeś na właściwym tropie, młodzieńcze, ale od dojrzenia Sedna odwiodło Cię zaufanie do narzędzi a nie do Idei. Słowa mają swoje znaczenie, które Ci umyka bo zbyt powierzchownie ich używasz. Przypomnij sobie co mówiłeś o szacowaniu. Słusznie powiedziałeś, że szacujemy wielkość zadań, a więc coś co jest cechą danego zadania natomiast w jakim czasie to zadanie jest w do wykonania zależy od tego, kto owo zadanie będzie wykonywał. Alvin Kraenzlein przebiegnie 60 metrów szybciej od Ciebie ale to te same 60 metrów. Czy to dla Ciebie jasne, młodzieńcze?
— Tak, Gandalfie.
— W takim razie, rozwiń to rozumowanie dalej sam.
— Niech się zastanowię… Fakt, że nie kończymy wszystkich zadań w sprincie może wynikać ze złego planowania.
— Może, ale nadal umyka Ci Sedno. Jesteś jednym z moich najinteligentniejszych uczniów i chciałbym abyś patrzył dalej niż sięga Scrum Guide, więc postaraj się bardziej. Jaka była moja pierwsza odpowiedź kiedy tu przyszedłeś?
— ,,Na czym polega problem?”
— Zgadza się, idź tym tropem. Słowa mają znaczenie, zwracałem Ci już na to uwagę!
— Czyli niedowiezienie sprintu nie jest problemem? Ale PO struga mi kołki na głowie!
— Aha… Dlaczego?
— No bo musi mieć ten produkt za dwa miesiące. Oh…!
— Czy dojrzałeś prawdziwy problem?
— Tak, Gandalfie. Teraz widzę, gdzie zbłądziliśmy.
— Zatem wytłumacz. Chcę być pewien, że widzisz Sedno a i Tobie nie zaszkodzi poukładać to w głowie.
— Nie jesteśmy zwinną organizacją. Nasza zwinność kończy się wewnątrz zespołu. Pozwoliliśmy narzucić sobie i zakres i czas trwania projektu a przecież czas trwania zależy od tego jak szybko zespół pracuje. Tego nie da się zgadnąć zawczasu, zwłaszcza, że nigdy jeszcze nie budowaliśmy podobnego produktu.
— Dobrze, mój młody Esemie. Problem, który mi przedstawiłeś niekoniecznie jest problemem zespołu.
— Czyli muszę rozmówić się z PO!
— Znowu nie uważasz! Powiedziałem ,,niekoniecznie”. Być może masz więcej niż jeden problem. Na pewno masz problem z PO ale nie oznacza to, że na pewno dobrze planujecie i nie wiem też czy dobrze i wydajnie pracujecie. Jestem jednak przekonany, że teraz już sobie poradzisz.
Idź i zawsze szukaj Sedna. Wszystko inne to tylko narzędzia ku niemu prowadzące. Jeśli zrozumiesz Sedno poczujesz wolność w ich używaniu, jeśli nie, będziesz ich niewolnikiem.
— Dziękuję, Gandalfie.
— Masz tu jeszcze listę, która pomoże Ci sprawdzić jakie masz problemy. Pamiętaj jednak, że to tylko kolejne narzędzie i nie trać z oczu Sedna. A teraz spadaj—chcę się zdrzemnąć!
]]>So, the news on the radio was that NIK (Polish Supreme Chamber of Control) was investigating the operation of an electronic toll charging system. It consists of a small transponder in a car and a number of toll gates encroaching roads. The idea is that you get billed automatically as you cruise underneath these gates at your regular speed—pretty nice compared to the toll gates on highways. To my surprise the problem under investigation was that if the system could not bill you automatically every gate you pass would trigger an automatic penalty ticket so the charges kept building up to, reportedly, tens of thousands of zlotys for some people.
The official answer from whoever is running this system was that “the gates are conforming to all the regulations and norms and there is no evidence that they…” but the bug, in my opinion, was clearly in software. In retrospect it seems like a stupid omission of one if
statement but if a few people sat together—and a combination of a business owner, a developer and a QA person that Paweł suggests sounds like a really good combination—one of them was likely to come up with such a basic scenario.
So, I believe that writing acceptance tests, test scenarions or whatever we call them forces the business owner to think harder at what exactly he wants to have and this is always a good thing :)
]]>I’ve chosen to focus on the the basics of the “agile way”, starting with the manifesto tuned to non-software world and continuing from there but I had to be more specific as well. So I briefly explained scrum and kanban as two methodologies working in very different ways and repeating over and over again that in the context of these companies it is not the intention to implement either framework as a whole but to pick bits and pieces that look promising. That worked, I hope, but in tha process of explaining this I have realized that maybe there was a better way of approaching this part.
What if I presented a number of initially separate “tricks” that could be used for specific purposes — remember that I thought I would be talking to complete newbies. For example the combination of a product backlog, a product owner and a sprint review as a way to approach communication with a client or a subcontractor? The daily meeting as a way to help communication within the team? Drawing a kanban board as a way to understand what is really going on in the organization? Then, only after explaining this “tricks” separately I would pull them together and show that they can make a complete “system”.
This idea is built on the premise that not only agile methods but also their elements are suposed to be tools that we use as necessary. Of course there are niches where we have tested complete frameworks — like scrum in the software development field is usually a good start — but in the end we should always inspect and adapt which, here’s the kicker, makes all discussions about which agile method is better completely pointless.
So, dear agile experts, what do you think about such approach? Do you subscribe to the “toolbox idea”? Have you ever tried to present it like this?
]]>Z punktu widzenia ,,due dilligence” proces był przeprowadzony wzorowo. Potencjalni dostawcy musieli przede wszystkim pokazać ile z wymaganej funkcjonalności mają już wcześniej zaimplementowaną przy okazji poprzednich projektów, potem przedstawić referencje oraz udowodnić, że bardzo dobrze znają rynek na który wchodzi zlecający. Firmy, które przeszły przez pierwsze sito zostały zaproszone na warsztaty, gdzie zweryfikowano prawdziwość danych z pierwszego etapu i przedyskutowano szczegółowe potrzeby zamawiającego. Biorąc to wszystko pod uwagę oraz oczywiście wycenę kontrakty zostały podpisane i prace ruszyły.
Nie dowiedziałbym się o tym, gdyby nie to, że wynik nie okazał się taki jak zamawiający sobie wyobraził. Główny problem leżał, jak to często bywa, w mało realistycznych oczekiwaniach i planie projektu w kombinacji z mało zwinnym do niego podejściem ale oprócz tego okazało się, że ten wzorowy proces wyboru dostawcy również zawiódł.
Z perspektywy czasu okazało się, że najważniejsze kryterium wyboru mające zaoszczędzić zlecającemu masę czasu i pieniędzy — czyli już gotowa funkcjonalność — okazała się stosunkowo trywialna i ponowne jej zaimplementowanie przez innego dostawcę nie wpływałoby znacząco ani na wycenę ani na czas realizacji a pojawiły się za to problemy w komunikacji z tym wybranym dostawcą.
Komisja przeprowadzająca wybór nie zadała sobie po prostu pytania: ,,Jak nam się będzie z dostawcą współpracować?”. Poznawszy nieco tę firmę nie dziwię się temu bardzo bo firmy nikt nie uświadomił, że jest bardzo trudno napisać kompletną i niesprzeczną specyfikację, że nawet z najlepszym i najuczciwszym podwykonawcą komunikacja potrafi się wykoleić, że różnice kulturowe potrafią być przeszkodą bardzo trudną do zdiagnozowania i naprawienia i, w końcu, że proces wytwarzania oprogramowania jest procesem twórczym a nie mechanicznym i przewidywalnym. Z drugiej jednak strony niezadanie sobie pytania o jakość współpracy przy wyborze strategicznego dostawcy na lata to jednak wpadka. Ja wiem, że to nie jest czynnik łatwo mierzalny i łatwy do ewentualnej obrony przed szefami ale taka decyzja to przecież biznesowe małżeństwo, którego konsekwencje będą trwały lata.
]]>O co chodzi… Zastanawiałem się ostatnio jak nasza przeprowadzka z Holandii do Polski a potem przejście na własną działalność wpłynęło na moje zadowolenie z zawodowej części mojego życia. Jak zwykle nie ma róży bez kolców, wszystko ma swoją cenę itd. więc odpowiedź wyszła mi pozytywna ale nie w stu procentach.
Największym plusem przeprowadzki do Polski jest fakt, że moja praca ma zdecydowanie większe przełożenie na rzeczywistość. Wynika to z różnych cznynników, między innymi z tego, że w Holandii duża część problemów trapiących nas w Polsce jest już rozwiązana a kultura pracy i podejście do pracowników są na zupełnie innym poziomie. Stąd projekty merytorczne mają łatwiejszą drogę do wdrożenia a projekty związane z ludźmi czy zarządzaniem projektami z reguły dotyczą znanych i przepracowanych tematów.
Z kolei odejście z korporacji ma tę niesamowitą zaletę, która codziennie cieszy mnie już ponad pół roku, że pracuję nad tematami, nad którymi chcę pracować, które wydają mi się ważne i/lub ciekawe.
Ceną, którą płacę za te zmiany jest ograniczony kontakt z ciekawymi ludźmi. Nie każdy człowiek jest jednakowo ciekawy, zwłaszcza jeśli ograniczymy się do sfery profesjonalnej, więc praca w miejscu, które jest skupiskiem ciekawych ludzi zwiększa szanse, że na takie osoby się trafi. Philips Research, jak daleko by się nie stoczył od dnia, w którym podjąłem tam pracę, nadal jest pod tym względem jednym z najlepszych miejsc w Europie i od czasu do czasu brakuje mi spotkania z kimś, kto otworzy mi oczy na coś zupełnie nowego lub niespodziewanego. Absolutnie największe na spotkanie interesujących ludzi są są w projektach prowadzonych pomiędzy kilkoma firmami. Zwłaszcza jeśli projekt taki uznany zostanie za ważny to firma wyśle tam swoich najlepszych ludzi a wtedy nawet częste wielogodzinne przesiadywanie w samolotach nie jest w stanie człowieka zniechęcić. Pracując na własny rachunek możemy jedynie liczyć na konferencje.
,,Бог троицу любит”, więc z tego wszystkiego wyszło mi, że są trzy aspekty o które warto zadbać żeby ludziom dobrze się pracowało:
Lubimy pracować nad tematami, które nas interesują, które wiemy, że coś wnoszą do świata, dają coś innym.
Lubimy pracować w dobrym zespole, z ludźmi, którzy wnoszą coś więcej niż tylko dodatkową parę rąk i jedną głowę.
Wreszcie lubimy pracować nad tematami, w których czujemy się mocni lub w których chcemy czuć się mocni.
Oczywiście są ludzie, których motywują inne aspekty (np. Sander był fantastycznym programistą ale nie lubił i nie umiał pracować w grupie) ale, według mnie, stanowią oni zdecydowaną mniejszość a ponadto zapewnienie powyższych aspektów na pewno ich nie zdemotywuje.
]]>I’m not going to write here about metrics and measurements, there are sites covering it but the presentation made me think about the tools we have developed for our agile way of working and how and for what purpose we are using them.
The problem that occurs more often than it should is that once in a while someone on an agile team becomes a bit obsessed with tools. I know, most of are are geeks and we do enjoy good tools but, as everything else, they come at a price.
What I have tried with my last team was to strive to have as few tools as possible and I can report here with confidence that it was a good idea. Every so often during the retrospecitve we would take a quick look at all the tools and artefacts we had and check if the results they had produced were actually useful and then discuss if we really needed them. Good telling signs were the commitments we have taken but failed to apply to. Some of them emerged as a result of some metric or a tool but if we had failed and did not feel bad about it we could start questioning the usefulness of the thing that made us commit in the first place.
An argument to adopt a new tool and, especially, a new metric is often to prepare for the future or “just see how we are doing”. I can appreciate that but the cost of introducing such a tool is often greater than anticipated. We had the argument “but it takes only 5 minutes in the morning to tag the tasks” but nobody predicted in advance that discussing the outcome will chip away a lot of time during the retrospection and we wouldn’t actually learn anything immediately useful. We could have said that it might become in the future but you know what? It haven’t. True, sometimes you have to spend more time analyzing the past because you haven’t measured something in advance but we were not good in predicting what would eventually become useful so it was a good call to drop everything not usefull immediately.
So, the short version of this post is: be aware of the total cost of any tool or metric or a tool you are using and double-check if you are getting useful and practical information out of them. Otherwise, after a while, you might find your agile stiff and a slave to a process.
As a reminder: Agile Principle 12: Inspect and Adapt.
Update: An article targeting specifically agile metrics on InfoQ.
]]>Jeszcze dzisiaj poszukuję trenera, który po wygranym przez nas przetargu zechciałby przeprowadzić dla Zamawiającego szkolenie ze…
Litościwie pominę link do oryginału, szczegóły i nadawcę ale z ciężkim sercem bo takie podejście powinno być karane publicznym słownym ukrzyżowaniem. Wady przetargów znamy wszyscy ale takie podejście nie dość, że prawie gwarantuje Zamawiającemu słabą usługę to jeszcze psuje rynek tego szkolenia.
Ale prawdziwa lekcja jest inna: przetarg czy nie, sprawdzajmy kompetencje potencjalnych podwykonawców.
]]>Powierzchownie wydawało mi się, że sprawa sprowadza się do niedbałości o jakość: bardzo często wyglądało na to, że wiele firm jakość zupełnie ich nie intresuje pomimo, że przenigdy żaden odpowiedzialny manager nie przyznałby się do tego. Ta jakość może dotyczyć wytwarzanych produktów, podejścia do klienta, dbałości o własnych pracowników itp. nie ma to specjalnie znaczenia.
Potem zacząłem zastanawiać się z czego to może wynikać i jedyna logiczna odpowiedź jaka przyszła mi do głowy to ucieczka kadry zarządzającej od odpowiedzialności. Inaczej nie jestem w stanie uzasadnić dlaczego na przykład polskie telekomy wydają grube miliony na reklamę mającą przyciągnąć klientów konkurencji zamiast wydać ułamek tej kwoty, żeby zadbać o własnych. Podejrzewam, że odbywa się to na zasadzie kopiowania tego co robią inni bo za to nikt się nie przyczepi.
Na tej samej zasadzie mało kto na poziomie dyrektora dba o jakość pracy i komfort własnych pracowników: najpierw stara się zrekrutować jak najlepszych pracowników ale natychmiast wtłacza się ich w procedury nie pozwalające optymalnie pracować bo znowu za wdrożenie i pilnowanie procedur trudniej dostać po głowie niż za jakąkolwiek działalność.
Nie jestem pewnien czy ta konkluzja jest pozytywna czy negatywna ale mnie pozwala spokojniej podchodzić do kontaktów z korporacjami.
]]>Każdy feedback z naszej pracy jest dla nas bardzo cenny, a rzadko kto w tym kraju ma takie podejście w kwestii dzielenia się swoją wiedzą i doświadczeniem. Bardzo to wszyscy w trójkę doceniamy!
W pierwszej chwili pomyślałem, że to po prostu miły gest ale po krótkim zastanowieniu doszedłem do wniosku, że faktycznie w Polsce spotkałem całkiem sporo osób pilnujących bardzo, żeby nikt im nie ,,ukradł” wiedzy.
Wydaje mi się to bzdurą z dwóch powodów. Po pierwsze, mając pod ręką Google, Wikipedię i Amazon (prawie) każda informacja jest łatwo dostępna. W dodatku wiedza książkowa jest często nieco zapóźniona bo postęp w wielu dziedzinach często dokumentowany jest w czasie rzeczywistym na ogólnie dostępnych stronach, blogach czy forach. Zwłaszcza w dziedzinie oprogramowania. Sama informacja nie jest już taką dużą wartością jak była kiedyś kiedy na dobre książki trzeba było polować.
Po drugie, dzielenie się wiedzą nie powoduje, że dzielącemu się wiedzy ubywa. Wręcz przeciwnie—nic tak nie pomaga uporządkować swoich przemyśleń czy doświadczeń jak opowiedzenie komuś o nich. Ponadto przy takich rozmowach ja dużo się uczę o tym co i dlaczego poszło źle a informacje pochodzące z doświadczeń, zwłaszcza negatywnych, są dużo trudniejsze do zdobycia.
W sumie wyłania mi się konkluzja, że wiedzy ,,pilnują” ludzie nie mający jej zbyt wiele, albo mający wiedzę powierzchowną więc nie ma co próbować jej z nich wyciągać czy żałować, że nie chcą się podzielić.
]]>The SL018 sports two jumpers which let you select the address the reader will use on an I2C bus. This means that you can connect up to four devices on a single bus and that before you connect more than one you have to solder one or more of these jumpers. Take look at the manual for details.
Marc’s RFDuino can poll one reader at a time so we need a way to figure out when to poll which reader. Fortunately Stronglink’s readers feature a pin that signals whether a card has been found in the field. On the SL030 this is pin number 5 called “Out”, and we will connect it to one of the Arduino pins. Now, we will only poll the reader for card data once the reader have signalled that the card is actually available.
So, the implementation of the above method works roughly like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
|
We can add as many segments like this in the loop()
part of the Arduino code and each segment supporting a particular reader will ‘trigger’ whenever that reader fill find a card.
The code where we are waiting for data could be written more naturally as:
1
|
|
but for some reason that I didn’t have the time to investigte does not work.
Just go to Marc’s github repository and peek into the RFIDuino/SL018/examples/twoReaders directory. It contains a twoReaders file that I have written and which Marc included in his repository. Please note that Marc updated his library for Arduino IDE 1.0 but there is nothing IDE-specific in this example. If you have an older version of the RFDUino library just change the file extension of my code accordingly.
Here’s the full example code for your convenience:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 |
|
Good luck and have fun! If you have some improvements to this code for Marc’s (preferably) or my repository on git hub and help pushing this library forward.
]]>Here’s an quite easy and not too expensive way to integrate NFC with Arduino.
Just in case, before we proceed, I’m going to make a disclaimer here. The NFC technology has been around for years begging to be adopted on a mass scale and when it have finally picked up the mess is considerable. For years the technology companies couldn’t figure out the “killer app” and finally we now see there isn’t one. Partly for this reason there’s no consensus on the terminology. So my disclaimer is that I need to work with Mifare cards only so to keep the cost low I have selected the NFC modules from Stronglink which only talk to Mifare cards. And not even all of them. Nevertheless, Mifare enjoys the widest deployment in, I believe, the whole world besides Japan. Your public transport card most probably uses it. So, before you place your order double-check if this module covers whatever card you want to play with. I myself have purchased a set of NFC stickers from Stronglink to be able stick them on wherever needed.
An NFC (Mifare) module from Stronglink. I’ve chosen the SL030 because I wanted to work with 3.3V supply voltage but you can have a 5V version as well. Here you can see how big it is:
As with most of casual bloggers you have to excuse the quality of pictures taken with a phone.
The module comes as an board populated SMD components but without headers so if you don’t have spare ones laying around make sure you get them separately or you will have to solder wires directly to the board.
The board supports I2C interface so you need just 2 wires, power supply and ground to connect it to Arduino.
Arduino to SL030 wiring:
A4/SDA 3
A5/SCL 4
GND 6
3V3 1
Here’s the board connected to Arduino Uno:
And to a JeeNode (the reason I needed a 3.3V module is that this is the voltage the JeeNode operates on):
This NFC module is supported by the RFIDuino libraries hosted here written by Marc Boon (thank you, Marc!). The SL030 module works with the library that Marc called SL018. On the screenshot below you can see both the simple example code (available in the “examples” subdirectory) as well as the result of scanning a number of tags.
Well, that was pretty easy, wasn’t it? I consider this part a warm-up and “check if everything is ok” step. My final goal is to connect two readers to a single Arduino and possibly connect it to internet. If you get bored before part 2 appears, take a look at Marc’s code, there is a lot of comments that explain what is going on. You might also find the SL030 User Manual useful.
P.S. The JeeNode is a pretty cool device. You get an Arduino + Radio for less.
]]>