Guter Artikel über agiles Schätzen in verteilten Teams / Remote-Situationen. Sind ein paar nützliche Tools erwähnt, aber auch ein paar gute Vorgehensweisen (wie etwa das Mapping-ähnliche Vergleichen von Größen).
I have too often seen that "agile" mostly means "let's drain more water from the waterfall", ignoring everything outside of the development work. This article here has a nice "urgency" chart which depicts an all too familiar situation where time passes for a long while in the decision and planning phase, only to generate a lot of pressure on the delivery team. In other words: the overall cost of delay of a feature is a function of the overall lifecycle, not only of the development. A devops initiative might be completely wasted.
"So, agile and architecture are addressing the same problem from different angles: architecture gives you the options to sustain velocity when the unexpected happens. And agile gives you the attitude to always be learning and to quickly adapt to changing circumstances."
Interesting article on high performing teams. The most interesting thing for me here is the assumption that the teams in question has lots of ownership (the article focuses on purpose and assumes competence and autonomy). Unfortunately I think that this assumption is wrong for lots of orgs and teams.
"The daily meeting" or: another description of the awful mess that is often created out of the well-intended #agile ideas.
"Simultaneously, online Agile Lifecycle Management (ALM) tools became popular. The most popular of these began life as trouble ticket systems, adapted by mapping a backlog item or user story onto a problem report with a unique ID.
As a result, workers use the unique "story" ID as shorthand, to get their part of the status report done quickly. They were assigned ticket numbers, worked on the numbered ticket, reported status of the ticket, and that became the language of the translated agile world.
This has a hidden cost: In most teams, nobody knows what their peers are really working on because they only know their own ticket numbers, and only for the ticket or tickets they are currently working on."
Been there, seen that. It's awful. How much more meaningless can work become than being responsible for a number?
Mary and Tom Poppendieck would prefer "engineering" over #agile. The main point here is captured in these two quotes:
"Agile has come to mean anything but the fundamental, underlying technical capability necessary to do really good software engineering.” [...] "Being good at things, it seems, is Mary’s current creed. Buzzwords come and go, she repeated, but smart, technical problem-solving will never feel dated."
So, next week I'll have to organize my first #remote #retrospective. Expect me to drop some links here as I try to dig a bit deeper into the topic. Let me start with this brief overview from the Scrum Master Toolbox: https://scrum-master-toolbox.org/2020/03/blog/facilitating-remote-retrospectives-for-recently-distributed-teams/
The FH Koblenz is running its fourth study "status quo agile", this time with a focus on scaling #agile: https://www.hs-koblenz.de/en/rmc/fachbereiche/economics/forschung-projekte-weiterbildung/forschungsprojekte/bpm-labor/status-quo-scaled-agile-2019/
Good new scale for #agile estimation proposed: 1, too big, no clue.
A lot here is about putting more emphasis on the team taking responsibility for everything, not only for coding and testing. The problem is that some people just are not interested in these things at all and are happy to just code away. On the flip-side of the article, technical quality is not in focus at all.
To me, this doesn't sound like it's solving the issues with a lot of agile implementations.
Rules of Thumb for Agile Coaches https://www.estherderby.com/2019/07/rules-of-thumb-for-agile-coaches.html
Sometimes I wonder if everybody lives in startup land or has super engineering power. Sigh. #agile
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!