One thing I think missed in this is talking about one of the reasons to break things down into the smallest portion - it's not only the metrics, but it's to make everyone look the same to management. Each person can take any of the work, in theory. In practice, this never happens. You'd rather wait for the expert to do the work, because it will take them less time and probably produce better quality. Good people become the bottlenecks and you aren't sure what to give the people that aren't so good. Estimates given by the subject matter expert (the only one who could give an estimate) are way too small because it implies they will be doing the work. And there's this feeling that by spreading out the work over a whole team, that the bus factor is increased and it is worth it to have everyone understand everything about everything. But there is a definite tax in terms of productivity, speed, and quality.
> Estimates given by the subject matter expert (the only one who could give an estimate) are way too small because it implies they will be doing the work.
If you play the pointing poker game you tell everyone on the team (of people who might have to work on it) to make an estimate, and if they're unsure then to estimate high. Then you can take the mean, or the highest estimate, or talk through the concerns and come to some consensus (the consensus includes things like "we need a lot more information before we can estimate" or "we need to break this up more").
If an individual is estimating the level of effort for work that could be given to any number of people then I think the estimation system needs improving.
I generally agree with the rest of your comment, though.
Honestly, I've never found story pointing exercises to result in anything resembling reality. Maybe if it's a task you've already done a hundred times and everyone knows "oh it's just doing that ...". Anytime you move into creating something new, you're basically hosed. Especially if you have heterogeneous work streams in the same sprint. That just any hope of planning things that much harder.
> Honestly, I've never found story pointing exercises to result in anything resembling reality.
IIRC, story points are a replacement for detailed hour estimates that were created specifically because of research dating back through the 1940s shows clearly that estimates of original intellectual work of any detail are essentially impossible; story points are literally throwing in the towel on that issue and wasting less time chasing something you aren't going to get. With tracking of velocity and history you get better numbers with story points than when people try to estimate in hours, because people are better at rough relative size estimates than detailed estimates, but that's a marginal improvement. The big win is you spend less time chasing false precision with them.
That's reasonable ... The times I've worked with hour based estimates, we were assigning tickets to people up front and there always had to be a bit of a scaling factor based on who was doing the work. (mostly relative to their skill level and how familiar they were with a particular piece of code). There are at least a couple of no-nos for scrum style processes in there. Still, I find it more useful to look at the number of tickets and what's actually being done in them and ignore the point/hour values when trying to come up with what's a good break down of work for a sprint. The point values are just too opaque to convey anything that can be substantively predictive. (At least for me..)
> Honestly, I've never found story pointing exercises to result in anything resembling reality.
I've never found story pointing exercises to provide anything meaningful. Goodhart's law in action; you either ignore the story points, making them useless, or you use them to estimate productivity, causing people to game them.
I understand that gauging velocity and individual contributions is important, I just think story points or work estimates are a bad way to do it in the context of sprints. An individual task, or even a sprint, is too micro to get any decent measure out of. I much more strongly prefer evaluations based on longer milestones (monthly or quarterly). Someone being low on story points for a sprint means nothing without a lot of context on why. Someone missing a milestone on a month or quarter long project is much more indicative of a problem, because they've had enough time to ask for help, or to smooth out bursty progress.
This is actually kind of disturbing to me... I didn't think story points were supposed to be used as this kind of metric. Linking performance to story points seems like a complete misapplication of something that is supposedly meant to help determine how much work can be put in a sprint.
> If you play the pointing poker game you tell everyone on the team (of people who might have to work on it) to make an estimate, and if they're unsure then to estimate high.
I think this is great advice in general, and I try to follow what I call the Scottie rule. Multiply your estimates by 4. That way you're a miracle worker! Or if you're like me, you might finish it on time.
I think there's some ego stuff going on though in planning sessions, and it seems bad estimates are rarely punished. And you can't really learn from it, since you always think "this time it's different."
I've said it before: one of the goals of Agile methodologies as sold to management is the promise of emulating a good developer with a redundant array of mediocre developers. Good developers can produce good work fast. They can take feedback on an iteration and turn it into working code for the next iteration quickly. But they're unreliable -- prone to getting cranky or bored -- and they're a single point of failure: If they die or quit because they got too cranky or bored, million dollar projects can be put in jeopardy.
But by spreading the work out over a team and making them collectively responsible for the code, and by keeping them constantly in communication, it is hoped, you can take advantage of their cumulative brainpower to get good developer quality and turn around time while smoothing over the reliability issues because any one developer is fungible with the rest.
It is hoped, that is. Reality is usually quite different...
I had a project assigned that I was completely responsible for, except that every technical and architectural decision was made for me. As I became more familiar with the project I raise concerns about these choices as they introduced maintainability and performance issues, but was overruled and told to stay the course. The project was a failure.
I feel like if you're not coding a project, your opinion on it is less valuable and should be secondary to the primary contributor. After all, the manager doesn't maintain a project. The person who built it does.
That sucks. I worked in a role where I had to make decisions like that for the "implementers." Nobody liked that system. I left and so did almost everybody else.
In my current company, design tasks are just tickets, but we tend to assign implementation tasks to the same people who did the design tickets, when possible. However, design gets done in isolation, with little to no consultation. Some factors can trigger a design review, but it comes so late in the process that changing anything at that point is disruptive and regarded as a kind of failure.
Much better (in my opinion) is for one person, who will also implement the design if plans permit, to be responsible for the design, but the process of designing to be done "in public." Somebody is responsible for making sure the design is done on schedule, documented, etc., and they have the final call on any contentious issues, but it is discussed by everybody who is interested, and the meetings are publicized and open to anybody who wants to come. Since it is public, you get ideas from the most people, raise awareness so negative impacts to other systems are more likely to be spotted, and generally raise the level of understanding of the system as a whole among all the developers. Since it is individually owned, there is a single point of contact for product and management, it's clear who needs to be allocated time for documentation and research, and the implementer gets to feel a sense of ownership.
I made a presentation on what I was supposed to do and what I was actually going to do instead.
I detailed everything, made it clear where I was ignoring my actual assignments.
It was done in a tongue and check manor, but also completely serious.
I finished A massive platform migration project in under 3 months. Solved nearly of the reliability and performance issues. And our build time went from 18 hours to 20 minutes.
I am lucky to work with a reasonable company that prioritizes people over methodology. We follow Scrumban - something between Scrum and Kanban.
We have sprints, tickets, story points, daily standups, but it is humane.
Before sprint starts, tickets are estimated and assigned to developers. Each developer gets more-less the same amount of story points. Since the codebase is very big, if possible, a developer would get tickets related to his past tickets. A developer would own a certain feature of the system. We can trade tickets with each other. Usually, tickets are overestimated a little, but we are encouraged to adjust the story points of our tickets to match reality. In case of an urgent issue, anyone can add tickets to the ongoing sprint, but it is done sparingly. It's okay if it takes two times longer to finish a ticket sometimes. It is also okay to say on standup that you didn't make any progress on your tickets assuming you've been busy doing something else related to the project. If the ticket is big and the end of the sprint is close, the pull request would be merged at the beginning of the next sprint. Finally, the release can be delayed for a couple of days if necessary. Every third sprint is a tech sprint. The goal is to improve the system. Anyone can write a ticket and work on what he wants pretty much.
In conclusion, it's about trust and being professional. The methodology is just a baseline that sets the tone. It should be followed for as long as it makes sense. There should be a clear goal. In our case, it is to have a stable system and a healthy workplace.
This. I do believe that the act of breaking down tasks helps clarify assumptions and helps paint a more accurate picture of what needs to be accomplished for a particular task. Can breaking down the task into small bite-size chunks be a little demoralizing? Maybe. But I don't necessarily view it that way, assuming that the person owning the task is part of the initial conversation.
In short, the breaking up of tasks should be a conversation, not some top down mandate.
> Every third sprint is a tech sprint.
Can you elaborate on this? I love the sound. I get pushback even suggesting a tech sprint once every 6 weeks. What kinds of projects fall under here, and do you still work on product? What's the product team work during this sprint? Thanks!
It is very similar to a normal sprint, but instead of adding new features, our goal is to improve existing features, the system, or the process. It can be technical things like upgrading to a new version of PHP, of a framework, or a library. It can be anything related to technical debt. It can be some proof-of-concept. In one of such sprints, I've introduced cypress and made a couple of tests to demo it.
The tickets for this sprint come from anyone. Usually, when working on a ticket you sometimes get a brilliant idea. Write a new ticket with that idea and add it to the tech sprint proposal. Before the tech sprint, the whole team participates in sprint planning. We go over tickets, review them, and decide whether they should be done. Usually, we assign tickets to ourselves. We also estimate how many story points they will be. Ideally, it should take less than 1 week to finish. A maximum of the whole sprint of 2 weeks is allowed. Otherwise, it is divided or multiple people work on it.
IMO the problem with this approach is it draws a line between “tech debt” and “progress”. So in the end, the team will overcompensate to do less and less “tech debt sprints” or start expanding it into an occasional “tech debt half”, and so on.
What I think works better is having a tech debt related goal _as part of product work_: instead of estimating you’ll work on feature X, also add time and be explicit about tackling issues around X. This also prevents wasting time on debt that’s not really relevant (is a piece of code that never fails and never change really worth rewriting?). This makes it easier to tackle it over time, easier to sell to product & management.
“Tech debt” itself is a bad term IMO - it isn’t an aspect of software that’s easily identified (unlike, say, compilation warnings), and you can’t count it as money-debt, so I always found the concept of “paying it down” sorta counterproductive. But that’s a different topic altogether.
The first section had me screaming, YES, YES, YES... Now I don't have to write this very article about the difference between actually trusting and empowering your engineers and giving them little tasks to do.
A lot of the rest applies to big companies.
However, I would change the conclusion, because the thing is, the culture of "little tasks, little trust" has taken hold even where there is no bureaucracy and no specialization of roles. It happens at start-ups as small as three people.
The antidote is simple, in the start-up case: Give each person one or two big projects to focus on, based on their strengths and interests. Carve up the work by large areas, and give people ownership and responsibility. Look at each person as individual. If someone has no talent or interest in product decisions or UX decisions, they'll need support on those, or a project that doesn't require them. If they have interest and some talent, mentor them. If, as a company, you are trying to make progress on too many things in parallel, or have a shortage of talent in certain functional areas, be real about that.
Frameworks and style guides and even "database guys" aren't a problem, if they are good and support you. However, I think the ideal is probably to have small project teams that grow from one to, say, five people, each containing engineering, product, and team management talent, and not enforce conformity across project teams over team productivity and happiness.
Edit: Though honestly, a lot comes down to individual preferences. A lot of engineers love being handed a style guide. A lot of engineers love doing tasks off lists.
How do you make people collaborate, in a scenario like that, where each person has 1-2 projects of their own? How do you prevent these projects from becoming “niches”, and expand in complexity to take the entire time of each said developer?
The way to go about a collaboration depends on the reason for the collaboration, and why it's a better idea than not collaborating. I don't think there's a general answer to how you "make" people collaborate.
The question about project scope and resource allocation is also hard to answer in a general way, as I'm not sure why it would be harder in the world I'm suggesting.
I'm a software architect and how I handle this between my teams is:
+ Set an expectation for teams to raise difficult problems they don't know how to solve for guidance
+ Help teams meet and determine standards and contracts together
+ Make sure teams have the power to make bold choices within their own domains
Sometimes these go a bit off the rails or a less optimal choice gets made and frankly... that's fine. Mistakes are where we learn and letting engineers make mistakes and recover from them is part of letting engineers grow.
Being an effective manager often means buying cover for your team to do their work and evolve it organically.
Totally agree. Reminds me of a quote from Peopleware:
"Most managers give themselves excellent grades on knowing when to trust their people and when not to. But in our experience, too many managers err on the side of mistrust. They follow the basic premise that their people may operate completely autonomously, as long as they operate correctly. This amounts to no autonomy at all. The only freedom that has any meaning is the freedom to proceed differently from the way your manager would have proceeded. This is true in a broader sense, too: The right to be right (in your manager’s eyes or in your government’s eyes) is irrelevant; it’s only the right to be wrong that makes you free."
“Sometimes these go a bit off the rails or a less optimal choice gets made and frankly... that's fine. Mistakes are where we learn and letting engineers make mistakes and recover from them is part of letting engineers grow.”
So true. I often pity the young people who are starting now with complete micromanagement by JIRA, Scrum, daily stand up and pull requests. When I started out 30 years ago you could often go away and work on something for a month or more, try out stuff, screw up royally, learn from it and become a better programmer. These days it often feels like an assembly line where every step is optimized but no creativity is allowed. There is no better learning experience than to develop a system and after a few requirements changes to learn that the system was misdesigned. Good programmers will work through that and do better. Bad programmers will just shrug their shoulders.
Right now my strategy as a tech lead is to of ask mainly if something is holding people up, act on that quickly and be available for discussions, but otherwise I am trying to hold back and let people do their thing even if I don’t agree. But this takes strong nerves with line managers and project managers breathing down your neck.
I'm on the hunt for a manager that understands principles like these -- if you need someone with the wide-ranging skills of an experimental physicist, please get in touch. Email is in my HN profile.
I volunteered for a non-profit where we had a model of "accountability" that worked very much this way. Leads weren't told how to do it, they were just given the accountability of making sure it was done and the autonomy to decide how it happened. If a lead quit, that accountability fell to that lead's lead. This led all the way up to the President of the org who would be accountable for everything should everyone quit. It worked fabulously well. We were all volunteers (~250 members). The closest thing I've seen to this in the paid professional world is the holacracy model of business organization. Despite my best efforts, I was unable to convince my current company to grow this way and now we swim through a deep pile of jira tasks, assigning them out to devs one by one with nobody having a clear sense of ownership of anything ever.
sure you can, most people dont stay at companies long term, so it's not especially hard to get promoted to some sort of management position if you stay a couple years.
"Design belongs to management" is actually the best case for work broken down into itty bitty tasks. The worst case is "design only happens in the sense of figuring out how to hang the new thing off the side".
Agile coding is supposed to contain refactoring where the existing system is redesigned to be more coherent, after each step of mere accretion. But this is never treated by management as equally important to the task-work, so it always gets bumped.
"Design belongs to management" is definitely better than "no design at all". But this needlessly conflates leadership and management. There is no reason that the most capable at design would also be most at home doing all the other management tasks like performance reviews and inter-team communication that are typically the managers' domain. Also vice versa btw: I've seen multiple times how people wanting to grow as people managers would have to make deep technical decisions (on the spot, no time to ask the team about it) about things they had very little experience with.
An even better spot in the solution space would be to separate people management and tech leadership into different roles to be filled, though for this to work a high level of trust between the types of leader needs to exist.
The benefit of the tiny tasks model is that you don't build stuff people don't care about. Features/bugs exist in a survival of the fittest world and the lowest priority ones never get built/fixed. This was one of the big problems with "hero in the back office coding for months and emerging with a product".
The tiny tasks model also lets you ship updates to the end user much faster and also ensures the product is never in a half-broken state. It's also more robust when you don't have a team of all-star programmers.
I agree that building big projects on your own (or with a tiny team of motivated folks and no mandated meetings) is way more fun and sometimes far more productive. But that's why I think it's important to incorporate things like hackathons and prototype phases into the engineering department. Each software development model has its strengths and should be used when appropriate.
I think you're missing the point here. The point isn't coding in isolation is good, nor that we shouldn't break our work down into smaller tasks, it's that the developer should be given the responsibility and freedom to decide what those tasks are for their work, not dictated from above.
If I'm responsible for project A, I should be able to make 85% of the decisions for that project. Too often, recently, development organizations make every decision from above, then break that up into miniscule tasks that require no thought from developers.
Hackathons, IMO, are just gimmicks to gloss over a deficient product management group or software architecture. If your organization can't be convinced of the need to spend time on something outside of a gimmicky "hackathon", then something needs fixed.
I don't think hackathons are always a gimmick, but then again I was probably too loose with my word choice. I mostly meant a period of sustained cooperation with a small group where most of the time is spent together, all meetings are canceled, and you don't try to split up work into bite sized pieces with any formality (like a story/jira ticket).
I agree that organizations that don't trust their engineers with any design or implementation decisions are wasting their talent and probably creating a lot of bored and burned out engineers. If an engineer wants to use a fancy new piece of tech and they can justify it, let them do it.
Currently my manager gives me tasks like "so and so needs something, you should talk to them." That eventually becomes a bunch of tiny tasks, but I don't receive the work pre-chewed.
I agree that there needs to be a balance. I disagree that hackathons are the solution.
Hackathons are usually what management comes up with when they think about this problem. However, I guarantee you that this conversation regularly happens among your developers at Friday happy hours:
- So how's that project Z going?
- You know, same old. Looks easy in theory, and every little task is a slog. I spent this whole week fighting the Blorgifier again.
- Wait, that abomination is still in our codebase? That was a hack we came up with at 3am during one of those death marches last year when we needed to ship something for the Initech demo.
- Yeah, you know what they say. Nothing more permanent than a temporary bandaid. I wish I could have a week of my time back.
- Yeah... cheers!
There will always be very important seeming bugs that have a great definition and visible customer impact. Unfortunately, obscure poorly-defined tasks like "rewrite the Blorgifier" immediately trigger a response of "that's just developers wanting to have fun" in managers. And they end up adding a tax on every single one of those important fixes until eventually the whole thing collapses under its own weight.
How to solve this? Ask the developers what's important to fix? Nah, they don't know how to plan a project and don't understand the customer.
Does this mean that developer pet projects need to get 100% time allocation? No. But in most companies their time is undersized by a factor of 1000 or more.
I won't reconstruct the reply I wrote to someone else but I agree hackathons are not a silver bullet (and I probably misused the term). Solving the tech debt problem is a whole other can of worms.
At the same time, how many of us have been burnt when delegation goes wrong? I think managers have a "fool me once shame on you, fool me twice shame on me" attitude that inevitably leads to small tasks and less delegation of responsibility after a few bad experiences with developers wandering off in the woods and building what they want and not what is needed.
Delegating and trusting someone doesn't mean a task never goes badly. Part of delegation is meeting and touching base with work that is ongoing. Participate in code reviews, have regular 1:1s with people you are delegating to.
And yes, you're not going to end up with your exact vision when you delegate. The question is whether the end goal is sufficient and minimal, and if not then you should evolve that with the other people involved.
Absolutely delegation should still mean being involved in the process and being receptive to course correction from the people carrying out the work. This is how things should work.
Ideally.
In practice I've seen it go the opposite way where management's reaction is trust less and less, making smaller and smaller tasks. Developers aren't innocent either, instead of griping about having less control, they throw up their hands and work-to-rule. Doesn't matter if the task description has obvious problems, that's what is getting implemented. Nothing less and nothing more.
Honestly this all comes off as toxic. Maybe it's high time to leave where I am seeing this all go on.
In my view, if you say, "I'll never trust someone again if they ever make a mistake," then you'll be deservedly miserable as a manager, and you've never raised kids. ;-)
You might have to take baby steps. Can you watch someone make a mistake without intervening? Can you do so without severe emotional turmoil?
Most managers never break the micromanagement habit, and will always pay the price. Probably the biggest price of not trusting people is that they don't trust you either, and they find ways to keep you out of the loop so they can make decisions and get work done. This in turn causes you to trust them even less. Distrust is a self fulfilling death spiral.
You might have no choice, e.g., if you work in a micromanagerial culture. Can your boss watch you, as you are watching someone make a mistake? In other words, are your management habits the source of a culture, or merely its effect?
Thus the final step is: Can you stick up for your people after they've made a mistake?
The answer to that is to sit down with the developer -- like an adult -- and talk to them about priorities in terms of what the user wants and the business needs. Just tell them point blank, "the thing doesn't need to read mail, but we really need features X, Y, and Z to have an MVP, so please concentrate your efforts there."
Some of my best jobs involved constructive discussions with my managers just like this. If a developer is any good, they're smart. It's okay to treat them like a fully functioning person.
The bigger problem is that if you delegate A and B to Vincent as the article suggests is that often it becomes King Vincent lord and ruler of A and B. They are the only one allowed to touch A and B, and worse may be the only one's capable of touching A and B. You can end up with a bunch of these little fiefdoms and getting anything done quickly becomes an issue of appeasing a few petty despots.
That's a little bit extreme for example but there's definitely benefits to standardizing things across projects.
Not really. Even if you have one person architecting the system you will have at least a couple developers implementing. Knowledge will be spread across multiple people preventing any one of them being indespensible.
The author has another article about that. They’re allowed to be the lord and ruler of A and B, but also responsible for them. A and B are the consistent bottleneck to release? Maybe B should belong to someone else. Petty despots don’t get to keep their toys.
I think there's also a sort of a tension with this approach of little tasks with little trust and the complexities of modern code. Many small tasks involve a pretty in-depth understanding of a large stack to do correctly. This understanding is not easily developed if the programmers are not encouraged and empowered to explore how things work and having little trust in them is the opposite of encouragement.
So at the end programmers have "small" tasks but they end up being ill equipped to solve and become despondent.
This describes my most productive, successful work environments pretty accurately.
I still believe in breaking down work into small tasks and estimating them, but that should be done by the individual (or small team) doing the work. Estimates also need to capture the level of uncertainty.
I still believe in frequent status updates with the manager, but those should be informal and (often) initiated by the individual/team.
When driven by the employees, the act of breaking down tasks, estimating, and reporting status can do a lot to build trust in the eyes of management. However, that autonomy first has to be granted by management first.
This work style isn't just for senior engineers either. The scope of responsibility should be smaller for junior engineers, but the level of autonomy over that scope should be relatively constant.
The best managers I have had hate micromanagement and generally refuse to put up with employees who require it long-term.
> Estimates also need to capture the level of uncertainty.
As a junior developer, I was asked to provide LOEs for tickets and tasks. I just looked at my boss. "How should I know?"
"Come up with your best answer." So I did. I gave him my best guess, plus some error bars. The error bars were promptly discarded. And while when I went over estimates I didn't feel bad, there was obviously some static there from my boss when things went "over estimate".
I have harbored a lot of suspicion towards the process of ticket estimation and "story pointing" and the like ever since.
A manager who cannot deal in error bars is not doing their job correctly, although I would also point out that it is important to re-estimate and update your boss as soon as you think you will miss the estimate (which you may have done).
In my previous environment, we were only allowed to give estimates in terms of a range of time.
We had a series of predefined "buckets" of time ranges (e.g. less than a day, 1-2 days, 2-3 days, 3-5 days, 1-2 weeks, 2-3 weeks, 3-6 weeks). As the estimates got bigger, so did the error bars, and if a task didn't fit comfortably into one bucket then it was upgraded to the next.
We also had design discussions and poker planning for all of these tasks. Estimates were almost always accurate, even if they weren't very precise.
I mean, I was a junior engineer. I didn't know when I was gonna miss the estimate, when you're heads-down like that you don't know if you're 25% in or 80% in until you've gotten a lot more experience. Hence the error bars in the first place. ;)
Can you explain what happens when e.g. you need to merge your changes into product and your PR contains an unsuitable approach. For example, that you used multiple external libraries when none are needed?
Like in any engineering environment, you submit a PR for feedback from your peers, and you have a discussion about any changes that might need to be made.
Is there a reason why you did not think that would be the case?
I think you can have both, especially for younger people starting out in their careers having a set of tasks to work through can help them account for their productivity.
Also, I have found a list of tasks on a post-it note to be much less demoralizing than a set of tickets listed in a tracker.
This post reminds me of the phrase "you can delegate authority, but you cannot delegate responsibility." Has anybody hear this before? I found a blog post [1] that attributes it to "an old saying of the US military".
* Authority means that you have the power to give orders, make decisions.
i sometimes put little rants onto social media about how micromanaged work is, & especially how jealously developers time is guarded- work on the ticket, one ticket, nothing else! this is a much better reasoned foothold.
i have felt very alone for feeling the wrongness of this completely accepted seemingly 100% universally deployed new "agile" process. i miss the old days, of having big tasks, and freedom to work widely on them, figure out where the good opportunities lie. hearing someone else, anyone else, speak out that they think other ways may have value, it's relieving to hear. just a little bit de-alienating.
I am a front-line coder but if I don't restrain myself I will usually be the #1 person for creating tickets in the ticket system because I like to split tasks into great detail enough to drive my co-workers nuts.
There was a time I did updates to a web form application and I could break the work down to tasks in 10 minute increments and plan it would take six hours and I would really get it done in 5.8 hours. The design of the application helped because the changes I had to do were all straightforward within the existing framework.
An alternate model for "development" is fast cycle run-break-fix. Even if you are planning to deliver good "user stories" or whatever makes the project go forward there is some probability that the tester will say your code failed, some probability the tester is right and that the ticket gets sent back to you.
Sometimes before you send it to the tester you might try a few "failing" solutions before you find one that works; so instead of a model that you'll take "12 hours" to develop something rather something like a Markov process where maybe you get lucky on the first try, but it may take several attempts.
Hopefully you learn as much as you can from these attempts, maybe the first draft was written when you didn't understand the problem, the second draft was basically right but there were 1d4 places where it gets hung up because of an interaction you didn't think through and etc.
How long did it take you to create all the tickets to break the work down into 10 minute subtasks?
Whatever ticketing system you're using must be fast as hell if you're able to do that and not spend more time doing data entry than actually doing the work...
I a big believer in the fact that splitting tasks into little micro bits that we work on in isolation is really holding teams back. Sizing work so that it's big enough to be of some value delivered to your users is a great way to actually getting your team thinking about the big picture and the impact they're having and to encourage your team members to work together on delivering that value.
You don't need to slice and dice stuff into tiny tasks. You don't need a manager handing these tasks out to team members. You can have teams that self organize and have a laser focus on the impact they deliver.
I'll admit I'm quite biased as I'm the founder of a startup [0] that builds a product management tool that encourages teams to have larger work items where they can capture a whole "unit" of value delivered to users. Teams use our work items to write a lot, attach designs, code snippets, etc. When they need to break down stuff, just add a todo list in the work item. We also don't have a notion of single assignees, but instead allow groups of users to be set as the team for a work item. My cofounder wrote a blog post on "right sizing" work items [1].
All of those tools have a mismatch between how different people involve see their work.
At one end there is the "user story" which can be great for envisioning but a poor match for describing the work that has to get done. There is also the "bug" found by the end user or by the tester or the code, not to mind the "feature request".
People see those as different but when quality counts the coder is going to do the same thing no matter what a change request is called. A change request can also be scoped to subsystems, such as a web front end vs a back end. There are many reasons to keep separate paperwork for those systems (maybe different people do the work!) but when the tester fails it, the tester has no idea if it is a front end problem or a back end problem so it is 50-50% they will fail the right ticket, etc.
Though the Little Tasks Model is very good for beginners joining the software development industry (as they can quickly come up to speed under this model), this is an absolutely terrible model for senior developers, as this model by itself limits freedom, growth and career progression as it is difficult for senior developers to prove their worth when they are only given Little tasks perpetually.
I think small tasks can be good, but in a mix with large overall responsibilities. Some days you aren't so productive and that can be a good time to pick off a lot of small tasks, but your work starts to feel demoralizing and incoherent if you don't have a main thing (imo)
Well said but the fact remains it's easier to feign people management when attending to technical Tasks. Tracking Responsibility tends not to fit the mold of HR mandated performance accounting.
This essay is full of awful advice and is more about the author venting that their work isn't organized how they like. I would recommend they found a startup and experiment with the kind of structure they think would work best and see how it scales!
>No backlog grooming meetings or burn-down charts either. Your manager simply looked at how your products were coming along. A little trust, some accountability, and a healthy portion of “give me some space to do my work.”
The author speaks as though they have never been in the situation where their team delivered a product that meets the spec but isn't actually useful to their customers. Agile (what the author means when they speak about tasks/backlogs) doesn't guarantee this problem will be fully solved by doing by-the-numbers scrum or w/e, but the system they are flirting with in this essay is almost certainly worse. It's a complete recapitulation of waterfall/cowboy and adhoc design processes, without the honesty to interrogate why these processes failed organizations large and small.
>As I see it, little tasks are born of a fundamentally different management attitude. Small tasks are a not-so-subtle way of saying that all the product vision lies with management. Keep away. Don’t touch.
The author is talking, here, about how encountering agile makes them feel. This is not a universal experience. I would reply that we have a division of labor/responsibility because technical personnel are often some of the worst people to speak for the customer, and history has born this out.
>Then you went back to your private office (I sure miss private offices, but that is a topic for another day) and fixed a few things. Later, in a weekly status meeting you would tell people how it went — yep, that’s right, no daily stand-ups where you look mournfully at your shoes and admit that you didn’t make any notable progress yet.
Once again, the author is telling on themselves If they don't like feeling like they aren't making progress, it's almost always because they aren't motivated or need help. Certain team strutures (e.g. Mob Programming) actually produce incentives for this sort of task-going-nowhere problem to be addressed constructively (also against silo-ing, another perverse tendency that this author implicitly endorses throughout the essay).
As an aside, I agree about the communal working space trend in tech being shitty, if you team can't work communally. This is a problem that agile practices are only beginning to address (again, please see Mob Programming for a way to deal with this).
>Sadly, as developers, we do it to ourselves as well. Once someone gives us a better title, we are right on board with the program. When a regular developer might have had a chance to do some research or design, we immediately snatch it away for ourselves.
This is a philosophical non-sequitur. How are tasks related to snatching design work away from non-architect/technical-lead developers? Any team that wants to spread around design work can address this and whether a team does agile/task-based work has no bearing.
>Worse yet, we design every product’s architecture, and expect any deviation to be approved by us first. All that is left are tiny morsels. Grunt work for the foot soldiers once the fun has been stripped away.
The author moves and back and forth between speaking as a grunt developer and speaking as an architect/technical-lead, and it's quite confusing. They are also, per their bio, a fan of "organizational self-management". Furthermore:
>“I am Amerigo, the product guy. Heretofore, no developer will make product decisions, for they are mine.”
>“And I am Ferdinand, process guy. Heretofore, no developer will make process decisions, for they are mine.”
>“I Bartolomeu will enforce compliance.”
>“I Vasco used to be pretty good at Microsoft Access, I guess I’ll be the database guy.”
I feel like you put all of these things together and get a picture of a programmer who I, personally, would be absolutely terrified to allow in front of a customer, let alone expect them to work constructively with other functional stakeholders.
For the record: I'm a technical lead in a medium-sized (~150 developer seats, many more non-technical roles) enterprise software organization. Most of my experience is in the enterprise/consulting space and my perspective reflects that.
I think the kind of unstructured/responsibility-based approach the author advocates is naive and says more about their problems working with others than it does about how dysfunctional agile can be. I think the main barriers to teams delivering is how to cooperate to deliver consistently and sustainably, and not that rockstars needs to be set free to pursue their own agenda within vaguely defined boundaries of responsibility.
Whenever anyone says "no, the problem is completely with the other guy", usually they are the ones with the problem. Did you notice how many insults you hurled at the author? And what is his offense exactly? Writing something you happen to disagree with?
Ask yourself this: could it be that some people on your team, on some days when they are frustrated, sleep deprived, and stuck on a problem feel like this guy? Do you think they would be comfortable discussing this with you given how you react?
I took a similar feeling away from this comment. It reads like someone who feels the need to defend a top down model of control. In my experience, these models are really more about perception management and creating the illusion of productivity while a lot of developer talent under their umbrella is wasted. I might be a bit jaded, but I honestly think a lot of the popular "agile" methodologies of today are directly responsible for the commonality of software bugs and glitches in production code. Most devs today will never get to experience a feeling of ownership over the technology they ultimately produce.
Personal attacks aren't allowed on HN and we ban accounts that post like this. Would you mind reviewing https://news.ycombinator.com/newsguidelines.html and using HN in the intended spirit? We'd appreciate it.
Personal attacks like this are not allowed on HN—it's not what this site is for. Perhaps you don't owe the other person better, but you owe this community better if you're posting to it, so please don't create accounts to break the site guidelines.
As much as I understand the frustration here, the reason why programmers aren't trusted to make decisions is because they've consistently failed to earn that trust.
Big tasks with lots of room for error is what gave us the platforms of the 80's: barely-usable "power" platforms like Linux, over-promise-under-deliver demo OS's like Windows 95, the pile of hacks called The Web, and the pile of less-famous code that gives rise to organizations with names like Destroy All Software.
The micromanagement might not be much better, but acting like coders should be given more trust and responsibility is laughable.
The examples of bad software given are two of the most popular and widely used OS's of all time, and the internet. Are these things piles of hacks? Yes, but for Linux and the internet, they are arguably antifragile, and are so because of the way they're made. They have stood the test of time in a way that no top-down managed product has done that I'm aware of. The world would be so lucky to get another Linux-like project and another internet-like project.
