Reply to u/Hileotech at https://www.reddit.com/r/Zettelkasten/comments/17dp8nl/zk_system_for_project_and_task_management/

They don't have the same structure as Luhmann's zettelkasten (they don't really need to and may frankly work better without them), but index cards were heavily used in business and project planning settings for decades prior to the popularization of the computer.

I've documented one productivity method from 1903 called the Memindex which was a precursor to things like the Hipster PDA, the Pile of Index Cards, and 43 folders methods which have been popular since the early 2000s. Details and pointers can be found at The Memindex Method: an early precursor of the Memex, Hipster PDA, 43 Folders, GTD, BaSB, and Bullet Journal systems. Addition details can also be found at A year of Bullet Journaling on Index Cards inspired by the Memindex Methodas well as in the comments.

Index card-based project management techniques with items broken out by task can be used to create physical Kanban boards or even arranged in Gantt chart-like fashion on walls, bulletin boards, or tables.

Kanban vs. Scrum: What's the Difference?

https://www.3m.co.uk/3M/en_GB/post-it-notes/ideas/articles/make-the-leap-from-to-do-to-done-with-the-scrum-methodology/

"The Scrum method" described here, similar to the Kanban method, the Memindex method, tickler systems, or other card index as productivity systems, seems to be a productized name for selling Post-it Notes.

Scrum method consists of a project broken down into "story" rows with "to do" items in columns which progress along to "in process", "to verify", and finally "done".

Other productized names (particular to the note taking space): Antinet zettelkasten, Linking Your Thinking, Second Brain, etc.

با اسپیس از طریق فیلتر های مختلف (تگ و ... ) میتونی aspects های مختلف کار رو ببینی و دنبال کنی

کانبان برای بهینه سازی و دیدن Work Flow هست ، خیلی بهتر است که برای هر کار مخصوص ، یک ورک فلو جدا داشته باشی! یا بهتر بگم هر پروژه!

فضاهای مختلف برای هر ایتریشن ، بک لاگ ؛، و....

my takeaways

• Sprint is a form of limiting WiP; Sprint Backlog is an explicit WiP limit policy

• Limiting WiP decreases Cycle Time because wait time and task switching are minimized

• WiP is a leading indicator of Cycle Time, and the latter can be a leading indicator for Throughput

• self management means that Developers choose PBIs for the Sprint Backlog in collaboration with the Product Owner;

• flow debt is borrowing work time from other items to prioritize an item in progress → it results in the increase of the age of other items in progress

my takeaways

• SLE is set by the team for the team → purpose is to inspect and adapt the workflow in the Daily Scrum and the Sprint Retrospective;
• hence, the SLE is not a commitment or a promise, especially not to an outside stakeholder
• "We basically learn about the increased risk to specific items the more time passes without them completing. Common sense, no? The idea is that by visualizing these items and that growing risk we can focus the team's tactical inspection and adaptation during the Daily Scrum on tackling these risky items."

my takeaways from the Kanban Guide for the Scrum Teams

• kanban = a strategy for optimizing the flow of value through a process that uses a visual, work-in-progress limited pull system

• kanban can enhance/augment the work of the Scrum Team as described in the Scrum Guide

• flow = the movement of value throughout the product development system

• empiricism in Scrum in Kanban - besides being used to inspect and adapt the Product Increment - is used also to make transparent, inspect and adapt the workflow → make the workflow policies (how do we get things done) explicit (i.e. transparent) → use flow metrics in Scrum Events to inspect → adapt experimentally → run again :)

• basic flow metrics: Work in Progress; Cycle Time; Work Item Age; Throughput (check my other notes, especially the one(s) tagged with metrics for more detail)

• Little's Law [average Cycle Time = average WiP / average Throughput] → we can shorten the CT by decreasing the WiP limit; Throughput is mostly constant, i.e. hardest to change

• Kanban Practices for Scrum Teams

