Holger

Whenever I read an article about epics vs. user stories, even if it's a good one like this one from Kent McDonald on "epic confusion" (agilealliance.org/epic-confusi) , I can't help but think about this Geek&Poke comic about Advanced Scrum: geek-and-poke.com/geekandpoke/

0
Holger

Great list of signs that you're working in a feature factory: mdalmijn.com/14-signs-youre-wo
From experience, I can only agree to most points. However, I don't agree to the argument that this is Scrum's failure.

1
Holger

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).

heise.de/hintergrund/Agile-Ent

0
Holger

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.

charleslambdin.wordpress.com/2

0
Holger

Gregor Hohpe is starting an article series about and . 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."

architectelevator.com/transfor

1
Holger

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.

leaddev.com/debugging-engineer

1
Holger

That's a nice collection of resources:

github.com/lorabv/awesome-agil

0
Holger

"The daily meeting" or: another description of the awful mess that is often created out of the well-intended 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?

industriallogic.com/blog/the-d

0
Holger

Mary and Tom Poppendieck would prefer "engineering" over . 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."

builtin.com/software-engineeri

1
Holger

So, next week I'll have to organize my first . 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: scrum-master-toolbox.org/2020/

0
Holger

This discussion with Esther Derby on is probably also worth watching: retrium.wistia.com/medias/fr07

0
Holger

The FH Koblenz is running its fourth study "status quo agile", this time with a focus on scaling : hs-koblenz.de/en/rmc/fachberei

0
Holger

Good new scale for estimation proposed: 1, too big, no clue.
agilealliance.org/estimation-a

0
Holger

Ron Jeffries dials up self-organization and to twelve: ronjeffries.com/articles/019-0

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.

0
Holger

Rules of Thumb for Agile Coaches estherderby.com/2019/07/rules-

A pretty good read and reminder what coaching is abour.

0
Holger

"This team has three developers. A developer can normally deliver 5 story points per Sprint, so the team velicity is 15."

Yikes, where do I even start explaining how wrong this is? Maybe by pointing out the team has also testers?

0
Holger

industriallogic.com/blog/redef
Sometimes I wonder if everybody lives in startup land or has super engineering power. Sigh.

0
Holger

Interesting experience report on .
dominikberner.ch/getting-safed

0
Holger

Hello functional.cafe. I'm a freshly arrived , with interests in , -architecture and .

1

clojure

53

sailfishos

21

emacs

19

agile

19

lisp

13

debian

10

security

9

python

7

privacy

6
Functional Café

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!

Resources

Developers

What is Mastodon?

functional.cafe

More…

v3.5.1+glitch · Privacy policy