Why do we do Agile?

Why do we do Agile?

What problem does it solve? What benefits does it give? Why it’s better than the Waterfall methods?

What are the core reasons to use it?

Continue reading “Why do we do Agile?”

Advertisements

The single and correct level of abstraction at the specification by example level – 5 rules to write good examples

In one of my previous posts, I wrote about the single and right level of abstraction. In that article, I focused on the code and unit tests level. However, the single and the right level of abstraction principle applies also at a much higher level – at the level of specification by example. The driving force behind it is different than in the case of unit tests though, so it’s worth a separate discussion.

Continue reading “The single and correct level of abstraction at the specification by example level – 5 rules to write good examples”

The most important thing about test coverage is consistency

If we can’t, for some reason, have 100% test coverage, which parts of the system should we cover and to what degree?

What will give us more value:

  • to cover only main positive scenarios, but for all features
  • to cover only a few most important features, but in 100%
  • to strive for as high coverage in as many features as possible, deciding what to cover with tests on a case-by-case basis

Many teams new to TDD or working on legacy projects struggle to achieve full test coverage for all features, so questions like this are not uncommon.

Let me share my opinion on this topic.

Continue reading “The most important thing about test coverage is consistency”

Passion vs engagement – how to attract and keep the top talent

Several weeks ago, I’ve read a Henrik Berglund’s post on the Scrum.org blog that really struck a chord with me. In a nutshell, its message is that to stay competitive on the current market, the passive expertise of your employees is not enough, they must also be deeply engaged or even truly passionate about what they do for you.

Continue reading “Passion vs engagement – how to attract and keep the top talent”

Only 1 expectation per spec – an empty dogma or not?

An old TDD dogma says that there should be only a single expectation per spec 1.

I agree that this is a good rule of thumb, but as with all such extreme advices, you shouldn’t follow it blindly. To better understand why the single expectation heuristic is useful, let’s focus on the impact it has on the two core aspects of BDD-style specs: acting as living documentation and guiding the design of the system.

Continue reading “Only 1 expectation per spec – an empty dogma or not?”

Don’t mix roulette with poker – a recipe for better estimations

During a planning poker estimation we hide cards until everybody makes his mind and then we reveal them all at once. We do that to make the estimation more objective, unbiased.

One obvious bias that could skew our estimation is influence of more experienced, or just more vocal, team members. The pressure resulting from their self-confidence can impact our estimate, make it gravitate towards their opinion.

However, there is also another strong, but not so obvious bias: the Anchoring Effect.

Continue reading “Don’t mix roulette with poker – a recipe for better estimations”

Impeded work in kanban is a “critical error” state, not “waiting”

During a discussion about a WiP (work in progress) limit for the “development” column of our kanban board, a question appeared: what should we do if a story is blocked for some reason during development?

My answer was to mark the impeded story with some eye-catching token (e.g. big, red exclamation mark), “stop the production line” and focus on un-blocking the story as quickly as possible.

This raised a lot of doubts. Why should we stop the production line in such a case? Why can’t we simply multitask for a moment and work on another story, letting the impeded story “hang” idly on the board until it becomes un-blocked?

Continue reading “Impeded work in kanban is a “critical error” state, not “waiting””

The 3 kinds of tests you must understand to do effective TDD

The tests are a mess!

There is a plethora of different kinds of automated tests. If we check out the Wikipedia entry on Software Testing we can find many specialized types of tests: sanity, smoke, usability, security, conformance and so on.

Similarly, the so called “test pyramid” model, popularized by Mike Cohn in his Succeeding with Agile book, also has several variants, with a different number and differently named layers:

Continue reading “The 3 kinds of tests you must understand to do effective TDD”