Holger @schaueho@functional.cafe
- Languages
- German, English
Living in Germany, interested in #clojure, #softwarearchitecture, #agile, #emacs, #opensource, #nlp, #security and #privacy.
Great list of signs that you're working in a feature factory: https://mdalmijn.com/14-signs-youre-working-in-a-scrum-feature-factory/
From experience, I can only agree to most points. However, I don't agree to the argument that this is Scrum's failure.
#agile
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).
https://www.heise.de/hintergrund/Agile-Entwicklung-Gutes-Schaetzen-geht-auch-remote-4946004.html
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.
https://charleslambdin.wordpress.com/2020/03/12/is-cd3-the-golden-key/
Gregor Hohpe is starting an article series about #agile and #architecture. The first article here gives an intro and outlines a little bit where he's coming from:
"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."
https://architectelevator.com/transformation/agile_architecture/
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.
https://leaddev.com/debugging-engineering-velocity-and-leading-high-performing-teams
That's a nice collection of #agile resources:
"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."
https://builtin.com/software-engineering-perspectives/lean-agile-methodology-software-engineering
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/
#agile #wfhlife
This discussion with Esther Derby on #remote #retrospective is probably also worth watching: https://retrium.wistia.com/medias/fr07x6xp7h
#agile #wfhlife
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.
https://www.agilealliance.org/estimation-and-forecasting/
Ron Jeffries dials up self-organization and #agile to twelve: https://ronjeffries.com/articles/019-01ff/twelve/
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
A pretty good read and reminder what coaching is abour. #agile #coaching
https://www.industriallogic.com/blog/redefining-done/
Sometimes I wonder if everybody lives in startup land or has super engineering power. Sigh. #agile
Interesting experience report on #SAFe. #agile #scaledagile
http://dominikberner.ch/getting-safed/
Hello functional.cafe. I'm a freshly arrived #googleplusrefugee, with interests in #clojure, #software-architecture and #agile.
- Languages
- German, English
Living in Germany, interested in #clojure, #softwarearchitecture, #agile, #emacs, #opensource, #nlp, #security and #privacy.
