5 ms·
Couldn't agree more. Just quit my job of last six years the previous week. I really liked the team and the product. We had a very informal development process -
by vesinisa 6y ago
Couldn't agree more. Just quit my job of last six years the previous week. I really liked the team and the product. We had a very informal development process - we all agreed it was agile but not through following any formal process (Scrum or such).
We still had retros and dailies. Planning was done by managers explaining a feature they'd like us to do, and the team then doing the planning, design and implementation. More processes and e.g. recurring meetings were erected and torn down based on the team's actual needs alone. If someone wanted an estimate, we'd give it, but we were not doing continuos estimation just for the sake of estimation itself, like in Scrum. Felt like the process served us, rather than us serving a process. If you'd taken a look at the Agile manifesto, we were ticking pretty much all the boxes: https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html
Then 1.5 years ago, company decided to roll out whole IT department wide SAFe, which is basically Scrum but on a whole organization level, and hence even more bureaucratic and with one additional level of mega-iterations added on top of Scrum's sprints.
Suddenly, our team is assigned a Scrum master and we no longer even get to speak directly with the managers who previously negotiated new features with us. Instead, everything has to go through multiple levels of prioritization and broken telephones of new SAFe intermediaries. We started attending 2-3 new mandatory processes / recurring meetings, meaning time spent in inefficient boring meetings went up significantly. We had to also start a much more stringent ticketing system regime, including having to estimate ALL work. Despite multiple requests from Scrum master and managers, nobody was ever able to explain why estimating absolutely everything - even when nobody had even asked for an estimate - helped with anything. It was seemingly taken as a religious thesis that it was just the right thing to do.
Soon, the team was paralyzed. Even simple features became harder and harder to develop. Despite the massive effort spent on estimating even the most trivial of tasks, the big picture was forgotten about because larger feature-level ballpark estimates were no longer acceptable, and hence unimportant. On a company level, the business managers that previously talked directly to us just basically quit working with the IT department because the SAFe process was such a beast to contend. It was easiest for them to just stop asking for new digital product features, and focus on non-IT projects instead.
I know Scrum / SAFe proponents will say we were doing it wrong. It's ALWAYS that way - Scrum consultants love to gloat when some metric improves, but if things go south the org has only itself to blame for failing to correctly convert to their favorite flavor of True Agile System™.
My experience was however seeing an Agile team (as expressed by the Agile manifesto) turn into a Monty Python parody of agile software development just by being forced to submit to these "fake agile" heavy processes and hierarchies.
- rpmiskin 6y agoWe’re in the midst of a ‘SAFe transformation’ from having been running in a fairly lightweight scrum-style manner for year. There are a set of ‘good things’ that I can see from SAFe, and if you read the book and do the course there is loads about how you /should/ adapt it to work for you. Amongst the issues is that SAFe, by its very nature, has stakeholders outside the local team and that mandates some sort of process. Interestingly the size that Scaled Agile talk about is pretty big - a small Agile Release Train was discussed as ~100 people across ~5 teams. The full Portfolio SAFe is for multiple release trains e.g. 500+ people. If you’re trying to enforce SAFe on something much smaller then I think you’re probably doing it wrong. Also, if the “IT Department is trying to implement SAFe” rather than the “Company is undergoing a SAFe transformation” it has already gone wrong. You need to have your stakeholders throughout the organisation on board, and it is something of a top down thing.
- pracer 6y ago>If you’re trying to enforce SAFe on something much smaller then I think you’re probably doing it wrong. the comment you are answering was on point >I know Scrum / SAFe proponents will say we were doing it wrong. It's ALWAYS that way
- rpmiskin 6y agoMy bad, not ‘doing it wrong’, just trying to use the wrong methodology for your problem :) sledgehammer to crack a nut.
- vesinisa 6y agoThis particular company was in fact seriously in need of a corporation-wide business development methodology, so sledgehammer was called for – and I can see the appeal they saw in SAFe. But completely replacing autonomous agile teams' existing self-organized processes with a new top-down forced SAFe variety of Scrum with the same swing of the hammer -- not really called for, but mandated anyway in name of SAFe having to be an "organization wide" effort. Reality is of course that the dev teams are the only ones ever trained in the new process, and must suffer the chaos while rest of the org just don't care or hate it just as much – apart of course from the new middle managers who were hired to "help with the SAFe transformation". My prediction: max two years from now senior management announce "the end of the SAFe experiment", and go back to some ad-hoc version of the preceding organization model "with lessons learned" etc. Rinse and repeat every four-five years.