I’ve been working with and leading Agile engineering teams for over a decade, and while I won’t claim to know everything you do you should do, I can share some insights on things you definitely shouldn’t do. I might add that they learned everything from mistakes.
You’ll find excuses like “Oh, I’ll come back to it later” or “Come on, that’s half a point; everyone knows what to do.” don’t do it
Realize when you’re spewing those self-deprecating platitudes that you’re acting like an ass—not to me, but to yourself and your future-team. That’s not cool. Write a story. It will take you two minutes, but it will make you think about what you really want to gain from this effort and why. This is pretty important in most endeavors.
Speak only in a standing position
I once worked at a job like this and quit after about three months because it was absolutely devastating. Most people want to work in a team, so find a way to work as one. A 2-minute fact-based update in a 15-minute meeting once a day is not enough and you risk losing half/the whole team feeling isolated.
Communication is difficult. Likewise, software development. So the idea that we all wander off into our silos for 24 hours after the standup is over, and nothing will be unclear, difficult or confusing in the meantime, is just silly.
If your team doesn’t talk much during the day, it might mean they’re all super-people. Or, more likely, your culture is bad and they are afraid or unwilling to communicate.
Some things I’ve seen work well in overcoming this are standing invitations, initial conversations, and setting clear expectations about what junior developers should do when blocked.
Planning sessions of 2.5 hours
Your workload is not an anomaly that is impossible to plan for. You don’t need a few hours to agree on what’s coming in the sprint for the next week or two. What is actually happening is that you are planning wrong.
Instead of a conversation that sounds like, “Let’s do these n things in a sprint, are there any problems/emergencies/problems?” – what almost certainly happens is that you discover a bunch of new information in the planning session, which leads to re-refining (or re-refining if you’re bad) the work.
Instead, do finishing touches. I won’t go into how to do the finishing; google/read this link. But please do them. One of the hardest parts of Agile development is properly defining what (and why) to work on for the whole team. Focus on “defined and aligned”. If your team has not defined what success means and not everyone is in agreement, the story should not be in the planning. Send it back to the refinement phase.
PM-&-lead-only scope
Delegation is easy, but it’s the thing I see most people screw up the most, myself included. But this must be overcome if you want the team to become good at planning, scoping and estimating work.
To be explicit:
- Everyone on the team should be involved in ticket selection before grooming.
- Everyone in the team should be actively involved in the training session itself.
When teams don’t do this, they miss out on a bunch of things like experience gained for younger developers, seniors learning to better explain and share their thoughts, and helping the team internalize the code as something they own.
Postponing release until all stories are finished
If you are not shipping “continuously”, please go back to 2003. We do not FTP our files to production servers for the deployment process.
The faster you integrate code (ie make it part of the master branch), the sooner your team will discover differences with the code they’re writing. The longer this integration time is, the more things will diverge, and therefore the more time will be wasted taking them apart.
The faster you deploy your code, the faster your work will get to your customers and the sooner you’ll know (if you at least have a robust bug tracking setup) if you’ve introduced a new bug as part of your work , meaning the time to fix is greatly reduced. A nice side benefit is that the less there is in the deployment queue, the smaller the “deployment gap” will be. In my experience, this will make it a heck of a lot easier to fix.
Bad excuses I’ve heard over the years about why you can’t do this include: ‘it’s taking too much time’ (deployment should be a click of a button), ‘it’s not ready yet’ (which means you’re planning your work wrong) or not allowed due to “regulation X”. For the latter, read on Project Phoenix for some good lessons on how to solve problems here.
Warning: Sometimes it is not physically possible to perform regular deployments, for example you write software for a cruise missile. But otherwise, if SpaceX can deliver software to its satellites every weekyou can do continuous delivery, mate.
We will add tests later
Add them now or admit (ideally in a signed pact with the devil, written in the blood of your first born) that you just don’t care if your code works or not.
I guess you’re already too far gone to be saved if I have to argue this point any further, but to put it succinctly: untested code is code that probably doesn’t work. It is impossible to know if it works because there are no tests to describe the functionality. It’s also impossible to change because you don’t know what you’re breaking when you change it. Untested code is currently legacy code that must be immediately fixed (with tests) or completely replaced.