[a_square_peg]

Wonder how 'Sprint', 'Scrum', 'Kanban' etc. all evolved out this? I really can't understand how it went from 'individuals and interactions over processes and tools' became formalized processes of daily standups, 2-week sprints, etc.

[ryathal]

Scrum came from a world where product folks and developers never directly talked to each other. Everything was a formal written request with some requirements and there were SLAs for how long developers could look at it before providing questions and estimates back. After one (two if you're lucky) round(s) of questions a deadline is established, and work begins.

In that world, creating a single product owner that had the full complete say of this is what will happen that met with developers on a daily basis is a huge improvement of individuals and interactions. This is the single biggest win of Scrum, getting people to just talk to each other regularly, by having mandatory meetings all the time. If an organization has good communication or a product is too large for a single person to manage, Scrum ceases to be as useful option.

[nine_k]

Kanban came from elsewhere. The word comes from post-war Japanese car factories, but the principle is older. Kanban boards were physical boards, with tokens representing various machines' or workers' availability, and the presence of things to work on. It's more a work-scheduling mechanism for known, understandable, repeatable work.

https://en.wikipedia.org/wiki/Kanban

[a_square_peg]

Interesting to know - thanks for the info. Strange to think that something designed for 'known, understandable, repeatable work' got adopted by software development.

[nine_k]

Some software-related work, like regular changes to a website, or regular SRE work, is understandable and relatively repeatable.

Software development work usually isn't. Software development, by its nature, automates away everything repeatable and predictable, so unpredictable and never-before-seen stuff dominates.

[The_Colonel]

Manifesto came out in 2001, you need to take into account the context of that time - the processes were often much more heavy-handed (esp. in big companies) than they are now. This manifesto item was never about not creating any processes.