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.

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

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

Ron Jeffries dials up self-organization and to 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.

"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?
Sometimes I wonder if everybody lives in startup land or has super engineering power. Sigh.

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