Might want to add company size and team size(s). Many of these points show it is most likely for small to medium sized companies. For an enterprise the checklist does not entirely hold due to more specialized roles. Though there are some good tips.
A Tech Lead’s New Project Checklist
31–40 of 45 posts
Re: A Tech Lead’s New Project Checklist
#32"Understand the importance of the Trinity of delivery: Delivery manager, product owner, tech lead" I'm only familiar with teams too small to have separate roles like this. How does good software planning scale down to smaller teams -- say 5 or 10 people in the whole organization? Ultimately someone has to be responsible for the same concerns, but I wonder how it maps. In general I'd love to see a comparison of softwa…
They forgot QA lead. I know it's currently posh in some companies to do away with QA (YOLO software development methodology?). I've found successful software delivery without a strong QA lead on equal footing as the tech lead and PM/PJM is a recipe for disaster. QA is often the only source of truth that you can rely on when you want an accurate assessment of where things stand.
[deleted]
Re: A Tech Lead’s New Project Checklist
#33Earlier quoted context omitted.
I'm a lead on a team of 13 right now: myself, 6 developers, a QA lead, 2 testers, analyst, scrum master, and product owner. We're one of ~15? teams in my organization (part of an overall IT shop of ~3000), but we're fairly separate from the others in business and technologies. We have a delivery manager for our team and a couple other efforts. There's a dedicated tech lead of tech leads, program level PMs, lead produ…
>scrum master Serious question, do you find real value out of this position?
Yes absolutely, a good one is invaluable at helping the rest of the team be more productive.
Re: A Tech Lead’s New Project Checklist
#34Earlier quoted context omitted.
And continually revisit it. When you're knee deep in requirements, corner cases, and industry best practices, you can lose sight of why you were building the damn thing in the first place, and end up with something that doesn't satisfy that need.
Always know what 'DONE' looks like. Reminding ourselves of what the done state of project looks like helps us stay on track, from developers to the leads.
How do you define done? Software is never done.
A better way to look at things is whether a feature is in good enough shape and whether moving on to working on other things is likely to be more beneficial.
Re: A Tech Lead’s New Project Checklist
#35Earlier quoted context omitted.
They forgot QA lead. I know it's currently posh in some companies to do away with QA (YOLO software development methodology?). I've found successful software delivery without a strong QA lead on equal footing as the tech lead and PM/PJM is a recipe for disaster. QA is often the only source of truth that you can rely on when you want an accurate assessment of where things stand.
The thing is that tests generally have to be a core part of the development process now, so if the QA isn't being driven by the devs then they aren't doing software engineering quite up to contemporary standards. Having said that, I have had a lot of jobs on small teams, especially some years ago, where testing was inadequate or not really part of the development process, and I always tried to convince them to hire o…
Dev needs QA/Test just like writers need editors.
I was a QA manager for a while. It's been over 10 years since I've worked somewhere that had any sense of QA/Test.
Now we have Horde, err, Scrum and DevOps. Proudly. It's like the industry just gave up.
I don't what it's like at the allegedly highest functioning teams (environments) Google, Facebook. But out here in the wild, it's madness.
Dan Luu has been best at capturing and articulating "contemporary standards" for what passes as "quality" in software development. http://danluu.com (I wish I was 1/2 as smart as Dan.)
Re: A Tech Lead’s New Project Checklist
#36here is what i usually do: -identify weak people in the team with a stinky attitude, those who dont learn and are toxic, do your best to get rid of them. -next identify those mediocre people doing 9-5, maximise their output during those hours, don't give them no slack. -finally identify your super stars, cherish them, buy them coffee/lunch and give them a lot of slack. for this is a meritocracy, no damn Disneyland.
How do you identify superstars? Do you look at their code or do you simply see the UI when its done? I've seen a couple superstars/JS ninjas that produced unmaintainable crap, but a lot of it, and it took actually looking at their code to see why. They didn't last.
> How do you identify superstars?
Fun to be around if you're their boss, has a confident yet subtly incorrect opinion on every single aspect of programming, climate science, dietology and immigrants that are not them, personally stabbed one of the "weaklings" in the face, knows lots of GoT trivia, "weaklings" burned out while fixing their bugs.
Re: A Tech Lead’s New Project Checklist
#37Earlier quoted context omitted.
I'm a lead on a team of 13 right now: myself, 6 developers, a QA lead, 2 testers, analyst, scrum master, and product owner. We're one of ~15? teams in my organization (part of an overall IT shop of ~3000), but we're fairly separate from the others in business and technologies. We have a delivery manager for our team and a couple other efforts. There's a dedicated tech lead of tech leads, program level PMs, lead produ…
>scrum master Serious question, do you find real value out of this position?
Yes and no. On the useful side, they own some of the process inherent in large organizations. But they also act as a conduit to push that process to team members.
In practice, our scrum masters have been a place for the PMs, Analysts, and QA leads to go as their positions have been displaced. I would like to see more technical scrum masters that can own technical impediments, but that doesn't seem to be happening yet.
I also think that spreading scrum masters across teams will disconnect them from the specifics of the work and allow them to act more as coaches than non-technical team members.
Re: A Tech Lead’s New Project Checklist
#38"Understand the importance of the Trinity of delivery: Delivery manager, product owner, tech lead" I'm only familiar with teams too small to have separate roles like this. How does good software planning scale down to smaller teams -- say 5 or 10 people in the whole organization? Ultimately someone has to be responsible for the same concerns, but I wonder how it maps. In general I'd love to see a comparison of softwa…
The minimum team size is one: A single person building a project. I'd guess the minimum successful team size is in the 2-3 range. At the very least you must have a client or customer of some kind and a developer or implementer.
I think it is possible to have a successful team of one. Customers aren't usually included as part of the team.
Re: A Tech Lead’s New Project Checklist
#39Earlier quoted context omitted.
>scrum master Serious question, do you find real value out of this position?
There are many industries which have found value in specific people to do the paperwork and deal with process. I don't think it's needed under 10 or so people if you have a good team, but once you're we'll into the 20+ range, I don't understand why so many devs are so set against giving this type of work to someone else. It's certainly not what I want to to be doing day-to-day, yet our tools aren't smart enough today…
Funny you say that while every other "expert" says it's pointless to do scrum above around 10 members.
Not that I believe any of that eh, scrum usually devolves to ritualistic, empty blabbering in around six months anyway.
Re: A Tech Lead’s New Project Checklist
#40Earlier quoted context omitted.
Always know what 'DONE' looks like. Reminding ourselves of what the done state of project looks like helps us stay on track, from developers to the leads.
How do you define done? Software is never done. A better way to look at things is whether a feature is in good enough shape and whether moving on to working on other things is likely to be more beneficial.
You're not building "software," you're building something for someone to use. Done is defined by what that person needs to do their work. Done should be defined up front, or at least as far ahead as possible so it's clear.
One of the first questions I ask when probing about the state of a project or task is "how do you know when you're done?" Too often, the answer is a shrug, or a deer in headlights look!