71–80 of 298 posts
Scrum/Agile is awesome! I always used the daily calls to ask as much dumb shit as possible to make the meetings as long as i could so i could keep charging my hourly rate without actually working.
For anyone who's read 37signals development methodology (in Shape Up), how does it compare to other common dev methods?
Earlier quoted context omitted.
The amount of time lost to doing Scrum things was so out of control that some people had fewer than 3-4 hours per day to actually work. If the aggregate of the sprint planning, backlog refinement, retro and dailies is more than 10% of the total time (eg 1 full day out of a 10 day sprint) for most of the team then something bizarre is going on. If the everyone is losing 50% of their time to agile things then your proc…
Until you're on 4 teams
It's interesting to speculate on why, if Scrum is so bad, everyone uses it? Is it because everyone is an idiot (e.g. management)? Or for some nefarious reason? Or maybe it isn't actually that bad? On one project I was on, there was a contractor company billing millions per year to create a React admin tool frontend. Many developers involved, Scrum master full-time, and so on. Tickets were created for small parts of f…
For me, I'm a senior technical leader now and my entire professional career has been Agile and Scrum. I haven't been exposed to other techniques.
Better not upset the apple-cart, we all know how it works, and besides, it's the defacto for a reason... right? (this is tongue in cheek but to be fair, I make decisions like these subconsciously all the time; "why do CI/CD", "Why use GIT as SCM", "Why do peer review/MRs" --- because I always have and it seems good enough on the surface)
"Way of work should be defined at a team level by its people, not by the company." - This is basically the origin of scrum. Essentially every problem ascribed to scrum is its departure from this origin story. Scrum is about making each team work better, but somehow it turned into the same weird top-down imposed structure that it was supposed to replace. 2 week sprints are mandatory for all teams? They all have to sta…
I added up all of the time we were spending in Scrum-related activities at a recent job. The company hired a lot of project and program managers who were pulling everyone into everyone meeting. I presented the number of hours (meetings multiplied by engineering participants) to our VP and he insisted I must be wrong. He insisted there was no possible way we could be spending that much time doing Scrum things and that…
The last org I was in realized how much time their engineers were spending in agile-caused meetings, much like what you describe, at least half of the working hours in a week - so they made a company-wide rule that no one could spend more than 4 hours a week in meetings. What happened instead were impromptu "ghost" meetings and a ton of stuff done sloppily over chat instead, where I think the hope was that people wou…
Required meeting attendees should consist of the Rs... and only the Rs. As and Cs can be optional, but meetings can conclude without them.
Everyone not in the meeting can be updated out of band.
"What action is this person taking in this meeting?" should be a brutally honest question. If the answer is only "listening", then it's a waste of their time.
And also, related point: what is the termination condition of this meeting? And has that been decided and communicated beforehand? I.e. What outcome are we seeking, that when done everyone agrees the meeting is over?
I can't stand agenda-less, "we're meeting to move something forward in some undefined way" meetings.
The disease is KPIs and metrics, and I'm betting it has gotten worse since COVID and WFH.
As the article states, teams have to focus on capturing every iota of work in tickets and stories and make sure they log the closures correct ly and tie every task to a greater story.
Scrum tools and pointing and tickets should support the goal of writing functional software. But when middle management demands 15 different KPIs determined by various calculations of time, estimates of effort and # tickets closed, the tickets/stories/epics become the goal, and development is the sideshow.
Before my devops role in 2019/2020, I was on a security operations team. We did our version of Kanban. It was simply organizing all our bigger goals/projects (initiatives with a definable end state) into backlog, doing, blocked, done. Operational tasks were worked on without documentation (daily software patches, on call tasks, etc) and small tasks from external teams were documented with a ticketing system and a 3 day SLO. A breach of SLO was not measured in any reporting! It was a good-faith goal that we met most of the time, and if it were breached and the external team got angry they could escalate to our manager.
The point is, the tools we used were made for the team's benefit of productivity and organization, without manager-observed KPIs. We just got shit done.
I added up all of the time we were spending in Scrum-related activities at a recent job. The company hired a lot of project and program managers who were pulling everyone into everyone meeting. I presented the number of hours (meetings multiplied by engineering participants) to our VP and he insisted I must be wrong. He insisted there was no possible way we could be spending that much time doing Scrum things and that…
I don't think it's helpful in any discussion to try and pre-emptively dismiss people who might disagree. People have been doing that for the decade or so scrum has been mainstream and it just dumbs the discussion down to he-said she-said.
That being said, agile as it was originally described in the manifesto was not prescriptive, and scrum, while it was intended to follow in its footsteps, has been a victim of its own success. It's now firmly in the domain of other highly-prescriptive management frameworks thanks to the effort of consultants and managers who adhere strictly to the letter of scrum without paying thought to the essence of it.
Most people I know who were fans of scrum back in the day have distanced themselves from it because it's not agile any more. Certainly not with consultants selling SAFe as an agile methodology.