Little Tasks, Little Trust

I am a front-line coder but if I don't restrain myself I will usually be the #1 person for creating tickets in the ticket system because I like to split tasks into great detail enough to drive my co-workers nuts.

There was a time I did updates to a web form application and I could break the work down to tasks in 10 minute increments and plan it would take six hours and I would really get it done in 5.8 hours. The design of the application helped because the changes I had to do were all straightforward within the existing framework.

An alternate model for "development" is fast cycle run-break-fix. Even if you are planning to deliver good "user stories" or whatever makes the project go forward there is some probability that the tester will say your code failed, some probability the tester is right and that the ticket gets sent back to you.

Sometimes before you send it to the tester you might try a few "failing" solutions before you find one that works; so instead of a model that you'll take "12 hours" to develop something rather something like a Markov process where maybe you get lucky on the first try, but it may take several attempts.

Hopefully you learn as much as you can from these attempts, maybe the first draft was written when you didn't understand the problem, the second draft was basically right but there were 1d4 places where it gets hung up because of an interaction you didn't think through and etc.

> Every third sprint is a tech sprint. Can you elaborate on this? I love the sound. I get pushback even suggesting a tech sprint once every 6 weeks. What kinds of projects fall under here, and do you still work on product? What's the product team work during this sprint? Thanks!

I volunteered for a non-profit where we had a model of "accountability" that worked very much this way. Leads weren't told how to do it, they were just given the accountability of making sure it was done and the autonomy to decide how it happened. If a lead quit, that accountability fell to that lead's lead. This led all the way up to the President of the org who would be accountable for everything should everyone quit. It worked fabulously well. We were all volunteers (~250 members). The closest thing I've seen to this in the paid professional world is the holacracy model of business organization. Despite my best efforts, I was unable to convince my current company to grow this way and now we swim through a deep pile of jira tasks, assigning them out to devs one by one with nobody having a clear sense of ownership of anything ever.

In my view, if you say, "I'll never trust someone again if they ever make a mistake," then you'll be deservedly miserable as a manager, and you've never raised kids. ;-)

You might have to take baby steps. Can you watch someone make a mistake without intervening? Can you do so without severe emotional turmoil?

Most managers never break the micromanagement habit, and will always pay the price. Probably the biggest price of not trusting people is that they don't trust you either, and they find ways to keep you out of the loop so they can make decisions and get work done. This in turn causes you to trust them even less. Distrust is a self fulfilling death spiral.

You might have no choice, e.g., if you work in a micromanagerial culture. Can your boss watch you, as you are watching someone make a mistake? In other words, are your management habits the source of a culture, or merely its effect?

Thus the final step is: Can you stick up for your people after they've made a mistake?

It is very similar to a normal sprint, but instead of adding new features, our goal is to improve existing features, the system, or the process. It can be technical things like upgrading to a new version of PHP, of a framework, or a library. It can be anything related to technical debt. It can be some proof-of-concept. In one of such sprints, I've introduced cypress and made a couple of tests to demo it.

The tickets for this sprint come from anyone. Usually, when working on a ticket you sometimes get a brilliant idea. Write a new ticket with that idea and add it to the tech sprint proposal. Before the tech sprint, the whole team participates in sprint planning. We go over tickets, review them, and decide whether they should be done. Usually, we assign tickets to ourselves. We also estimate how many story points they will be. Ideally, it should take less than 1 week to finish. A maximum of the whole sprint of 2 weeks is allowed. Otherwise, it is divided or multiple people work on it.