Bad habits that stop engineering teams from high-performance

I’ve been working in and managing Agile engineering teams for over a decade, and whilst I won’t profess to know everything you should be doing, I can share some insight on things you definitely should not be doing. All learned from screwups, I might add.

You’ll find excuses, like “Oh, I’ll get back to it later,” or “Come on, it’s half a point; everyone knows what to do”. Don’t do it.

Realize as you spout these self-platitudes that you are being an arse – not to me, but to future-you and future-you’s team. That’s not cool. Write out the story. It’ll take you two minutes, but it’ll force you to think about what you actually want to get out of this effort and why. That’s rather important in most endeavors.

You only talk at stand-up

I once worked at a job like this and quit after about three months because it was utterly soul-destroying. Most humans want to work in a team, so find a way to work as one. Giving a two-minute, fact-based update in a 15-minute meeting once a day doesn’t cut it, and you risk losing half/all of your team who feel isolated.

Communication is hard. So is software development. So, the idea that we all wander off into our silos for 24 hours once standup is done, and nothing will still be unclear, hard or confusing in the meantime, is just plain silly.

If your team isn’t talking a lot during the day, it might mean they’re all super-humans. Or, more likely, your culture is bad, and they’re afraid or unwilling to communicate. 

Some things that I’ve seen work well to overcome this are Perma-calls, Kick-off chats and setting clear expectations for what junior devs should do when blocked.

Planning sessions of 2.5 hours

Your workload is not an impossible-to-plan anomaly. You do not need several hours to agree on what is coming into the sprint for the next week or two. What is actually happening is that you’re doing planning wrong. 

Instead of a chat that sounds like, “Let’s do these {n} things in the sprint, any concerns/emergencies/issues?” – what is almost definitely happening is that you’re discovering a bunch of new information in the planning session, which is leading to a re-refinement (or first refinement if you’re terrible) of the work.

Instead, do refinements. I won’t go into how to do a refinement; go Google it/read this link. But please do them. One of the hardest parts of Agile development is getting what to work on (and why) properly defined for the whole team. Focus on “defined and aligned.” If your team hasn’t defined what success means and aren’t all in agreement, the story shouldn’t be in planning. Send it back to the refinement stage.

PM-&-lead-only work-scoping

Delegation is easy, but it’s the thing I see most people screw up most often, myself very much included. But it must be overcome if you want a team to get good at planning, scoping and estimating work.

To be explicit:

• Everyone in the team should be involved in scoping out tickets before the refinement.
• Everyone in the team should be actively involved in the refinement session itself.

When teams don’t do this, they’re missing out on a bunch of things such as experience gained for junior devs, seniors learning to better explain and share their thoughts and helping the team internalize the code as something that they own.

Delaying releases until all the stories are done

If you’re not delivering “continuously”, then please go back to 2003. We’re not FTPing our files onto production servers for a deployment process.

The faster you integrate code (i.e. make it part of the main branch) the earlier your team is discovering differences with the code they’re writing. The longer this time-to-integrate is, the further things will have diverged, and thus, the more time will be wasted picking it apart.

The faster you deploy your code, the quicker your work is getting out to your customers, and the sooner you’ll know (if you have a robust error monitoring setup at least) whether you’ve introduced a new bug as part of the work, meaning the time-to-fix is vastly reduced. A nice side benefit is that the less that has been queued up to deploy, the smaller the “deploy diff” will be. That’s going to make it a heck of a lot easier to fix, in my experience.

Bad excuses I’ve heard over the years as to why you can’t do this include, ‘it takes up too much time’ (deploying should be a click of a button), ‘It’s not all ready yet’ (meaning you’re planning your work wrong) or we’re not allowed to because of “X regulation.” For the latter, read The Phoenix Project for some good lessons on how to address concerns here.

Caveat: Sometimes it’s physically not possible to do regular deployments, like if you’re writing software for a cruise missile. But otherwise, if SpaceX can deliver software to their satellites every week, you can do continuous delivery, mate.

We’ll add the tests later

Add them now or admit (ideally in a signed pact with the devil, written in your firstborn’s blood) that you just don’t care about whether your code works or not.

I suspect that if I have to argue this point further, then you’re already too far gone to be saved, but put succinctly-ish: untested code is code that probably doesn’t work. It’s impossible to know if it does work because the tests that should describe the functionality aren’t there. It’s also impossible to change because you don’t know what you’re breaking when you change it. Untested code is immediately legacy code that must either be immediately fixed (with tests) or completely replaced.

The post Bad habits that stop engineering teams from high-performance appeared first on SD Times.

from SD Times https://ift.tt/m7TAHDl