Is not about it, is all about sailing

“Is not about it, is all about sailing” is the title I’ve chosen to use for the presentation to the quarterly Byte-code All hands as guest speaker.

I know it doesn’t mean anything.

The scope of the presentation is the importance of the so called soft skills: cooperation, communication, what are non technical abilities. and all the non technical abilities. The sailing is the example I’ve chosen to better explain my point of view.

The slides are better understandable if you have a look at the video of my presentation (Note: unfortunately is in italian).


Agile #2 – Kanban vs Scrum – Myths and Truths

After an introduction on Kanban, in this second article I will try to make some evaluation of Kanban, taking Scrum as reference which is a methodology I consider myself experienced. I want also to emerge some myths and truths that are flying around. Personally I have been using Scrum for almost three years in the same project (in a definitevly non-agile organization – with all the difficulties implied). in 2011 I became Scrum Master certified.

Before start reading, be aware that this article doesn’t aim to support one or another agile methodology. I’d like to share some thoughts coming from my experience.

Let’s talk about Scrum. From Wikipedia: Scrum is an iterative and incremental agile software development method for managing software projects and product or application development. Scrum has not only reinforced the interest in project management, but also challenged the conventional ideas about such management. Scrum focuses on project management institutions where it is difficult to plan ahead. Mechanisms of empirical process control, where feedback loops that constitute the core management technique are used as opposed to traditional command-and-control oriented management. It represents a radically new approach for planning and managing projects, bringing decision-making authority to the level of operation properties and certainties.”

Scrum methodology

Scrum also define three main roles: Team, Scrum Master, Product Owner with different responsibilities and duties. If you want to know more about Scrum this page contains good description and explanation.

Kanban and Scrum, two different models, two different origin, a common goal: deliver business value.

To achieve the same goal, Kanban and Scrum use different approaches, and they can be effective on different contextes. Let’s see some myths and truth about my experience with Scrum and Kanban:

Myth #1: ${methodology} gives better visualization of the workflow and the problems can be better identified. This is not true, if the problems are not visible on the board means the board is not correctly designed. Change the board instead (e.g. add more columns).

Myth #2Scrum is harder to adopt, because has more rules and is more restrictive, Kanban is easier and can be adopted step by step. Indeed Scrum has more rules, but nobody stops you to adopt Scrum gradually or only partially. For example you could start having stand-up meetings every day. Adopting the full implementation of Scrum require just a bit more training than Kanban.

Myth #3Repeated daily meetings are part of the waste generated due to communication overhead. I think in every environment the communication is one of the failure point. The benefit of having daily short meetings is enforce everybody to be informed about what is going on in the team. Believe me, desk-mate sometimes are not talking. 15 minutes must be the maximum time for a stand up meeting for a 7/8 team’s people.

Truth #1Kanban works better in a maintenance team. In maintenance mode, the team has to guarantee a constant lead-time (time from when the ticket is open to when is closed). The input throughput is not predictable and is subject to high variability. The focus is not the delivery before a certain date (end of the iteration) on tasks coming with variability therefore Kanban is surely a better choice.

Truth #2: Scrum works better in a development team. Where the focus is to delivery incremental features within sprint boundaries, Scrum gives to the team better visualization of the short-term and final goal. Kanban has the concept of fixed delivery date, and can be adapted, but Scrum comes naturally as the best choice for this case.

We can stay talk for hours to see the differences, but the real truth is that both can be adapted to basically any kind of situation. The real problem is not the method itself but the maturity of the organization. That’s the crucial point! Maturity of the organization doesn’t mean only maturity of the management, but also maturity of external teams, procurement, test teams, etc however most of the big organizations are still behind the schedule, and they are starting slowly to move out from the old waterfall approaches.

For sleepless nights: Scrum vs Kanban:  is an interesting book, written by Henrik Kniberg that explain how Scrum and Kanban are related and can be used together.

Fast test, slow test

I found this video quite interesting, here some observations:

  • Why you test? Tests are preventing regression, fear (enable refactoring), bad design.
  • In the video the guy is talking about System tests. The meaning is quite generic for integration and/or functional tests. Normally they are not as fast as Unit tests.
  • If every time you change the code, you have to change the tests, you have clearly problems with tests
  • A way to measure how our test is unit is to measure how many dependencies we have in every of our tests. Every dependency increase the probability to fail the tests if external code is changed, and when it fails cannot tell you exactly where.

Reasons to fail the test strategy:

  • Use selenium as primary test suite – slow – no possibility to use TDD
  • Unit tests are too big. Studies have demonstrate that testing time is growing exponentially from the start of a process development.
  • Write fine grained tests around legacy code is a bad way to design tests.


  • 90-95% of Unit tests – 5-10% Integration/Functional tests
  • Quick unit Tests allow you to do TDD. If it has to fail, it has to fail fast.
  • When unit tests are failing, they are pointing the fine grain problem, if this is not true, they are not unit tests