Years ago when I was a Scrum Master for a great team we had a ritual. Right before the Daily Scrum, we would walk to our tea/coffee station and fill up our cups with our choice of drink and then walk back to our Jira board to inspect our progress. And I assume, a lot of other teams also do the same.
Years ago when I was a Scrum Master for a great team we had a ritual. Right before the Daily Scrum, we would walk to our tea/coffee station and fill up our cups with our choice of drink and then walk back to our Jira board to inspect our progress. And I assume, a lot of other teams also do the same.
This article is not for teaching anything new about Scrum but sharing an observation from an everyday life workplace which applies the same principles as Scrum.
The usual questionsOften when I am teaching one of Scrum classes someone asks - can Scrum be applied outside of software development? Someone states it is only for the ideal world and not for the real application. And then there is someone else who likes to share how they make their grocery runs using scrum. All different perspectives, all valid to some extent.
I answer such questions/remarks from a place of curiosity. What they intend to achieve by applying scrum in their context and then focus on driving the idea of principles over practices.
The Agile ManifestoScrum has been around before the manifesto was drafted and yet I was introduced to Scrum as an approach under the agile umbrella along with many other approaches. That was an exact image in the Scrum class I attended back in 2013. And consciously or subconsciously that image remained stuck in my learning for a long time. Even today I see a lot of Scrum Masters making posts on social media that have the same image and probably draw the same parallels which I used to have.
Now, the agile manifesto clearly starts with the heading - Manifesto for Agile Software Development. So if you are into software development then surely agile is for you. And because Scrum is quite often put under that umbrella, it is considered only for software development. I have observed many organizations drawing a strict line - if it is support work, use kanban; if it is software development use Scrum.
In context
- Topic: Proyectos, PMO y Riesgos — Gestión de proyectos, oficinas de proyecto y riesgo del portafolio.
- Source: Scrum.org
- Published: 14/09/2026
Continue reading at the original source →
Excerpt published automatically by the site radar. The full text belongs to its publisher and is linked above.
Why it matters
Projects rarely fail on the day they are declared failed. They fail months earlier, in a meeting where somebody saw the problem coming and calculated it was not in their interest to say so. Everything else — the slipping schedule, the stretching budget — is the visible consequence of that silence.
I read these things looking for where the risk sat before it became an incident. It was almost always already written in some register nobody reviewed, with an assigned owner who never found out they were one. A risk identified and not managed is worse than one never identified: it creates the false sense that there is control.
What usually goes wrong
Where it usually breaks is the handover to operations. The project is declared finished when it is delivered, not when the receiving area can sustain it. Three months later the team has dissolved, nobody documented anything, and operations lives with something it does not understand and cannot change.
What to watch
- The size of the first useful delivery: the further out it is, the more it resembles a bet.
- How it was estimated and how close the same organisation's previous estimates turned out to be.
- Who the sponsor is and how often they actually show up — not on the org chart, in the calendar.
How I read this entry
If this landed on my desk, the first thing I would ask for is not percentage complete: it is the list of pending decisions with a name and a date. A percentage can be dressed up; a decision stuck for three weeks with an identified owner cannot be argued with, and it explains the delay far better.
This entry is an excerpt from the original source, selected by the site radar. The commentary above is the site's own and does not belong to the cited publisher.
Comments
No comments yet. Yours can be the first.
Living through this in your own team?
Open the chat and tell me how you're handling it. I'm interested in comparing notes.
