#kanban — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #kanban, aggregated by home.social.
-
4 days in, #AgileConfessions has some gems:
"I misused the daily as a status report."
"I thought agile meant finishing tickets fast so I could change the plan anytime."
"Endless upfront plans, until I learned to run experiments."Your turn: the most anti-agile thing you've done, and what it taught you. Any language, just tag #AgileConfessions.
-
4 days in, #AgileConfessions has some gems:
"I misused the daily as a status report."
"I thought agile meant finishing tickets fast so I could change the plan anytime."
"Endless upfront plans, until I learned to run experiments."Your turn: the most anti-agile thing you've done, and what it taught you. Any language, just tag #AgileConfessions.
-
@andre Die These kann ich aus der Praxis bestätigen.
Crossfunktionale Teams, Anwendernähe, Transparenz, Feedback Loops, Service Safaris, gemeinsames Lernen, schnelle Entscheidungen, angemessene Komplexität.
Wenn man echtes agiles Arbeiten in der Organisation zulässt, kann man Software in sehr kurzer Zeit herstellen.
KI kann unterstützen, ist für mich aber nicht der Schlüssel.
Die Verzögerung kommt nicht durch die Technik, sondern die Strukturen.
-
@andre Die These kann ich aus der Praxis bestätigen.
Crossfunktionale Teams, Anwendernähe, Transparenz, Feedback Loops, Service Safaris, gemeinsames Lernen, schnelle Entscheidungen, angemessene Komplexität.
Wenn man echtes agiles Arbeiten in der Organisation zulässt, kann man Software in sehr kurzer Zeit herstellen.
KI kann unterstützen, ist für mich aber nicht der Schlüssel.
Die Verzögerung kommt nicht durch die Technik, sondern die Strukturen.
-
JiraMetrics v3.0 is out.
It's a free, open-source command-line tool that turns your Jira history into agile metrics charts (cycle time, aging WIP, throughput, and more) in one self-contained HTML report. Useful for any team that wants to understand and improve its delivery flow.
A major release because it now requires Ruby 3.4 (or JRuby 10) and removes long-deprecated features.
Full change log at https://jirametrics.org/changes/
#agile #jira #flowmetrics #kanban #scrum -
JiraMetrics v3.0 is out.
It's a free, open-source command-line tool that turns your Jira history into agile metrics charts (cycle time, aging WIP, throughput, and more) in one self-contained HTML report. Useful for any team that wants to understand and improve its delivery flow.
A major release because it now requires Ruby 3.4 (or JRuby 10) and removes long-deprecated features.
Full change log at https://jirametrics.org/changes/
#agile #jira #flowmetrics #kanban #scrum -
JiraMetrics v3.0 is out.
It's a free, open-source command-line tool that turns your Jira history into agile metrics charts (cycle time, aging WIP, throughput, and more) in one self-contained HTML report. Useful for any team that wants to understand and improve its delivery flow.
A major release because it now requires Ruby 3.4 (or JRuby 10) and removes long-deprecated features.
Full change log at https://jirametrics.org/changes/
#agile #jira #flowmetrics #kanban #scrum -
JiraMetrics v3.0 is out.
It's a free, open-source command-line tool that turns your Jira history into agile metrics charts (cycle time, aging WIP, throughput, and more) in one self-contained HTML report. Useful for any team that wants to understand and improve its delivery flow.
A major release because it now requires Ruby 3.4 (or JRuby 10) and removes long-deprecated features.
Full change log at https://jirametrics.org/changes/
#agile #jira #flowmetrics #kanban #scrum -
JiraMetrics v3.0 is out.
It's a free, open-source command-line tool that turns your Jira history into agile metrics charts (cycle time, aging WIP, throughput, and more) in one self-contained HTML report. Useful for any team that wants to understand and improve its delivery flow.
A major release because it now requires Ruby 3.4 (or JRuby 10) and removes long-deprecated features.
Full change log at https://jirametrics.org/changes/
#agile #jira #flowmetrics #kanban #scrum -
Neulich im Board-Review: 5 Devs, 14 Tickets gleichzeitig ‚in Arbeit'. Alle busy, keiner fertig, Chef fragt: warum sind wir so langsam?
Ihr seid nicht langsam. Ihr habt zu viel offen. Auslastung ist nicht Geschwindigkeit. Jedes Ticket, das du zusätzlich startest, verlängert die Wartezeit für alle. Stop starting, start finishing.
Little's Law selbst erleben: https://no-bullshit-agile.de/wipit-warum-dein-team-nicht-langsam-ist-sondern-ueberladen.html
-
Neulich im Board-Review: 5 Devs, 14 Tickets gleichzeitig ‚in Arbeit'. Alle busy, keiner fertig, Chef fragt: warum sind wir so langsam?
Ihr seid nicht langsam. Ihr habt zu viel offen. Auslastung ist nicht Geschwindigkeit. Jedes Ticket, das du zusätzlich startest, verlängert die Wartezeit für alle. Stop starting, start finishing.
Little's Law selbst erleben: https://no-bullshit-agile.de/wipit-warum-dein-team-nicht-langsam-ist-sondern-ueberladen.html
-
⚡ RARgames/4gaBoards
Enables visual project management via realtime kanban boards supporting multitasking, markdown editing, and dark mode.
⭐ Stars: 673
📅 Last Update: Jul 21, 2026https://github.com/RARgames/4gaBoards
#selfhosted #homelab #selfhost #selfhosting #opensource #projectmanagement #kanban
-
⚡ RARgames/4gaBoards
Enables visual project management via realtime kanban boards supporting multitasking, markdown editing, and dark mode.
⭐ Stars: 673
📅 Last Update: Jul 21, 2026https://github.com/RARgames/4gaBoards
#selfhosted #homelab #selfhost #selfhosting #opensource #projectmanagement #kanban
-
⚡ RARgames/4gaBoards
Enables visual project management via realtime kanban boards supporting multitasking, markdown editing, and dark mode.
⭐ Stars: 673
📅 Last Update: Jul 21, 2026https://github.com/RARgames/4gaBoards
#selfhosted #homelab #selfhost #selfhosting #opensource #projectmanagement #kanban
-
Scrum — не серебряная пуля. Почему «натянутый» Scrum на несколько команд ломает продукт — и что работает вместо него
Есть фраза, от которой у меня до сих пор дёргается глаз: «Да там ничего сложного — просто раскатим Scrum на все команды». Обычно её уверенно произносит человек, который пару недель назад сходил на двухдневный курс, получил красивый сертификат — и теперь искренне считает, что понял, как устроена разработка. Пятнадцать лет в профессии, путь от инженера до директора разработки, до восьми команд над одним продуктом одновременно — и за это время я видел этот сценарий десятки раз. Приходит свежий «эксперт», и Scrum начинают натягивать на всё подряд: на поддержку, на исследования, на команду из трёх человек, на департамент из ста. По одному лекалу. «Потому что так правильно». Сразу оговорюсь: проблема не в Scrum. Scrum — хороший инструмент, я сам его люблю и использую. Проблема в том, что его продают и покупают как серебряную пулю — универсальное лекарство от всех болезней доставки. А потом искренне недоумевают, почему на нескольких командах, которые пилят один продукт, всё превращается в хаос из зависимостей, интеграционного ада и созвонов ради созвонов. Ниже — три вещи, на которых я набил шишки лично: (1) откуда взялся миф о всемогущем Scrum и почему сам Scrum Guide с ним не согласен; (2) почему «голый» Scrum, натянутый на несколько команд с одним продуктом, — это заявка на провал; (3) что реально работает в этом контексте — от LeSS до Team Topologies — и как в эпоху AI выбор смещается в сторону лёгких, потоковых, адаптивных подходов. Без хайпа, с источниками и из практики.
https://habr.com/ru/articles/1061124/
#scrum #less #team_topologies #масштабирование_команды #delivery_management #предсказуемость #управление_разработкой #оргдизайн #scrum_of_scrums #kanban
-
Scrum — не серебряная пуля. Почему «натянутый» Scrum на несколько команд ломает продукт — и что работает вместо него
Есть фраза, от которой у меня до сих пор дёргается глаз: «Да там ничего сложного — просто раскатим Scrum на все команды». Обычно её уверенно произносит человек, который пару недель назад сходил на двухдневный курс, получил красивый сертификат — и теперь искренне считает, что понял, как устроена разработка. Пятнадцать лет в профессии, путь от инженера до директора разработки, до восьми команд над одним продуктом одновременно — и за это время я видел этот сценарий десятки раз. Приходит свежий «эксперт», и Scrum начинают натягивать на всё подряд: на поддержку, на исследования, на команду из трёх человек, на департамент из ста. По одному лекалу. «Потому что так правильно». Сразу оговорюсь: проблема не в Scrum. Scrum — хороший инструмент, я сам его люблю и использую. Проблема в том, что его продают и покупают как серебряную пулю — универсальное лекарство от всех болезней доставки. А потом искренне недоумевают, почему на нескольких командах, которые пилят один продукт, всё превращается в хаос из зависимостей, интеграционного ада и созвонов ради созвонов. Ниже — три вещи, на которых я набил шишки лично: (1) откуда взялся миф о всемогущем Scrum и почему сам Scrum Guide с ним не согласен; (2) почему «голый» Scrum, натянутый на несколько команд с одним продуктом, — это заявка на провал; (3) что реально работает в этом контексте — от LeSS до Team Topologies — и как в эпоху AI выбор смещается в сторону лёгких, потоковых, адаптивных подходов. Без хайпа, с источниками и из практики.
https://habr.com/ru/articles/1061124/
#scrum #less #team_topologies #масштабирование_команды #delivery_management #предсказуемость #управление_разработкой #оргдизайн #scrum_of_scrums #kanban
-
Scrum — не серебряная пуля. Почему «натянутый» Scrum на несколько команд ломает продукт — и что работает вместо него
Есть фраза, от которой у меня до сих пор дёргается глаз: «Да там ничего сложного — просто раскатим Scrum на все команды». Обычно её уверенно произносит человек, который пару недель назад сходил на двухдневный курс, получил красивый сертификат — и теперь искренне считает, что понял, как устроена разработка. Пятнадцать лет в профессии, путь от инженера до директора разработки, до восьми команд над одним продуктом одновременно — и за это время я видел этот сценарий десятки раз. Приходит свежий «эксперт», и Scrum начинают натягивать на всё подряд: на поддержку, на исследования, на команду из трёх человек, на департамент из ста. По одному лекалу. «Потому что так правильно». Сразу оговорюсь: проблема не в Scrum. Scrum — хороший инструмент, я сам его люблю и использую. Проблема в том, что его продают и покупают как серебряную пулю — универсальное лекарство от всех болезней доставки. А потом искренне недоумевают, почему на нескольких командах, которые пилят один продукт, всё превращается в хаос из зависимостей, интеграционного ада и созвонов ради созвонов. Ниже — три вещи, на которых я набил шишки лично: (1) откуда взялся миф о всемогущем Scrum и почему сам Scrum Guide с ним не согласен; (2) почему «голый» Scrum, натянутый на несколько команд с одним продуктом, — это заявка на провал; (3) что реально работает в этом контексте — от LeSS до Team Topologies — и как в эпоху AI выбор смещается в сторону лёгких, потоковых, адаптивных подходов. Без хайпа, с источниками и из практики.
https://habr.com/ru/articles/1061124/
#scrum #less #team_topologies #масштабирование_команды #delivery_management #предсказуемость #управление_разработкой #оргдизайн #scrum_of_scrums #kanban
-
40 Tickets mit „Priorität 1". Das ist keine Priorisierung, das ist eine Wunschliste.
Prioritäten setzen kostet nichts, solange niemand die Kapazität des Teams gegenrechnet. Eine Reihenfolge entsteht erst, wenn du sagst, was NICHT drankommt.
Warum Prioritäten-Pläne fast immer Waste sind:
https://no-bullshit-agile.de/nba08-prioritaeten-sind-quatsch.html -
40 Tickets mit „Priorität 1". Das ist keine Priorisierung, das ist eine Wunschliste.
Prioritäten setzen kostet nichts, solange niemand die Kapazität des Teams gegenrechnet. Eine Reihenfolge entsteht erst, wenn du sagst, was NICHT drankommt.
Warum Prioritäten-Pläne fast immer Waste sind:
https://no-bullshit-agile.de/nba08-prioritaeten-sind-quatsch.html -
40 Tickets mit „Priorität 1". Das ist keine Priorisierung, das ist eine Wunschliste.
Prioritäten setzen kostet nichts, solange niemand die Kapazität des Teams gegenrechnet. Eine Reihenfolge entsteht erst, wenn du sagst, was NICHT drankommt.
Warum Prioritäten-Pläne fast immer Waste sind:
https://no-bullshit-agile.de/nba08-prioritaeten-sind-quatsch.html -
40 Tickets mit „Priorität 1". Das ist keine Priorisierung, das ist eine Wunschliste.
Prioritäten setzen kostet nichts, solange niemand die Kapazität des Teams gegenrechnet. Eine Reihenfolge entsteht erst, wenn du sagst, was NICHT drankommt.
Warum Prioritäten-Pläne fast immer Waste sind:
https://no-bullshit-agile.de/nba08-prioritaeten-sind-quatsch.html -
40 Tickets mit „Priorität 1". Das ist keine Priorisierung, das ist eine Wunschliste.
Prioritäten setzen kostet nichts, solange niemand die Kapazität des Teams gegenrechnet. Eine Reihenfolge entsteht erst, wenn du sagst, was NICHT drankommt.
Warum Prioritäten-Pläne fast immer Waste sind:
https://no-bullshit-agile.de/nba08-prioritaeten-sind-quatsch.html -
Man verlangt vom Team Eigenverantwortung und lässt jede echte Entscheidung vom Management absegnen. Das ist keine Autonomie. Das ist Schuld-Delegation.
Ein Team ohne Entscheidungsbefugnis trägt nur die Verantwortung fürs Scheitern, nicht die Macht, es zu verhindern.
-
Man verlangt vom Team Eigenverantwortung und lässt jede echte Entscheidung vom Management absegnen. Das ist keine Autonomie. Das ist Schuld-Delegation.
Ein Team ohne Entscheidungsbefugnis trägt nur die Verantwortung fürs Scheitern, nicht die Macht, es zu verhindern.
-
Man verlangt vom Team Eigenverantwortung und lässt jede echte Entscheidung vom Management absegnen. Das ist keine Autonomie. Das ist Schuld-Delegation.
Ein Team ohne Entscheidungsbefugnis trägt nur die Verantwortung fürs Scheitern, nicht die Macht, es zu verhindern.
-
Man verlangt vom Team Eigenverantwortung und lässt jede echte Entscheidung vom Management absegnen. Das ist keine Autonomie. Das ist Schuld-Delegation.
Ein Team ohne Entscheidungsbefugnis trägt nur die Verantwortung fürs Scheitern, nicht die Macht, es zu verhindern.
-
Man verlangt vom Team Eigenverantwortung und lässt jede echte Entscheidung vom Management absegnen. Das ist keine Autonomie. Das ist Schuld-Delegation.
Ein Team ohne Entscheidungsbefugnis trägt nur die Verantwortung fürs Scheitern, nicht die Macht, es zu verhindern.
-
RE: https://hachyderm.io/@mlevison/116930316460295220
From Mark: "There are many cases where I don’t love the language of the Scrum Guide. It can be too formal and heavy."
For details see my article. (I know, I have to revise it)
https://www.enteresc.net/done-is-not-just-a-document/ -
RE: https://hachyderm.io/@mlevison/116930316460295220
From Mark: "There are many cases where I don’t love the language of the Scrum Guide. It can be too formal and heavy."
For details see my article. (I know, I have to revise it)
https://www.enteresc.net/done-is-not-just-a-document/ -
RE: https://hachyderm.io/@mlevison/116930316460295220
From Mark: "There are many cases where I don’t love the language of the Scrum Guide. It can be too formal and heavy."
For details see my article. (I know, I have to revise it)
https://www.enteresc.net/done-is-not-just-a-document/ -
RE: https://hachyderm.io/@mlevison/116930316460295220
From Mark: "There are many cases where I don’t love the language of the Scrum Guide. It can be too formal and heavy."
For details see my article. (I know, I have to revise it)
https://www.enteresc.net/done-is-not-just-a-document/ -
Как «Первый Бит» выстроил прозрачный контур управления IT-командой на базе EvaTeam — российского аналога Jira
Как руководителю понять, чем занята ИТ-команда : сколько ресурсов уходит на поддержку, какие работы относятся к проектной нагрузке, где задачи остаются без оценки, а где назначены исполнители, но работа не движется? В компании «Первого Бита» для этого внедрили единый управленческий контур EvaTeam , поверх системы настроили аналитический HTML-дашборд. Через API он собирает данные, помогает находить слепые зоны и принимать управленческие решения на основе фактической загрузки команды. В статье разбираем архитектуру решения, логику разделения поддержки и проектных работ, состав аналитики и результаты одного из ежемесячных отчётных срезов .
https://habr.com/ru/companies/evateam/articles/1059818/
#импортозамещение #jira #evateam #confluence #российское_по #atlassian #kanban #agile #консалтинговые_компании #консалтинговый_проект
-
Как «Первый Бит» выстроил прозрачный контур управления IT-командой на базе EvaTeam — российского аналога Jira
Как руководителю понять, чем занята ИТ-команда : сколько ресурсов уходит на поддержку, какие работы относятся к проектной нагрузке, где задачи остаются без оценки, а где назначены исполнители, но работа не движется? В компании «Первого Бита» для этого внедрили единый управленческий контур EvaTeam , поверх системы настроили аналитический HTML-дашборд. Через API он собирает данные, помогает находить слепые зоны и принимать управленческие решения на основе фактической загрузки команды. В статье разбираем архитектуру решения, логику разделения поддержки и проектных работ, состав аналитики и результаты одного из ежемесячных отчётных срезов .
https://habr.com/ru/companies/evateam/articles/1059818/
#импортозамещение #jira #evateam #confluence #российское_по #atlassian #kanban #agile #консалтинговые_компании #консалтинговый_проект
-
Как «Первый Бит» выстроил прозрачный контур управления IT-командой на базе EvaTeam — российского аналога Jira
Как руководителю понять, чем занята ИТ-команда : сколько ресурсов уходит на поддержку, какие работы относятся к проектной нагрузке, где задачи остаются без оценки, а где назначены исполнители, но работа не движется? В компании «Первого Бита» для этого внедрили единый управленческий контур EvaTeam , поверх системы настроили аналитический HTML-дашборд. Через API он собирает данные, помогает находить слепые зоны и принимать управленческие решения на основе фактической загрузки команды. В статье разбираем архитектуру решения, логику разделения поддержки и проектных работ, состав аналитики и результаты одного из ежемесячных отчётных срезов .
https://habr.com/ru/companies/evateam/articles/1059818/
#импортозамещение #jira #evateam #confluence #российское_по #atlassian #kanban #agile #консалтинговые_компании #консалтинговый_проект
-
„Wie sollen wir so unterschiedlich große Stories schätzen?" Das ist die falsche Frage.
Du machst sie nicht gleich groß. Du machst sie klein. Horizontal schneiden, bis jedes Stück für sich Wert liefert. Der Rest ist laufende Priorisierung: Was ist jetzt am wichtigsten? Das nach oben. In Kanban jederzeit änderbar, solange nichts angefangen ist.
-
„Wie sollen wir so unterschiedlich große Stories schätzen?" Das ist die falsche Frage.
Du machst sie nicht gleich groß. Du machst sie klein. Horizontal schneiden, bis jedes Stück für sich Wert liefert. Der Rest ist laufende Priorisierung: Was ist jetzt am wichtigsten? Das nach oben. In Kanban jederzeit änderbar, solange nichts angefangen ist.
-
„Wie sollen wir so unterschiedlich große Stories schätzen?" Das ist die falsche Frage.
Du machst sie nicht gleich groß. Du machst sie klein. Horizontal schneiden, bis jedes Stück für sich Wert liefert. Der Rest ist laufende Priorisierung: Was ist jetzt am wichtigsten? Das nach oben. In Kanban jederzeit änderbar, solange nichts angefangen ist.
-
„Wie sollen wir so unterschiedlich große Stories schätzen?" Das ist die falsche Frage.
Du machst sie nicht gleich groß. Du machst sie klein. Horizontal schneiden, bis jedes Stück für sich Wert liefert. Der Rest ist laufende Priorisierung: Was ist jetzt am wichtigsten? Das nach oben. In Kanban jederzeit änderbar, solange nichts angefangen ist.
