Przejdź do głównej zawartości


Dwie parafie

This is the only post in Polish, it would not be easy to understand in English, as it is strongly based in Polish context.

Ten post dedykuję Mariuszowi Francuzowi, który pokazał mi, że Kanban to o wiele więcej niż tablica stanów.

Pewnego razu były sobie w Polsce dwie parafie. Żeby ukrócić plotki przyjmijmy, że jedna z nich nazywała się W a druga A. Obie parafie stanęły przed problemem: trzeba wyświetlać podczas Mszy Świętej teksty pieśni na ekranie.

Parafia W podeszła do problemu w następujący sposób. Zebrała kilkanaście mądrych i doświadczonych osób, aby zrobić zestawienie pieśni na cały rok. Parafia zadbała o to, aby w tym gronie bylo zarówno wierni jak i duchowni. Debatowanie nad listą pieśni zajęło trzy miesiące. Uzgodniona lista tytułów została przesłana do Kurii w celu konsultacji. Po trzech miesiącach Kuria odpowiedziała, nakazując wyłączyć ze spisu dwie pieśni, a z kolei dołączyć siedemnaście innych.

Na nowo zenergetyzowane grono parafii W zaczęło spisywać pełne teksty pieśni, …
Najnowsze posty

Attitude is more important than skills

I was fortunate to work with a few development teams that were truly cross-functional. Every developer was able to perform several types of tests, build and deploy the product and develop code in layers of the product. Not many teams are like that.

More often than not, teams do specialize by skills like: frontend, backend, testing, etc. A cursory look at a job board makes it clear that the range of specialized skills is even broader: data scientists, Cloud maintenance engineers, DevOps, manual testers, and more. Developers are often hired based on these specialized skills - no surprise they may end up thinking they are there just to do one special kind of job. The risk that we are running here is the deterioration towards groups of uncooperative, though skilled, professionals.

This specialization, in today's world, is inevitable, but it does not have to be bad. It is extremely important to understand that specialization is a factor that influences the way the developers interact w…

An illustrated analogy to carpentry

Code is like a building material. Imagine the code you work with is wood.

Just like wood and wooden appliances, it can have different structure.

Just like wood, it is exposed to external forces and to the pass of time.

Just like wood, it requires different tools to work with it and turn it into something usable and beautiful. Humans devoted many past years to the invention and enhancement of these tools. It would be foolish not to use them.

In both coding and carpentry, we need to learn to use each tool. Otherwise we are likely to cause damage.

Depending on the craftsmanship applied to woodworking, it is either harder or easier to maintain and repair a wooden appliance months and years after somebody started using it. Same is with code.

Different types of wood have been recognized as particularly good for different uses. And our OS kernels aren't coded in Javascript.

The code that you are developing today - which piece of furniture is more like it?

My favorite kind of Waterfall

Be a human, not a compiler

A recent reading inspired me to make an observation on programming skills and differences between those the masters and the laymen.

This is not the kind of information you will learn at university or a conference. This can change your professional attitude, so read on.

From the very beginning of our programming education we are talked into thinking like a compiler. We gradually develop the thinking that in order to write a decent piece of code we need to ask ourselves questions like these below:
how is this thing going to be evaluated by the computer?will this index ever go out of array boundary?can this variable overflow under any circumstances?will this statement correctly modify / concatenate / process these numbers / strings?is it then this pointer that is going to point at the result when the function returns? After years of doing that, we are even inclined to judge others at job interviews by how they are able to answer these questions. The funny (and upsetting, at the same time…

Start with something irrational

In this post I want to provide some examples how a Scrum Master can use irrational cases to foster discussion at Sprint Planning.

By irrational case I mean here asking the team for an opinion about an irrational amount of work or considering an irrational amount of time to complete some work. Here are the examples:

A Scrum Team is planning to execute some manual regression tests that they know cannot be completed in one sprint. They want to spread the execution through a few next sprints. The Product Owner wants to get agreement with the Development Team on how much of the regression can be completed in the current sprint. The regression has already been divided into well defined, small or medium backlog items.

The Development Team stucks in the discussion and they find it difficult to discuss how much of the regression they can do. The Scrum Master may ask questions like these:
(A) can you do exactly one regression backlog item in this sprint?(B) can you do half of the regression in t…

Looking back at the year 2015

I want to share some of my reflections over what I experienced in the ending year 2015 in software development area.

I attended two conferences this year: Agile Central Europe and Scrumdays (and ran a Practical Scrum workshop at the latter). The most influential and interesting speeches, in my opinion, were these two:
Science or Stories by Linda Rising - totally mindblowing speech! I also had a short but nice email exchange with Linda about Common SenseGreat speech Lean Product Management by Melissa Perri At each conference, there were lots of Scrum Masters (probably more than 50% of the attendees), quite many Product Owners, many "other people" and very little developers. What were they doing while their Scrum Masters and POs were at a conference? What other kind of gathering they attended last year?
Scaled Scrum / Scaled Agile
It seems like everybody wants to be doing Scaled Something nowadays and everybody wants Scaled Scrum more than they want decent Scrum. When…