Don't do process for its own sake. Before you do any practice, understand what it is for, and what you hope to get out of it. Trial it and abandon if is more effort than reward.
Make doing the right thing easy. Commits to source control should be easy because people do them a lot. Same with writing tests.
Make doing risky things slow. Deploying to live should involve some checklists and "management sign off" because you want people to slow down and think about whether they are about to fuck up. Ditto anything that could sink your business or unexpectedly cost a lot of money.
If you are delivering contracts, and a lot of enterprise sales involve these, then you signed up to deliver something. Track what that thing is, and have a way of proving you delivered it.
Some people genuinely enjoy filling out repetitive forms. They also enjoy writing them and getting doing one accepted as part of your project cycle. Spot these people by boilerplate to content ratio in the documents they are writing. Keep them away from core development.
Don't cargo cult. Don't re-invent the wheel. Use tools that don't get in the way.
It is useful for teams of 4 or more / mixed abilities to have a process just so everyone knows what they are doing and doesn't have to think about it. If you are in that kind of situation, just do scrum with actual postit notes for a couple months, then start dropping some bits and using tools for others. Scrum is only a good estimating tool if your developers don't do operations too. Less people than that (even as a team within a larger company), can probably get away with just talking, shared todo lists.
2 comments
[ 3.7 ms ] story [ 13.4 ms ] threadMake doing the right thing easy. Commits to source control should be easy because people do them a lot. Same with writing tests.
Make doing risky things slow. Deploying to live should involve some checklists and "management sign off" because you want people to slow down and think about whether they are about to fuck up. Ditto anything that could sink your business or unexpectedly cost a lot of money.
If you are delivering contracts, and a lot of enterprise sales involve these, then you signed up to deliver something. Track what that thing is, and have a way of proving you delivered it.
Some people genuinely enjoy filling out repetitive forms. They also enjoy writing them and getting doing one accepted as part of your project cycle. Spot these people by boilerplate to content ratio in the documents they are writing. Keep them away from core development.
Don't cargo cult. Don't re-invent the wheel. Use tools that don't get in the way.
It is useful for teams of 4 or more / mixed abilities to have a process just so everyone knows what they are doing and doesn't have to think about it. If you are in that kind of situation, just do scrum with actual postit notes for a couple months, then start dropping some bits and using tools for others. Scrum is only a good estimating tool if your developers don't do operations too. Less people than that (even as a team within a larger company), can probably get away with just talking, shared todo lists.