- use the process repeatedly and by as many people as possible
- adapt the process to any misuse seen in the wild
4) automate the process
Everybody will buy into steps 1&2, and most people will come around to 4, but doing step 3 usually will get you more people pushing for and understanding 4
The limitation of your approach I will say is that if you can automate the beginning of a process or the end it’s fine, but if you have two islands in the middle it doesn’t work better than a CLI tool with prompts.
> The limitation of your approach I will say is that if you can automate the beginning of a process or the end it’s fine, but if you have two islands in the middle it doesn’t work better than a CLI tool with prompts
I think I may have poorly described my approach then. It's just the same thing, the choice of sheets or Jira or cli or a combo is only about meeting people where their current process is. A dev setup -> cli. A business process between trams -> Jira if that's the current flow. I'm not getting marketing to install my cli tool, and they'd not be the ones doing the manual steps anyway.
The point is just making a process into a series of clearly defined steps that can be manual and can be automated independently.
Your description of what happens alongside 3 and 4 is good, this was really valuable when I've done it. Just like releasing a MVP and finding out key problems with your imagined approach, the issues are usually not what you expect. You also have better test cases and examples.
Massive side benefit when I did this with data was that it also meant a process could be automated 95% of the time, manual 5% without changing the interface anyone worked with. All they saw was the ticket took longer really. That's great when you find absolutely wild stuff in some csv file.
One of the fun things with SEI Capability Maturity Model is that you reach level 1 just by having your process written down at all, no matter how stupid it sounds.
But the giggle test is just something I borrowed from business, which is, “can I say this with a straight face?” Which eliminates a lot more censorious than you would think. Writing something down is one thing, making eye contact with someone while repeating it is a bit harder.
censorious appears to mean 'severely critical of others'. I expect they meant 'censoriously', with the full intent being that the embarrassment felt by the critical reactions of others when reading the instructions out loud will cause you to eliminate or fix obviously broken, complex or tedious processes that you had, until then, just quietly been putting up with.
Iteration doesn’t require infinite money and this sort of work more than pays for itself.
The last time I used it, which is probably eight times now, I freed a team up to attack more entrenched tech debt problems by making them no longer afraid of deploying to run trails instead of waiting to do feature toggles once a release cycle.
Every adult programmer should be able to think of four things they can work on when nobody is telling them what to do for the next little while, and Scrum produces a lot of those. This is just one of the things I do. And when you get close to a quantum of useful improvement you can usually get a story or two on the board.
Fixing your processes is an axe sharpening exercise. If you’d rather be dismissive enough to register a complaint then I feel sorry for the teams you work on.
1) Capture the process as is
2) make the process pass a giggle test
3) make the process automatable
Concurrent with 3 and 4:
- use the process repeatedly and by as many people as possible
- adapt the process to any misuse seen in the wild
4) automate the process
Everybody will buy into steps 1&2, and most people will come around to 4, but doing step 3 usually will get you more people pushing for and understanding 4
The limitation of your approach I will say is that if you can automate the beginning of a process or the end it’s fine, but if you have two islands in the middle it doesn’t work better than a CLI tool with prompts.