While the ”Gamestorming” book by Gray et.al. is mostly used as a reference of workshop tools I found an interesting thought in the introductory section. They noticed that some goals are ”fuzzy” by nature which implies that ”a project must proceed based on intuition, hypotheses and guesses”.

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.

Wielki zegar w hallu głębokim dźwiękiem wybija sześć uderzeń. Młody scrum master ze spoconym czołem i błędnymi oczami wypada z sali i biegnie korytarzem. Właśnie zakończył się kolejny przegląd sprintu i młody scrum master jest przekonany, że jeśli Gandalf go nie przyjmie będzie to jego ostatni sprint. Nieśmiało wchodzi do sali, w której Gandal oddaje się kontemplacji Sedna.

The Agile Warsaw meeting yesterday was, as usual, interesting but today’s news on the radio reminded me about one more issue missing from Paweł Rzymkiewicz’s talk about ATDD (Acceptance Test Driven Development). He said that the most important aspect addressed by adopting it was a much better communication between the Product Owner and the team. Good communication is, indeed, absolutely crucial but I think writing acceptance tests can mitigate an even more fundamental problem.

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 have just finished a very interesting workshop. Interesting for a number of reasons. The idea was to check if I can help two related companies in transformation from “traditional” to agile way of working. The problem was that the companies ware related only organizationaly but were playing on completely different markets, neither was related to software development and, on top of that, the participants spanned all the hierarchy levels. And I really mean all.

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?

Kilka tygodni temu miałem okazję dowiedzieć się z pierwszej ręki jak w pewnej niemałej firmie debiutującej na rynku usług cyforwych przeprowadzono procedurę wyboru strategicznego dostawcy oprogramowania.

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.