But in that same vein, recognizing how people operate means you can tweak or build a process to work with them and get results you want.
I’m not in a technical role like most people on this site, but I’m often in between those departments/their products and the consumer as well as the rest of the company. I think the mistake a lot of people in dev roles make is building a system that functions and think is good, and they need to bring the people to the process. But that’s not how people work. You can maybe get a person, maybe even a few in line with your designed process. But when you have groups of people it becomes impossible.
Take that DevSecOps person above. Their solution to entire teams not using their process is to oust the leadership and bring the team to heel. I don’t think that people take the time to think how they can alter their process to get the people more likely to work with it to get the results they want. As you said, people go the path of least resistance. You have to build your product to the user, not the other way around because the “people” aren’t going to change.
My example: We had a process our level 1 team members needed to follow when filling out tickets. Most of the time, no big deal. Our system means their tickets need to be filled out and submitted almost immediately upon completion, they can’t just wait around until the end of shift. It’s a lot of real-time work. Occasionally we’d get hit by huge numbers because something vital broke and they’re our front line in dealing with the communication, then these tickets would not get filled out properly in their mad rush to get them all submitted so they can move on. Every field not filled out correctly breaks our reporting, which is vital for us. Macros were no use because they could only fill out generic info and not any of the information we really needed. Their managers tried meetings and punishment and rewards, but when shit would hit the fan, inevitably the proper protocol would be the first thing to go to keep the operation running.
So I go in, take a look at the process start to finish and talk to the team about what specific things make it harder to complete in a crisis. And then I went and created a “mass issue” ticket form to use for those scenarios instead. When something major breaks and the team is flooded with these calls and they have to go through 4-5 at once every 10 minutes, they tick a box and get a new form with just the vital info and the ability to group as many issues on it as they have. Now they can group like issues together and fill out a single ticket. Their time is saved and we still get the precious data we need. Because we built our system to work with the user and made the path of least resistance a path that works.
But I have an advantage. I now work in a tech-adjacent role but I’ve spent my life working with people, not technology. So I get to bring that viewpoint to the job where most people around me have never really given it much thought.
DevSecOps is all about process, I simplified my answer.
At a high level in software there will always be a review phase, where code needs to be built and pass tests (as a minimum). With Git being used by every organisation I have been involved in you will find the organisation/team will claim to follow a variation of ‘Feature branch Workflow’ with review happening at a specific point (Pull Request).
For the last ~10 years every organisation/team I’ve worked in/with has claimed to use a CI to verify the source code as part of that review phase.
In most dysfunctional teams that review phase will be broken, the fastest win is to bring in the CI. Static analysis tools are also impartial in how they review and useful in teaching people how to review.
I don’t say your project must build with no warnings, I say you project must build and I’ll have the CI point out where you have added warnings as part of review. When people complain I’ll point to their teams Ways of Working or an organisations Software Development Plan (or in one case a System Engineering Management Plan).
The sort of team that then chooses to disable this will do so because the leadership are undermining it (normally a team lead turns it off or tells them to just ignore it). There seem to be a few common reasons as to why team leads will do this but it isn’t something you can rationally debate with. The only solution I’ve found is to sideline the problem, change team culture and identify a leader within the team and hand it over to them.
Your talking about teams which are failing due to the environment, those normally understand what is wrong and the best approach is to be a good scrum master (e.g. run retro sessions, identify issues and work to resolve the environment problems with them).
But in that same vein, recognizing how people operate means you can tweak or build a process to work with them and get results you want.
I’m not in a technical role like most people on this site, but I’m often in between those departments/their products and the consumer as well as the rest of the company. I think the mistake a lot of people in dev roles make is building a system that functions and think is good, and they need to bring the people to the process. But that’s not how people work. You can maybe get a person, maybe even a few in line with your designed process. But when you have groups of people it becomes impossible.
Take that DevSecOps person above. Their solution to entire teams not using their process is to oust the leadership and bring the team to heel. I don’t think that people take the time to think how they can alter their process to get the people more likely to work with it to get the results they want. As you said, people go the path of least resistance. You have to build your product to the user, not the other way around because the “people” aren’t going to change.
My example: We had a process our level 1 team members needed to follow when filling out tickets. Most of the time, no big deal. Our system means their tickets need to be filled out and submitted almost immediately upon completion, they can’t just wait around until the end of shift. It’s a lot of real-time work. Occasionally we’d get hit by huge numbers because something vital broke and they’re our front line in dealing with the communication, then these tickets would not get filled out properly in their mad rush to get them all submitted so they can move on. Every field not filled out correctly breaks our reporting, which is vital for us. Macros were no use because they could only fill out generic info and not any of the information we really needed. Their managers tried meetings and punishment and rewards, but when shit would hit the fan, inevitably the proper protocol would be the first thing to go to keep the operation running.
So I go in, take a look at the process start to finish and talk to the team about what specific things make it harder to complete in a crisis. And then I went and created a “mass issue” ticket form to use for those scenarios instead. When something major breaks and the team is flooded with these calls and they have to go through 4-5 at once every 10 minutes, they tick a box and get a new form with just the vital info and the ability to group as many issues on it as they have. Now they can group like issues together and fill out a single ticket. Their time is saved and we still get the precious data we need. Because we built our system to work with the user and made the path of least resistance a path that works.
But I have an advantage. I now work in a tech-adjacent role but I’ve spent my life working with people, not technology. So I get to bring that viewpoint to the job where most people around me have never really given it much thought.
DevSecOps is all about process, I simplified my answer.
At a high level in software there will always be a review phase, where code needs to be built and pass tests (as a minimum). With Git being used by every organisation I have been involved in you will find the organisation/team will claim to follow a variation of ‘Feature branch Workflow’ with review happening at a specific point (Pull Request).
For the last ~10 years every organisation/team I’ve worked in/with has claimed to use a CI to verify the source code as part of that review phase.
In most dysfunctional teams that review phase will be broken, the fastest win is to bring in the CI. Static analysis tools are also impartial in how they review and useful in teaching people how to review.
I don’t say your project must build with no warnings, I say you project must build and I’ll have the CI point out where you have added warnings as part of review. When people complain I’ll point to their teams Ways of Working or an organisations Software Development Plan (or in one case a System Engineering Management Plan).
The sort of team that then chooses to disable this will do so because the leadership are undermining it (normally a team lead turns it off or tells them to just ignore it). There seem to be a few common reasons as to why team leads will do this but it isn’t something you can rationally debate with. The only solution I’ve found is to sideline the problem, change team culture and identify a leader within the team and hand it over to them.
Your talking about teams which are failing due to the environment, those normally understand what is wrong and the best approach is to be a good scrum master (e.g. run retro sessions, identify issues and work to resolve the environment problems with them).