When I started reading it, I thought, how great is it to see the way we work described by someone else. We used to have meetings in, what we called, "the sniffing era" part of the sprint - few days before the sprint planning where we brainstorm new ideas, talk about high level design (or a need for a separate task for it), LOEs and homework for tasks breakdown.
And then, as I continued reading the article, I still saw my unresolved concerns with agile.
You are mentioning the "bus test" and on the other hand: don't treat developers as dairy cows. In my first experience with scrum, we would pass the "bus test", but no developer could feel unique. It's a very good thing for a company, but for developers it's harder to stand out. It's probably some traditional thinking by developers that they need to be unique or own a specific part of a system or a process in order for them to be happy.
In a practical example, it's the same as saying you won't be expert in language X, because we work as a team on a system that has language X, Y and Z. Most people find it as a disadvantage.
I'm wondering if you had any experience with breaking this way of thinking.
For me the despecialization you are mentioning is a way to have more system architects, but in practice we need both architects and people who specialize in specific language/framework/library.
Another interesting concern is how companies grow from startup to a bigger organization. In a startup, if you cannot cut corners and bring more money, there might be no place to come to work the next month. Which means the focus is on constant delivery of value today, which in most cases increases the tech debt. This creates some conflict of interests when the developer acts as the product manager too (somewhat related to the "bus test").
When a small company grows bigger, priorities change and the risk becomes lower, but people are harder to change, so they still want to produce code faster. And again, this change in people's minds is the key to success as the company grows, IMHO.
I don't personally know anyone who would feel like they aren't unique or special enough because they had to learn some new tech as part of a team. That said, we do specialize a little--I'm a JavaScript specialist, and my team also includes a CSS specialist, a .NET specialist, and a Product Manager. The point is that we try to avoid a situation where any one person has domain-specific knowledge that nobody else has. In other words, my team lead is much better at .NET than I am, but between me and a couple of other devs, we know as much about the company's .NET codebase as he does. In rare cases we may choose to divide tasks based on specialty--especially if we're in a hurry--but the Dev Design process ensures that whoever takes a task knows how it should be done, with plenty of input from the specialist for that scenario.
And, of course, this means that any of us can go on vacation for a week or two without leaving the team incapacitated.
As far as technical debt goes, you're right that it's one of the easiest ways to speed up delivery. We've definitely cut our share of corners in the short-term in order to meet contract obligations. But we carve out time to go back and refactor--in fact, we demand it--and the time it takes is not usually an issue because:
Well-architected code is much easier and faster to build on. We are able to move far more quickly now because we took the time to refactor early on.
Technical debt-laden code is a breeding ground for bugs that are difficult to diagnose and resolve. By paying it down, we reduce our future workload.
So I believe that refactoring genuinely saves time in the medium- and long-term, and I'm lucky enough to work for a company that has the funding to think beyond the here and now. On top of that, I like to do it because I'm so much happier at work when I'm working with code that is smart and solid. Again, I don't personally know anyone who's reluctant to take part in refactoring, but maybe I've just been extraordinarily lucky in terms of who I work with.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thank you for the article.
When I started reading it, I thought, how great is it to see the way we work described by someone else. We used to have meetings in, what we called, "the sniffing era" part of the sprint - few days before the sprint planning where we brainstorm new ideas, talk about high level design (or a need for a separate task for it), LOEs and homework for tasks breakdown.
And then, as I continued reading the article, I still saw my unresolved concerns with agile.
You are mentioning the "bus test" and on the other hand: don't treat developers as dairy cows. In my first experience with scrum, we would pass the "bus test", but no developer could feel unique. It's a very good thing for a company, but for developers it's harder to stand out. It's probably some traditional thinking by developers that they need to be unique or own a specific part of a system or a process in order for them to be happy.
In a practical example, it's the same as saying you won't be expert in language X, because we work as a team on a system that has language X, Y and Z. Most people find it as a disadvantage.
I'm wondering if you had any experience with breaking this way of thinking.
For me the despecialization you are mentioning is a way to have more system architects, but in practice we need both architects and people who specialize in specific language/framework/library.
Another interesting concern is how companies grow from startup to a bigger organization. In a startup, if you cannot cut corners and bring more money, there might be no place to come to work the next month. Which means the focus is on constant delivery of value today, which in most cases increases the tech debt. This creates some conflict of interests when the developer acts as the product manager too (somewhat related to the "bus test").
When a small company grows bigger, priorities change and the risk becomes lower, but people are harder to change, so they still want to produce code faster. And again, this change in people's minds is the key to success as the company grows, IMHO.
Those are great questions.
I don't personally know anyone who would feel like they aren't unique or special enough because they had to learn some new tech as part of a team. That said, we do specialize a little--I'm a JavaScript specialist, and my team also includes a CSS specialist, a .NET specialist, and a Product Manager. The point is that we try to avoid a situation where any one person has domain-specific knowledge that nobody else has. In other words, my team lead is much better at .NET than I am, but between me and a couple of other devs, we know as much about the company's .NET codebase as he does. In rare cases we may choose to divide tasks based on specialty--especially if we're in a hurry--but the Dev Design process ensures that whoever takes a task knows how it should be done, with plenty of input from the specialist for that scenario.
And, of course, this means that any of us can go on vacation for a week or two without leaving the team incapacitated.
As far as technical debt goes, you're right that it's one of the easiest ways to speed up delivery. We've definitely cut our share of corners in the short-term in order to meet contract obligations. But we carve out time to go back and refactor--in fact, we demand it--and the time it takes is not usually an issue because:
Well-architected code is much easier and faster to build on. We are able to move far more quickly now because we took the time to refactor early on.
Technical debt-laden code is a breeding ground for bugs that are difficult to diagnose and resolve. By paying it down, we reduce our future workload.
So I believe that refactoring genuinely saves time in the medium- and long-term, and I'm lucky enough to work for a company that has the funding to think beyond the here and now. On top of that, I like to do it because I'm so much happier at work when I'm working with code that is smart and solid. Again, I don't personally know anyone who's reluctant to take part in refactoring, but maybe I've just been extraordinarily lucky in terms of who I work with.