3 ms·

> tech-lead driven Would you expand on this please? Especially how it differs to agile. Very keen to learn alternative approaches, as a tech lead struggling st

by n4r9 2y ago

> tech-lead driven Would you expand on this please? Especially how it differs to agile. Very keen to learn alternative approaches, as a tech lead struggling struggling with the company's half-baked attempts to go agile.

bdbcbc 2y ago
How much time have you invested into it as a skill set ? Have you read product thinking, the lean startup, agile estimating and planning ? How do you expect to leverage a methodology if you don’t do a deep dive and become an expert.
- JKCalhoun 2y ago
  I wasn't the manager calling the shots. As an engineer though it will always be abominable to me. Others, as I say, like it.
- n4r9 2y ago
  Similar to the other reply, I don't manage people or drive the methodology changes. I'm dev lead on a small (3 dev) sub-team within the larger platform team. We generally follow the same methodology as the rest of dev. They're reportedly following agile but it has the classic hallmarks of being driven by senior management: little/no training or education in agile (even in product), devs don't speak to clients, retros are consistently cancelled for lack of time, process changes are dictated by the product team (which is managed by the company's MD), etc... . I'm actually not convinced that the company can pull off agile. Partly because management don't understand it, and partly because our major business client are rigid about roadmaps and deadlines. Also partly because my own sub-team engages in research-heavy, long-term features. A lot of our work consists of thinking up blue-skies algorithm changes, trying them out, and going back to the drawing board if it doesn't pan out. Month-long iterations of work with potentially no viable changes after each one. When I read about agile it tends to describe stuff where you can muster up an MVP for a feature within a week or two at most, so it has been tricky to interpret how to apply it. So basically, it's not working great and I have limited influence to change things. What I can do is fight my team's corner with well-backed arguments. E.g. there was recently a period of a few months where the entire platform team (~25 people) took part in a daily standup lasting 30 mins on average, on top of their own squad catchups. This was obviously wasteful but the engineering manager liked feeling ontop of things. After I repeatedly raised the issue, the frequency got dropped to weekly for my team and twice-weekly for the wider team. So I'm keen to learn more about agile vs alternative systems so I can continue to fight effectively my team's corner in this way. The ideal end-goal would be to extricate my team entirely from this half-baked agile mess, whether that means following agile more "correctly" or switching to something more bespoke. I appreciate the references and have started glancing through "Agile Estimations and Planning", it's okay so far but nothing revelatory. I don't have a lot of time to devote to this so I'm naturally skeptical of "just put in lots of hours of reading and I'm sure you'll see the benefit".
JKCalhoun 2y ago
It's maybe a bit orthogonal? (Or maybe misleading.) I'll fill in with anecdotes and try to make more sense: When I started at Apple in 1995 the way things got done was: you worked with a team that focused on, for example, the graphics frameworks of the OS. One engineer was tech-lead. They went to SIGGRAPH, tried to have their finger on the pulse of the "industry" and, of course, what our users wanted ... in terms of graphics on the platform. So a new OS meant an opportunity to add some of these desired features to our frameworks. Tech-lead generally called the shots, chose various engineers on the team to own various parts. And so we coded. And maybe I am getting a bit off topic here, describing something more like "ownership" for a dev on a team: We still had company-wide mandates but again it would be an engineer on a team that either volunteered or was selected to take responsibility for some "deliverable". When the Mac was moving to PowerPC I was handed the "color pickers" from the Mac source base that were written in 68K assembly, I was expected to get them to compile for PPC. In addition to rewriting them in C, I also cleaned up the SPI that allowed the color pickers to be modular. I wasn't asked to, but I wrote a crayon color picker, an HTML color picker to test the SPI and because, at least with the HTML picker, I thought users would want that (the web being the new thing). I had no idea then that it would not always be like this. On one hand, having to port code from 68K to C was definitely an example of the constant change I would see over the coming decades in my career. But no way did I see coming engineer-as-commodity (and I think of Agile like this, engineers are interchangeable cogs), the flip to top-down control (as in management or design telling engineers what to do instead of bottom-up where the team itself made many of the decisions). I'll end with this: I loathe agile development. But I have seen engineers that thrive in that environment so I am not one to condemn it. For engineers that seem unhappy I have always suggested that they be given a piece of code (or class, or part of a framework, or a whole framework if it is feasible) that they can "own". And by own I mean they make all the changes, fix all the bugs, etc. They own the tech debt, are free (time permitting) to toss everything and rewrite it if they choose to. They chart the direction of the code going forward. They become the domain expert of that code. For many engineers (and me of course) this can be the most rewarding way to work. The only pushback I hear from those agile-minded is, "What if that person leaves? Now we have no domain expert regarding that code?" They're right. Someone else will have to take it over. Perhaps even a new hire. And soon they too will "own" it — may even rewrite it. But we're engineers, we can figure this shit out. ;-)

