#scrum — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #scrum, aggregated by home.social.
-
Okay this might be a really weird question but I have one question regarding command-line-only workflows.
I am already used to and very comfortable working in the command line as is.
And as any heavy user of the terminal will know, at some point you'll probably start writing scripts and functions and aliases to create your own little shortcuts for common tasks or preferred program call-up options and such. So do I.
Now my weird little 'problem' is that I don't always remember all of the scripts, aliases, functions and even programs I built for my workflow over the years off the top of my head.
For example, I might have an "update" alias set up, but nine out of ten times will still enter the command manually out of sheer habit.
Or I will have a calendar or to-do application for the CLI/TUI, but sometimes forget that I have it installed when I need it. Or I'll forget where the files are I set up to organise my journal or my time tracking.
Or going even further, I don't always remember all the neat features of my shell I could use, or the computing/typing habits I wanted to build, or the projects I have going on, and so on!
In a graphical desktop environment or on a mobile UI, you have tools like desktop shortcuts, quickstart icons or application launcher menus for an overview of all of your environment's user-facing programs. Seeing an icon out of the corner of my eye sometimes reminds me of things that a purely reactive user interface like a shell doesn't.
Now there's obviously ways to solve this that come to mind:
- writing a script that prints comprehensive documentation on everything, so I only need to remember that one script name.
- keeping a physical cheat sheet next to my computer.
- using a terminal multiplexer to have a permanent digital 'cheat sheet' or 'launcher' open at the side of the screen.
- trying to just automate these things by using cronjobs/services and shell init scripts to, for example, show me the weather and my to-do list automatically on boot so i don't have to remember these commands at all
- trying to keep a super organised self-documenting file system and harmonious custom dotfile configs so every config is in the same place, every program uses the same keybinds, all scripts are in
~/.bin/or something etc. - writing my own "home page" type greeter.
… but with all of these solutions, while they may work perfectly fine, something doesn't feel "right"!
I mean it's nice and good to print these things upon shell start, but later on in the day that won't be there to look at anymore. The multiplexer one is cumbersome. The self documenting file system organisation sounds like a pain to maintain.
I feel like this is an issue that corporate folks probably should have solved by now, as documenting workflows for employee handovers and stuff is critical there too. Do they use wikis for that? What about all those newfangled workflows like #scrum and #agile and all, do they have anything to say about documentation?
Can anyone relate? How do you handle this?
#linux #unix #commandLine #terminal #cli #tui #tech #askfedi #technology #fish #zsh #bash #shell
-
-
Scrum Master Day 2026: Neuer Präsenz-Workshop und mehr Zeit fürs Sparen
Der Frühbucherpreis für die Online-Konferenz Scrum Master Day 2026 gilt eine Woche länger und neu im Programm ist ein Vor-Ort-Workshop in Köln.
-
Как перестать имитировать Agile и начать получать результат
На Хабре немало статей о том, почему Agile не работает. И в большинстве из них авторы справедливо отмечают, что ритуалы превратились в формальности, Scrum выродился в бюрократию, команды имитируют активность. Всё так. Я хочу поговорить про другое - про глубинные причины неудач во внедрении Agile и конкретные способы наконец-то получить от методологии тот результат, который она способна дать. Предлагаю пошаговый алгоритм, построенный на принципах поведенческой психологии. Он работает не с ритуалами и артефактами, а с тем, что действительно движет изменениями, — с людьми, их привычками и поведением. Эта статья — не про то, что Agile плох. Она про то, как сделать его работающим.
https://habr.com/ru/companies/smartvalues/articles/1069860/
#изменения #scrum #change_management #поведение #agileтрансформация #поведенческая_психология #процессы #управление_проектами #agile
-
Was Bakterien 🦠 besser machen als dein #Scrum-Team - Richard Seidl
Bugs zu vermeiden ist die falsche Strategie. Was Bakterien und Motten über Trends, Hypothesen und Robustheit in Software-Projekten lehren.
https://www.richard-seidl.com/de/podcast/resiliente-softwareprojekte-natur/ #Projektmanagement #ProjectManagement -
Почему Agile убивает стратегию, когда его масштабируют
Agile легко превращается в ловушку, когда спринты идут по плану, метрики растут, а стратегические задачи месяцами стоят на месте. Разбираемся, почему так происходит при масштабировании и где руководителю вернуть фокус на реальный результат.
https://habr.com/ru/companies/otus/articles/1068628/
#Agile #Scrum #масштабирование_Agile #стратегия #спринты #Velocity #Story_Points #управление_проектами #бизнесрезультат #стратегическое_управление
-
Software Testing: Was Bakterien besser machen als dein Scrum-Team
Die Softwareentwicklung kann sich von Strategien aus der Natur einiges abschauen, wie Anna Melbinger im Gespräch erläutert.
#AgileSoftwareentwicklung #IT #Journal #Projektmanagement #Scrum #Softwareentwicklung #Wirtschaft #news
-
🚧 A Developer mentions the same work four days running and still says "no blockers." Usually the team just doesn't share a definition of what an impediment is.
Working definition: anything that slows progress toward the Sprint Goal. Bad connection, interruptions, waiting on another team, broken builds, slow decisions, a poorly understood PBI. All impediments.
A trick: swap "impediment" for "slowdown," easier to admit. Then check the board for items stuck in one state for days.
An impediment you can't name is one nobody can remove.
https://agilepainrelief.com/glossary/impediments/?utm_source=mastodon&utm_campaign=archive-reshare
-
Fachbücher werden angefangen, nicht gelesen. Nach drei Wochen weißt du nicht mehr, wo du warst.
Seit dem Wochenende steht mein Buch komplett als Webseiten online. 34 Kapitel, jedes einzeln aufrufbar. Du hakst ab, was du gelesen hast. Die Suche geht über alle 43 Seiten. Und jeder Abschnitt hat einen Link zum Kopieren, wenn du einem Kollegen genau diese Stelle schicken willst.
Kostenlos. PDF und EPUB bleiben.
https://no-bullshit-agile.de/buch/?mtm_campaign=mastodon
#SoftwareEngineering #Programming #OpenSource #Scrum #Kanban
-
„Ohne Schätzung kann ich dem Kunden nichts sagen.“ Der Einwand ist berechtigt. Die meisten NoEstimates-Debatten gehen genau daran vorbei.
Nur: Der Kunde will ein Datum. Story Points sind keins. Zwischen der 5 und dem Termin steht eine Velocity, die ihr aus den letzten Sprints hochrechnet. Die hält, solange sich nichts ändert. Sie ändert sich immer.
Warum ich die Punkte trotzdem für den falschen Streit halte:
https://no-bullshit-agile.de/das-ende-der-schaetzung-warum-story-points-ueberbewertet-sind.html?mtm_campaign=mastodon -
Ein PDF verlinkt man nicht. Man schickt es rum, und drei Wochen später hat jeder eine andere Version.
Deshalb steht mein Buch jetzt komplett als Seiten im Netz. 34 Kapitel, jedes mit eigener URL, durchsuchbar, kostenlos, kein Formular, keine Mail-Adresse.
Wenn im nächsten Refinement wieder die Frage kommt, wer eigentlich entscheidet: Kapitel 11 verlinken statt eine Datei anzuhängen.
PDF und EPUB gibt es weiter.
-
Euer Team liefert alle zwei Wochen. Euer Geld bewegt sich einmal im Jahr. Ratet mal, wer gewinnt.
Organisationen sind auch Kapitalallokationssysteme, und diese Loop hat ihre eigene Frequenz: Jahresbudget, Business Case, Freigabe.
Feedback schnell, Entscheidung schnell, Delivery schnell, und die Erkenntnis bleibt folgenlos, weil das Geld erst in Q4 beweglich ist.
Operativ adaptiv, strategisch starr.
https://no-bullshit-agile.de/nbak13-kapital-kopplung-jahresbudgets.html?mtm_campaign=mastodon
-
In Folge 4 habe ich über Scrum als Management-Framework gesprochen. Fünf Jahre strikt nach Guide gearbeitet, dann diese Diagnose: der Blick geht aufs Projekt, nicht auf die Software.
Den Kern halte ich bis heute. Die Schärfe nicht mehr. Oben auf der Folgenseite steht deshalb ein Update von mir.
Was stehen bleibt: Ein Commitment auf Velocity trägt nur bei Arbeit, die ihr schon mal gemacht habt.
-
🎯 Setting your Sprint Goal as "finish all seven stories" misses the point.
A Sprint Goal is a single shared objective describing the purpose of the Sprint. "Finish the stories" says nothing about why the work matters. And it isn't imposed by the PO: the PO explains the business objective, the team negotiates what's feasible, and because everyone sets it, everyone owns it.
Struggling to set one is often a sign the business strategy underneath is unclear. Worth chasing, not skipping.
https://agilepainrelief.com/glossary/sprint-goal/?utm_source=mastodon&utm_campaign=archive-reshare
-
🎭 Too many Sprint Reviews are a Show and Tell: someone demos every corner of a feature while the room says "good job" and nothing substantive. The point is to increase engagement with stakeholders and users, and talking at people does the opposite.
Two fixes. Get key stakeholders (Marketing, Support) into Product Backlog Refinement so concerns surface early, not as an ambush in the Review. And replace Show and Tell with Show and Play: pair each developer with a user and let them actually use the product.
Nothing beats watching someone else use your app to see where they get confused.
-
⏱️ Shortly after ChatGPT 4o, people talked about doing Backlog Refinement in minutes with GenAI. Most have realized that's a bad idea.
Sprint Planning isn't about a tidy Sprint Backlog. It's the team building a shared understanding of the Sprint Goal, capacity, and how they'll get there. A faster event doesn't build that understanding, it skips it.
So don't ask how GenAI makes the event quicker. Ask how it helps the team spot what gets missed and go deeper. Stress-test the plan: yes. Write your Sprint Goal for you: no.
GenAI amplifies what you're already doing, good and bad.
-
Ich habe heute meine Dev-Serie umgebaut. Vorher stand alles Wichtige in der Übersicht, also hat niemand weitergelesen.
Acht Teile: Daily, Schätzen, DoD, Refinement, Tech Debt, WIP, Tickets, Vertrauen. Zu jedem der Satz, den du im Meeting sagen kannst, ohne als Querulant zu gelten.
Is eher lang. Eher Nachschlagewerk zum bookmarken und blättern.
https://no-bullshit-agile.de/agile-fuer-entwickler.html?mtm_campaign=mastodon
-
@midzer schrieb, Scrum sei ein brutaler Scam, erfunden von Krawatten.
Ich halte den Satz für falsch. Die Wut dahinter für berechtigt.
Die meisten Devs, die agiles Arbeiten hassen, haben es nie erlebt. Sie kennen das Daily als Statusreport für den Chef und die Schätzung, aus der eine Deadline wird.
Ich hab fünf Jahre Scrum nach Lehrbuch gemacht und es sein lassen. Warum es trotzdem nicht an dir liegt:
https://no-bullshit-agile.de/es-liegt-nicht-an-dir-agiles-arbeiten-devs.html?mtm_campaign=mastodon
-
🧱 I met a team where the client was the Product Owner. The backlog didn't make sense to them, they'd never seen a vision or strategy, and yet they wanted more features, faster, now.
The product looked like a Jenga tower about to topple.
Being a Product Owner is a craft: own the vision and strategy, order the backlog, understand users, security and usability, build a rhythm with the team. Clients usually just want to know it works.
So make your client a stakeholder, not the PO. A good PO solves the client's problem while holding the big picture, not just the next feature.