Taiga is an open-source project management software for agile teams used by millions of users worldwide. This privileged observatory gives the Taiga team access to a lot of information that helps detect the symptoms which lead to typical agile mistakes.
Pablo Ruiz-Muzquiz, CEO and co-founder of Taiga and Kaleidos, shared some key insights last December 17th, 2021 during our live streaming webinar on agile misconceptions and anti-patterns. You can watch the recording of the full webinar here:
Alternatively, if you’re one of those that are always on the run, you can listen to our podcast with the full voice recording of the webinar.
or
The top 4 agile antipatterns
Two years ago, Pablo had the pleasure of sharing the stage with Arie Van Bennekum, one of the Agile Manifesto authors. Arie had prepared a wonderful lecture on Agile and Waste and Pablo decided to talk about Dysfunctional Agile via what he calls the Agile Antipatterns. This blog post Pablo wrote shortly after, covers the topic and has inspired some other talks and webinars, like this past one.
On this webinar, though, he made sure to go back to the Agile Manifesto and its false myths, still perpetuated today (with the best of intentions, sure). After translating common agile misconceptions into more honest claims, he shares his thoughts on which particular technique, Scrum or KANBAN, suits a team based on their agile maturity (whether formal or informal).
A couple of questions left unanswered
On the Q&A of the webinar, there were a few questions that unfortunately were out of time and Pablo wasn’t able to answer them. We promised during the webinar that they’d be taken care of and here are Pablo’s responses:
Q1: Some projects involve electric boards and mechanical parts that are prone to production delays. In these cases, how can these teams leverage agile and how to integrate with the software team agile flow?
Pablo Ruiz-Muzquiz, CEO and co-founder of Kaleidos and Taiga.
[Pablo] In these cases, showing potential impediments or blocks is key. This “visual radiator” of critical dependencies is fundamental to make sure you, as a team, can commit to a number of user stories per sprint (Scrum) or a specific due date in a card (KANBAN board). External dependencies, whether they are production delays, late infrastructure availability or third-party API readiness , must be clearly shown as dependencies or blocks. Taiga has a feature for this, the BLOCK visual marker that asks for a reason (look for the lock icon).
In a Scrum’s Backlog, you should be able to have a dependency-heavy user story right at the top (representing priority) but status-labelled as NOT READY (or something like WAITING FOR X, etc), therefore not being available during the next Sprint’s planning yet impossible to ignore at that stage or during the Sprint’s retrospective where actions are defined. If using KANBAN, a similar technique could be used. Radiating that info and encouraging actions towards a successful unblocking is not enough. While you’re suffering from such nuisance, you need to make sure that:
- You’re not just keeping yourself busy, you’re actively seeking ways to deliver value and minimum waste.
- You invest in ways to minimise worst-case scenario impact taking into account the Last Responsible Moment technique.
As an extreme consequence, I’ve seen teams deciding the most beneficial decision for the project was to halt it temporarily until some strong dependency was finally met. If you plan this in advance, you might find valuable time for some side project that never got quality time and return to the core project in a much better position overall.
Q2: Is it better for a team to use two boards (Scrum for planned work and Kanban for continuous/support work) rather than using only one Scrumban board?
[Pablo] I’m unable to offer much more than “it depends” here. Planned work can also enjoy a healthy KANBAN and support work can be allocated using sprint-like processes (specially if they provide some business value). I think the key part of the question here is “a (one) team” doing both. In that case, I suggest you start with Scrum as the core technique for anything that can be planned, committed to and brings value plus any ticketing system that deals with priority/severity for organic support. Just make sure:
- You have visibility over both.
- Commitment towards a sprint has taken into account some reserved capacity for support
- There are clear rules on when issues/support tickets should be addressed so everyone is on the same page.
Taiga deals with this in a relatively neat way. In a Sprint Taskboard view, you can link issues from the Issues Module and make sure you have everything in one simple view. You get your Sprint and user stories (plus user story-less tasks) and also a filtered view on issues belonging to the Issues module that are relevant to this sprint. It’s also super handy for retrospectives.*
If you have more questions, feel free to ask in the comments section below.
Sign up to our free Basic Plan to begin applying agile correctly with our help.
