Optimizing for secondary virtues
When your environment claims or strives to be agile, you will probably stumble over an interesting pattern: Many people who identifiy with the agile approach, will also give you simple, straightforward advice (or rule-like guidelines) on how you can be agile. Such advice typically revolves around things like sprint-lengths (god forbid if they are longer than two weeks), the stand-up meeting (everyone should be there, and it should be < 15 minutes), or the kanban/task board (each day you should see some movement there).
What you typically do not hear (at least so infrequent that it isn’t worth mentioning) are quotes from the agile manifesto like
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
or the Scrum Guide, that can tell us about sprint lenghts
The heart of Scrum is a Sprint, a time-box of one month or less during which a ``Done'', useable, and potentially releasable product Increment is created.
Yet when teams struggle with two-week sprints, you still hear agile evangelists insisting on two-week sprints, instead of suggesting the team to deliver work in frequent increments and test what time-scale is suitable in their current situation and go on from there.
Similarly, for the daily standup meeting, the Daily Scrum, the the scrum guide is very clear that this is a meeting where the development team (which does not include the PO or the SM) plan their work.
The Daily Scrum is an internal meeting for the Development Team. If others are present, the Scrum Master ensures that they do not disrupt the meeting.
Yet, many agile enthusiasts will insist onhaving a reporting meeting with individuals reporting in 1-2 minute time boxes.
Second hand virtues
We observe these behaviours, because it is easy to focus on secondary virtues which are easy to remember, than on primary virtues, which are harder to remember or to achieve. Pointing out that the team did not deliver within a two-week time window is easy, finding the right fit between sprint duration and work-complexity is hard. Focussing daily on conducting a meeting for the benefit of the development team is hard, conducting a daily reporting meeting with a 15 minute time box is easy.
The huge problem with focussing on seconday virtues is, that the primary virtues are forgotten, and then, the secondary virtues lose their benefit, because they start to disorient, instead of support people in their pursuit of the primary virtues.
How to break the cycle
My hypothesis is, that a lot of secondary virtues are just simpler to remember and apply. More important but more complicated guidelines are forgotten or deprioritized in favour fo the easy-to-remember rules.
This is why we see Scrum Masters fighting 4-week-sprints with tooth and nail, while they remain fairly silent on sprints and stories without value delivery.
This is also why we see teams conducting Daily Scrum meetings that do not help the development team delivering value, but we see a reporting meeting with tight time-keeping.
What can we do about it?
The first step is to rediscover the intent of the recommendation, reading the primary and early sources. Then, you can start looking for obvious contradictions between the way you work and (a) the primary sources and (b) your model of well-organized and successful work. These are the starting point for meaningful change and experimentation. Is it helpful to conduct longer sprints? Are sprints themselves helpful to delivering value frequently? How would the developers prefer to communicate and organize their work? How can the standup become their meeting?
We are uncovering better ways of developing software by doing it and helping others do it.
If you are working in an agile team, you must be given the leg room to explore, inspect and adapt - just as the signatories of the agile manifesto did.