{"id":53866,"date":"2024-02-26T10:41:05","date_gmt":"2024-02-26T15:41:05","guid":{"rendered":"https:\/\/sdtimes.com\/?p=53866"},"modified":"2024-08-09T14:12:43","modified_gmt":"2024-08-09T18:12:43","slug":"bad-habits-that-stop-engineering-teams-from-high-performance","status":"publish","type":"post","link":"https:\/\/sdtimes.com\/agile\/bad-habits-that-stop-engineering-teams-from-high-performance\/","title":{"rendered":"Bad habits that stop engineering teams from high-performance"},"content":{"rendered":"

I\u2019ve been working in and managing Agile engineering teams for over a decade, and whilst I won\u2019t profess to know everything you <\/span>should<\/span><\/i> be doing, I can share some insight on things you definitely should not be doing. All learned from screwups, I might add.<\/span><\/p>\n

You\u2019ll find excuses, like \u201cOh, I\u2019ll get back to it later,\u201d or \u201cCome on, it\u2019s half a point; everyone knows what to do\u201d. Don\u2019t do it.<\/span><\/p>\n

Realize as you spout these self-platitudes that you are being an arse \u2013 not to me, but to future-you and future-you\u2019s team. That\u2019s not cool. Write out the story. It\u2019ll take you two minutes, but it\u2019ll force you to think about what you actually want to get out of this effort and why. That\u2019s rather important in most endeavors.<\/span><\/p>\n

You only talk at stand-up<\/strong><\/h5>\n

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\u2019t cut it, and you risk losing half\/all of your team who feel isolated.<\/span><\/p>\n

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.<\/span><\/p>\n

If your team isn\u2019t talking a lot during the day, it might mean they\u2019re all super-humans. Or, more likely, your culture is bad, and they\u2019re afraid or unwilling to communicate.\u00a0<\/span><\/p>\n

Some things that I\u2019ve seen work well to overcome this are Perma-calls, Kick-off chats and setting clear expectations for what junior devs should do when blocked.<\/span><\/p>\n

Planning sessions of 2.5 hours<\/strong><\/h5>\n

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\u2019re doing planning wrong.\u00a0<\/span><\/p>\n

Instead of a chat that sounds like, \u201cLet\u2019s do these {n} things in the sprint, any concerns\/emergencies\/issues?\u201d \u2013 what is almost definitely happening is that you\u2019re discovering a bunch of new information in the planning session, which is leading to a re-refinement (or first refinement if you\u2019re terrible) of the work.<\/span><\/p>\n

Instead, do<\/span> refinements. I won\u2019t go into how to do a refinement; go Google it\/read<\/span> this link<\/span><\/a>. 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 \u201cdefined and aligned.\u201d If your team hasn\u2019t defined what success means and aren\u2019t all in agreement, the story shouldn\u2019t be in planning. Send it back to the refinement stage.<\/span><\/p>\n

PM-&-lead-only work-scoping<\/strong><\/h5>\n

Delegation is easy, but it\u2019s 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.<\/span><\/p>\n

To be explicit:<\/span><\/p>\n