• visualisation of the Workflow (on the board);
• limiting WiP (by imposing limits for all the "doing" columns, i.e. all the columns between start and finish points of the workflow) → WiP items are Product Backlog Items rather than tasks;
• active management of work items in progress (pulling new work items at about the same time that they leave workflow; ensuring that work items pulled in don't age unnecessarily; responding quickly to items blocked or aged too much);
• inspecting and adapting the team's Definition of Workflow (visualisation policies and how we work policies).

Definition of Workflow = a set of explicit policies of how do we get the work done → shared understanding improves transparency and enables self-management → defined by the Scrum Team

impact of Kanban on Scrum Events 1. Sprint - per def it's a WiP limit (definite number of PBIs get pulled into Sprint Backlog - each PBI is a work item) - opportunity for both product and process(es) inspection and adaptation - multiple releases of increment are possible 2. Sprint Planning - reviewing historical Throughput enables understanding capacity of the Scrum Team 3. Daily Scrum - focus on establishing a consistent flow, by holding the meeting around the kanban board; - check on the blocked items and how to unblock them; slow items and items violating their SLE; consider factors which can impact the work and are not represented on the board; have ve learned anything new that might change what Scrum Team has planned to work next; is Wip limit being respected 4. Sprint Review - reviewing Throughput enables Product Owner to discuss likely delivery dates; 5. Sprint Retrospective - metrics enable discussion on improvement of processes; - inspection and adaptation of Definition of Workflow for the next Sprint - regular cadence of flow optimization reduces complexity and improves focus, commitment and transparency.

Increment is impacted by the fact that short feedback loops for processes make it possible the Scrum Team to identify bottlenecks, constraints and impediments to enable this faster, more continuous delivery of value.

my takeaways

• leading indicators (Work Item Age) are relevant for non-finished work, while lagging indicators (Cycle Time, Throughput) are relevant for finished Items

• kanban metrics are of use in the Scrum Events

• in Sprint Planning the key metric is Throughput, complemented with Work Item Aging for planning on work regarding leftover work from previous sprints.
• in the Daily Scrum Devs concern themselves with the WiP and Work Item Aging.
• Sprint Review revolves around Throughput, complemented by WIP and Cycle Time.
• in Sprint Retrospective we focus on Cycle Time, Throughput & WIP, while taking a look also at Work Item Aging.

Work in Progress

= a number of work items started but not finished - start and finish are defined by Scrum Team's Definition of Workflow - an explicit policy that serves as a constraint to help shaping of the flow of work - historically visualized through the Cumulative Flow Diagram

Cycle Time

= time elapsed between when a work item starts and when it finishes - start is when the work item is pulled into the workflow - CT is a lagging indicator visualised in a Cycle Time Scatterplot from which we can read trends, distributions, and look at the anomalies - enables us to come to the *Service Level Expectation (=amount of time that we expect a work item to be finished in)

Throughput

= number of work items finished per unit of time - exact count of items, regardless of their size - measured usually at the finish line of the workflow - visualized either at a separate run chart, or as the angle of curves on a Cumulative Flow Diagram - can be read out of the Cycle Time Scatterplot as well → !is not velocity!

Work Item Age

= time elapsed between moment when the work item has been pulled into the workflow (=start) and the current time - complemented with Cycle Time it can show us which items are doing well and which are late - Work Item Age is the best metric to look at if you want to determine when an item that has already started is going to finish

my takeaways

kanban is a pull system = the team pulls the items into its workflow, instead of having them pushed by the management or any other instance.

kanban core practices

1. visualize the work, workflow, and risks to flow/value delivery;
2. limit WiP;
3. manage flow;
4. make process(es) & policies explicit;
5. implement feedback loops; improve collaboratively, evolve experimentaly.

visualisation

• regards both work going into and out of Sprint;
• we visualise the flow of PBIs rather than the tasks;

WiP limitation

• regards PBIs being developed at the time;
• Sprint is a WiP limit (i.e. Developers *pull PBIs into Sprint Backlog);
• Kanban boards for Scrum Teams limit WiP per different stages of development process rather than having just one summary WiP limit for all categories of "doing";
• Wip limits should be low enough to introduce pain → that pushes the Team beyond comfort zone which forces teamwork and drives deep collaboration;

flow management

• monitor aging/stallenes of work items;
• focus on the healthy flow of work;
• to increase the flow teams should look to release as soon as the work is ready;

explicit precess(es)

• enables empowerment through increased transparency;
• enables inspection on "why do we do things this way?" or "how will a change affect the flow or the results?";
• most explicit policies in Scrum are the Definition of Done and the Scrum itself. another policy is the visualisation of work (columns on the kanban board), visualization of blockers, work prioritization etc.

feedback loops

• data-driven Sprint Retrospective

collaborative improvement, experimental evolution

• models and scientific method can guide empirical evolution of the Scrum Team;
• planning of the aims/goals and methods of their validation;
• constant review (in the Retros) of the results and decide whether further experimentation is needed, or the chane can be deployed as a standard operating policy

Examples include a separate Kanban board for - camping tasks - home-based tasks - Obsidian management - such as organize old files in database

ساده سراغ اسکرام نمی ریم میریم سراغ کانبان،

Cosa sono le metodologie Scrum e Kanban?

Si tratta di due metodologie che rendono concreti i principi alla base dell'Agile.

sprintless scrum

Would be interesting if Hypotesis and Zotero could be integrating by making the first support the annotations in the second (which means also working offline). Some times you annotate something and find a link to another annotation from another author in other document. This kind of cross-linking is difficult now in Hypothesis.

¿Podría haber un formato para determinar los permisos y datos que requiere una cookie, similar a como lo hacen las aplicaciones móviles que indican qué permisos requieren del usuario antes de instalarse? ¿Cómo puede ser esto extendido a aplicaciones de escritorio?

Se podría invitar a una figura (política por ej) de relativo renombre a que maneje su presencia en línea desde un lugar como los de Indie Web (Mastodon, Known, etc) y mirar qué ocurre con sus redes de seguidores. ¿Alguno migra a una nueva red para tener interacciones ampliadas con dichas figuras?

[K:] Revisar este documental.

Rafi Santo's (2011, 2013) "hacker literacies" similarly positions hacking as enabling critical thinking within a framework of media literacies.

¿Qué es lo que "falla" en el caso de Grafoscopio?¿Cuáles son las tensiones presentes?

Uno podría pensar que tiene que ver con la velocidad con que la comunidad, en general, adquiere la experticia que le permite poner a diálogar lo simbólico, con lo icónico y lo enactivo. El hecho de que algunos asistentes vengan reiteradamente, pero no transiten caminos que les ayuden a adquirir esa experticia por sí mismos. Dichas tensiones ayudan a mantener el proyecto real, al mismo tiempo que dan cuenta de posibilidades futuras de las que la comunidad se encuentra sembrada. Creo que pueden ir en la tradición de revisar las fallas, como ocurren con los hackerspaces feministas y pueden hacerse más explícitos en futuras ediciones del Data Week.

Chévere revisar los mitos y ficciones en Xerox PARC.

themeselves in relation to the group. “The process of becoming such an established maker seems to rely less on inherent abilities, skills, or intelligence per se, and more on adopting an outlook about one’s agency”

Esto ha pasado con el Data Week y Grafoscopio y está vinculado a comunidades de práctica y lo identitario.

Se puede empezar por acá la caracterización de lo hacker!

Aplazar la caracterización de la cultura hacker fue benéfico, pues este texto dialoga con otros que estaban puestos en el esqueleto.

Concentrarme en la dualidad dinácas y artefactos y su visualización es mejor por lo pronto.

Didn't know that I suffer from the Zeigarnik effect.