How long should a Product Backlog be? How should it be organized? Is there a universal rule of thumb or is it product-specific?
Are the concepts of the MVP (Minimal Viable Product) and iterative development related? Do they try to solve the same problem in a different way or are they complementary and can be used together?
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?
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.
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.
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?
Serious quality improvements require investments right now, while promised benefits wait somewhere far in the future.
Cleaning a messy code base will allow your team to speed up, but first, its velocity will drop, consumed by all the refactoring work needed. Implementing TDD will make adding new features a breeze, but first, time must be spent to configure necessary tools and to learn.
This makes people uneasy.
A culture is trendy.
It has become fashionable to brag about a company’s culture. Companies advertise themselves as having a startup-like culture, agile culture, craftsmanship culture – or whatever culture is hot at the moment.
Such cultural claims are shown off in job ads, conference talks and mission statements. They are sometimes even codified in procedures.
Fine and dandy. But does the actual, day-to-day behavior of the company’s employees affirm them?
When a project fails we often hear a question: “whose fault it is?”.
I’ve heard it so many times. And every time I wonder how come people can’t see how ridiculous this question is.
One of the fundamentals of Agile methodologies is the “inspect and adapt” approach.
What does it mean to inspect and adapt? It means that instead of planning (guessing) everything up-front waterfall style, you regularly reflect on your current situation and change your behavior accordingly.
To make such an approach work well, you must keep in mind a few rules: