A Tech Lead’s New Project Checklist(insimpleterms.blog) |
A Tech Lead’s New Project Checklist(insimpleterms.blog) |
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 software teams at different sizes. What are the key, identified roles in a company of 5, 50, or 500? What are habits that smaller organizations ought to borrow from larger ones?
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 product owner, 2 architects. There are also some other folks from the business side, change management, etc that we work with regularly.
We're going through a bit of a change at the moment, removing the QA and analyst roles, spreading scrum masters across 2 teams, and limiting team size overall. So by the end of the year, I expect to have myself, the product owner, analyst is moving to scrum master, 1 QA as developer, 1 QA maybe as developer (we'll see how he adapts), and 4 developers.
It is a really big organization with dedicated departments for security, security testing, application security, performance testing, accessibility testing, brand management, change & release, test data, DB, DB security, gateways, shared components. And those are only the folks I interact with - there are mainframe folks, server maintenance (linux and windows), and the list goes on.
Some of that is moving to the teams now, some later. It's a pendulum though, things will be more generalized and distributed until something breaks spectacularly and someone will ask "why don't we have dedicated testers? why are we trusting every ol' dev with DB access?" and so on.
Serious question, do you find real value out of this position?
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 one good QA person. They never listened. Instead on a few occasions a user or business analyst would be assigned to QA which I explained was a joke. But I guess I have just not had the best budgeted projects or something.
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.
Clues this might be happening: senior managers pulling you aside to discuss their ideas for the project. Getting different questions on project updates than the goals you're building towards in scrum. Constantly changing short term goals.
While one is spending their time on the first points imagining infrastructure (for usage that might one day materialise), the company goes out of business because they failed to solve a problem anyone cared about.
Reminding ourselves of what the done state of project looks like helps us stay on track, from developers to the leads.
Your customers will each have their own individual pet features that they care about but if you don't drive to business value (meaning you just build whatever random shit the client tells your build) then it will be a failure 100% of the time.
Scrum = Shite verbosity about agile process and training for mgmt larva. Agile = Hyperbole. AWS = I don't know better and my developers are < 35 years old or on the make (+ stock). My customers are just stupid. Security = big $$, modest skills, certs for the neglected comptia and northcut industures. I'm a CEH!! So is every script kiddie on the internet. tester: can't write working code, useless to the degree that you come in when they need you to justify junit crap numbers you generated when drunk. This will scale if 12 coors == 12 saudi virgins. analyst: I'm an experienced tester. tech lead: best resume and best bully of the bunch. I can understand stack exchange! QA: I like your doxygen docs and the test numbers but I have a problem with connecting to server(x) at ip(x) from greenland at 2pm on a sunday. Any ideas? team: Bunch of backstabbing co-moderators.
I wish I could integrate Instapaper with my Kobo ereader instead.
-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.
/s
I guess success looks different for everyone.
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.
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.)
It's certainly not what I want to to be doing day-to-day, yet our tools aren't smart enough today for me to do well in a larger org without it.
Not that I believe any of that eh, scrum usually devolves to ritualistic, empty blabbering in around six months anyway.
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.
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!