I worked for a company where management was truly convinced that it was cutting edge, state of the art, had best practices, etc. It was even ISO and CMMI certified, although no one outside of management could believe it (they lost those certifications later). The reality was complete chaos, with projects often running completely backwards (coding, testing, shipping, and only defining requirements after deployment, let alone design). Nothing was written down, everything was "obvious", and if you didn't understand, "talk to an architect" who'd explain it. Of course, while the different architects all said it was obvious, when pressed for details, they'd give different answers, so it depended on which one you talk to, resulting in different teams, and sometimes different people in the same team, working at cross or counter purposes.
And yet somehow, they always managed to always meet their internal metrics. That was, until the event. The event was a disaster at a customer site that took the company seven figures to address, as well as an external audit, with the customer choosing the auditor.
Suddenly, the company embraced Agile.
You'd think that a company that used what I referred to as lore based development would have a hard time doing that, but they did so swimmingly. And then the auditors looked at discovered the reason they'd transitioned so easily and quickly was because absolutely nothing had changed.
It was hilarious. All they did was rename what they were doing to the Agile terms, and called it a day.
One of the benefits of sprints is that once you commit to a task, that's what you do for the entirety of the sprint. However, that falls apart when people are pulled off to deal with a crisis. If you do, the sprint is considered corrupted. Unfortunately, pulling people off what they were doing to deal with crises was 90% of what people were doing. But that's okay, because it didn't affect reporting in the slightest.
Management happily reported that:
- in 52 weeks, there were 25 sprints
- every sprint was documented as 100% successful
- the teams were using Git and Jira successfully
- every sprint retrospective show successfully completion of all tasks assigned
The auditor discovered that:
- engineers came to work and were told to work on the crisis du jour
- sprint tasks were being assigned retroactively in the sprint retrospective ("what did you do?")
- the daily 90 minute (yes, an hour and a half) daily meeting was renamed to "standup"
The most hilarious part was the issue tracking. Despite using Git and Jira, the projects were managed by email chains, with all tasks tracked in "the spreadsheet" which was mailed around. Of course, different copies were made, got out of sync, etc. It was perfectly normal to discover that "issue 34" in one spreadsheet was "issue 38" in another, and two developers were working on the same thing without knowing about the other. Then someone would renumber things, and PMO would assign the urgent "issue 92" to someone, but when the engineer looked, issue 92 was a trivial graphics issue, with the critical issue now being 98, and no one looked at it, which wouldn't be discovered until the PMO wanted to ship the fix to the customer in an hour, and discovered know one had even looked at it.
Engineers who documented things in Jira were reprimanded for not updating the spreadsheet and emailing the PMO, because "PMO doesn't look at that crap". When the auditors asked to see the Jiras, the PMO said that they were using Jira 100%. And then the auditors looked at the actual tasks:
JIRA-SS1-7439: Task: issue #2890 in spreadsheet, assigned to Jim.
JIRA-SS1-7441: Task: issue #2923 in spreadsheet, assigned to Sarah.
JIRA-SS1-7459: Task: issue #3002 in spreadsheet, assigned to Michael.
There was no spreadsheet named, of course, let alone attached, or pointed to.
To quote one auditor's off the record comment: "Their development model appears to be a reverse waterfall method they call agile. Engineers internally call it Drunken Sailor"
This is not credible, the guy on the right in the final frame is depicted as an empathetic fella. These folks are usually only pathetic.
I told a scrum master that's too many meetings. They said it's not meetings, it's scrum ceremonies 🙄
*clears throat*
I LOATHE WORTHLESS STUPID MEETINGS!!!!!!!!!!!!!!!!!!!!!!!!!!!!
*grabs a throat lozenge*
I don't miss the days of multiple daily meetings.
...async...
Agile. Oh, Agile.
I worked for a company where management was truly convinced that it was cutting edge, state of the art, had best practices, etc. It was even ISO and CMMI certified, although no one outside of management could believe it (they lost those certifications later). The reality was complete chaos, with projects often running completely backwards (coding, testing, shipping, and only defining requirements after deployment, let alone design). Nothing was written down, everything was "obvious", and if you didn't understand, "talk to an architect" who'd explain it. Of course, while the different architects all said it was obvious, when pressed for details, they'd give different answers, so it depended on which one you talk to, resulting in different teams, and sometimes different people in the same team, working at cross or counter purposes.
And yet somehow, they always managed to always meet their internal metrics. That was, until the event. The event was a disaster at a customer site that took the company seven figures to address, as well as an external audit, with the customer choosing the auditor.
Suddenly, the company embraced Agile.
You'd think that a company that used what I referred to as lore based development would have a hard time doing that, but they did so swimmingly. And then the auditors looked at discovered the reason they'd transitioned so easily and quickly was because absolutely nothing had changed.
It was hilarious. All they did was rename what they were doing to the Agile terms, and called it a day.
One of the benefits of sprints is that once you commit to a task, that's what you do for the entirety of the sprint. However, that falls apart when people are pulled off to deal with a crisis. If you do, the sprint is considered corrupted. Unfortunately, pulling people off what they were doing to deal with crises was 90% of what people were doing. But that's okay, because it didn't affect reporting in the slightest.
Management happily reported that:
- in 52 weeks, there were 25 sprints
- every sprint was documented as 100% successful
- the teams were using Git and Jira successfully
- every sprint retrospective show successfully completion of all tasks assigned
The auditor discovered that:
- engineers came to work and were told to work on the crisis du jour
- sprint tasks were being assigned retroactively in the sprint retrospective ("what did you do?")
- the daily 90 minute (yes, an hour and a half) daily meeting was renamed to "standup"
The most hilarious part was the issue tracking. Despite using Git and Jira, the projects were managed by email chains, with all tasks tracked in "the spreadsheet" which was mailed around. Of course, different copies were made, got out of sync, etc. It was perfectly normal to discover that "issue 34" in one spreadsheet was "issue 38" in another, and two developers were working on the same thing without knowing about the other. Then someone would renumber things, and PMO would assign the urgent "issue 92" to someone, but when the engineer looked, issue 92 was a trivial graphics issue, with the critical issue now being 98, and no one looked at it, which wouldn't be discovered until the PMO wanted to ship the fix to the customer in an hour, and discovered know one had even looked at it.
Engineers who documented things in Jira were reprimanded for not updating the spreadsheet and emailing the PMO, because "PMO doesn't look at that crap". When the auditors asked to see the Jiras, the PMO said that they were using Jira 100%. And then the auditors looked at the actual tasks:
JIRA-SS1-7439: Task: issue #2890 in spreadsheet, assigned to Jim.
JIRA-SS1-7441: Task: issue #2923 in spreadsheet, assigned to Sarah.
JIRA-SS1-7459: Task: issue #3002 in spreadsheet, assigned to Michael.
There was no spreadsheet named, of course, let alone attached, or pointed to.
To quote one auditor's off the record comment: "Their development model appears to be a reverse waterfall method they call agile. Engineers internally call it Drunken Sailor"
I don't miss meetings that could've been an email. I don't even miss being invited. The only meetings I attend now are naps with me, myself, and I. 😴