by n4r9 2y ago

bdbcbc 2y ago

How much time have you invested into it as a skill set ? Have you read product thinking, the lean startup, agile estimating and planning ? How do you expect to leverage a methodology if you don’t do a deep dive and become an expert.

JKCalhoun 2y ago
I wasn't the manager calling the shots. As an engineer though it will always be abominable to me. Others, as I say, like it.
n4r9 2y ago
Similar to the other reply, I don't manage people or drive the methodology changes. I'm dev lead on a small (3 dev) sub-team within the larger platform team. We generally follow the same methodology as the rest of dev. They're reportedly following agile but it has the classic hallmarks of being driven by senior management: little/no training or education in agile (even in product), devs don't speak to clients, retros are consistently cancelled for lack of time, process changes are dictated by the product team (which is managed by the company's MD), etc... . I'm actually not convinced that the company can pull off agile. Partly because management don't understand it, and partly because our major business client are rigid about roadmaps and deadlines. Also partly because my own sub-team engages in research-heavy, long-term features. A lot of our work consists of thinking up blue-skies algorithm changes, trying them out, and going back to the drawing board if it doesn't pan out. Month-long iterations of work with potentially no viable changes after each one. When I read about agile it tends to describe stuff where you can muster up an MVP for a feature within a week or two at most, so it has been tricky to interpret how to apply it. So basically, it's not working great and I have limited influence to change things. What I can do is fight my team's corner with well-backed arguments. E.g. there was recently a period of a few months where the entire platform team (~25 people) took part in a daily standup lasting 30 mins on average, on top of their own squad catchups. This was obviously wasteful but the engineering manager liked feeling ontop of things. After I repeatedly raised the issue, the frequency got dropped to weekly for my team and twice-weekly for the wider team. So I'm keen to learn more about agile vs alternative systems so I can continue to fight effectively my team's corner in this way. The ideal end-goal would be to extricate my team entirely from this half-baked agile mess, whether that means following agile more "correctly" or switching to something more bespoke. I appreciate the references and have started glancing through "Agile Estimations and Planning", it's okay so far but nothing revelatory. I don't have a lot of time to devote to this so I'm naturally skeptical of "just put in lots of hours of reading and I'm sure you'll see the benefit".

JKCalhoun 2y ago

It's maybe a bit orthogonal? (Or maybe misleading.) I'll fill in with anecdotes and try to make more sense: When I started at Apple in 1995 the way things got done was: you worked with a team that focused on, for example, the graphics frameworks of the OS. One engineer was tech-lead. They went to SIGGRAPH, tried to have their finger on the pulse of the "industry" and, of course, what our users wanted ... in terms of graphics on the platform. So a new OS meant an opportunity to add some of these desired features to our frameworks. Tech-lead generally called the shots, chose various engineers on the team to own various parts. And so we coded. And maybe I am getting a bit off topic here, describing something more like "ownership" for a dev on a team: We still had company-wide mandates but again it would be an engineer on a team that either volunteered or was selected to take responsibility for some "deliverable". When the Mac was moving to PowerPC I was handed the "color pickers" from the Mac source base that were written in 68K assembly, I was expected to get them to compile for PPC. In addition to rewriting them in C, I also cleaned up the SPI that allowed the color pickers to be modular. I wasn't asked to, but I wrote a crayon color picker, an HTML color picker to test the SPI and because, at least with the HTML picker, I thought users would want that (the web being the new thing). I had no idea then that it would not always be like this. On one hand, having to port code from 68K to C was definitely an example of the constant change I would see over the coming decades in my career. But no way did I see coming engineer-as-commodity (and I think of Agile like this, engineers are interchangeable cogs), the flip to top-down control (as in management or design telling engineers what to do instead of bottom-up where the team itself made many of the decisions). I'll end with this: I loathe agile development. But I have seen engineers that thrive in that environment so I am not one to condemn it. For engineers that seem unhappy I have always suggested that they be given a piece of code (or class, or part of a framework, or a whole framework if it is feasible) that they can "own". And by own I mean they make all the changes, fix all the bugs, etc. They own the tech debt, are free (time permitting) to toss everything and rewrite it if they choose to. They chart the direction of the code going forward. They become the domain expert of that code. For many engineers (and me of course) this can be the most rewarding way to work. The only pushback I hear from those agile-minded is, "What if that person leaves? Now we have no domain expert regarding that code?" They're right. Someone else will have to take it over. Perhaps even a new hire. And soon they too will "own" it — may even rewrite it. But we're engineers, we can figure this shit out. ;-)