My fundamental issue with the continued uptake of Agile, Scrum and Devops is the devolution of responsibility. For a lot of people who work in IT they don't do the job to be responsible - they do it to code, to scratch that itch and to build something. Making teams responsible in the 'you own it, you run it' manner is not in my opinion a simple matter of cutting them loose and them blaming them when it goes wrong - you need to support the people and the processes. It is however a good thing to put techies closer to users - but not all techies are made alike. What is good for some is not good for all.
I've worked in many companies for over two and a half decades and in my recent engagements I've noticed increasingly levels of stress among dev teams who know they are going to have to support the whole stack when it goes live. This adversely colours development practice, it confuses codebases in swathes of (often unnecessary IMO) automation and encourages little in the the way of risk taking when it comes to design. Paranoia and burnout is actually now becoming commonplace whereas once it was little heard of.
I struggle to say that I preferred the day of the PM and the Gantt chart however in some ways is big business going down the right track with their view of Agile and Scrum? I think for the most part there needs to be a more nuanced approach to this rather than what you often see - enforcing new tools and new ways of working which a) upsets everyone's rhythm and b) gives responsibility to those who neither asked for it or want it going forwards. Time for a rethink..
I'd say in a small team responsibility and accountability are a given. I've worked in startups where there is not a lot of ceremony around going live and people do the devops because there is nobody else doing it. I've seen some surprisingly effective teams that run circles around most of the corporately unagile teams I've been in. In most bigger teams accountability is indeed the problem. People like to deflect it. So you get people asking each other for permission and then insisting on checks and balances and then asking for senior managers for permission.
Actually writing this in between two completely bog standard and risk free deploys to production. Nobody to ask for permission (or forgiveness). Actually works.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
My fundamental issue with the continued uptake of Agile, Scrum and Devops is the devolution of responsibility. For a lot of people who work in IT they don't do the job to be responsible - they do it to code, to scratch that itch and to build something. Making teams responsible in the 'you own it, you run it' manner is not in my opinion a simple matter of cutting them loose and them blaming them when it goes wrong - you need to support the people and the processes. It is however a good thing to put techies closer to users - but not all techies are made alike. What is good for some is not good for all.
I've worked in many companies for over two and a half decades and in my recent engagements I've noticed increasingly levels of stress among dev teams who know they are going to have to support the whole stack when it goes live. This adversely colours development practice, it confuses codebases in swathes of (often unnecessary IMO) automation and encourages little in the the way of risk taking when it comes to design. Paranoia and burnout is actually now becoming commonplace whereas once it was little heard of.
I struggle to say that I preferred the day of the PM and the Gantt chart however in some ways is big business going down the right track with their view of Agile and Scrum? I think for the most part there needs to be a more nuanced approach to this rather than what you often see - enforcing new tools and new ways of working which a) upsets everyone's rhythm and b) gives responsibility to those who neither asked for it or want it going forwards. Time for a rethink..
I'd say in a small team responsibility and accountability are a given. I've worked in startups where there is not a lot of ceremony around going live and people do the devops because there is nobody else doing it. I've seen some surprisingly effective teams that run circles around most of the corporately unagile teams I've been in. In most bigger teams accountability is indeed the problem. People like to deflect it. So you get people asking each other for permission and then insisting on checks and balances and then asking for senior managers for permission.
Actually writing this in between two completely bog standard and risk free deploys to production. Nobody to ask for permission (or forgiveness). Actually works.