NOTE: I moved on from DirectScale in late 2017. However, I stand by the principles I describe here, and I’ve made an effort to bring them on board ...
For further actions, you may consider blocking this person and/or reporting abuse
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.
These are some great realizations here. I love seeing stuff like this. I like your four questions to recruiters. Developer empowerment is a very valuable thing, but can be tricky to get insight into without actually working, or knowing people, at a company.
Most of what you moved to would more traditionally be described as Agile. The emphasis on collaboration is key (e.g. including dev team at all levels of the process, swarming, getting critical feedback as early as possible). The "Agile" scenario you described initially did not sound Agile in the slightest. I am lucky to never have worked for a company with such a process that had the audacity to call it "Agile". Not including the dev team in writing stories, and at least enumerating the possible code tasks is a woeful mistake.
The Dev Design idea is pretty cool. It's a very developer centered twist on something I've seen a lot in practice, which is to collaborate in writing all user acceptance tests before any coding begins. Both strategies can work well, because they have the goal of gaining a shared understand of the work before any time is wasted implementing the wrong thing.
I've heard a few people with similar "that's not Agile" responses to the scenario I describe, and while I fully agree, I think perhaps the downfall of Agile is its vagueness. It's too easy for a traditionally-structured company to say "of course we value individuals and interactions over processes and tools, etc.", tell everyone to do standups and sprints, and call themselves Agile. And it doesn't help that a lot of "Agile coaches" and "Agile product managers" don't understand Agile either.
The worst part is that a naive, bandwagon implementation of Agile is significantly worse than no Agile at all. One of the first places I worked as a developer, the implementation of Agile was unbelievably bad (and yes, they called it "Agile" without batting an eye, because there were sprints). They kept trying to solve their problems by reorganizing -- there was a complete restructuring of the development teams every 2-3 weeks -- and turnover was through the roof. I constantly felt like I wasn't allowed to be productive. I didn't last long there.
As good as the Agile manifesto is, there ought to be a sister document describing what Agile is not. I'd love to see some of my former managers' faces when they read "Agile is not about daily standups! Surprise!" I guess that's my next project.
I feel I have read the work of great artistry. I love all that we have brought out here. My question would be how do you and your team handle deadlines ? Say the gray suits people in the meeting say its time to step up ? Do you guys give a summary if the answer "Our team is responsible for a product... we got your back but some features here need a little more time" ? How do you still manage expectations and still keep up with a beautiful, familiar and well managed codebase ?
Thanks! Every company occasionally has reason to cut some corners and deliver early. Some thoughts on that:
1) Most deadlines are imaginary. It's very likely that even if you hit your deadline, you'll find out that most of the stakeholders have already changed direction or don't care that much. It's unfortunate, but that's been my experience.
2) A true high-stakes deadline should only come up a few times a year. If it's more often than that, constant death marches won't help -- it's an organizational issue, probably stemming from issues in management. Lobby for change, and if change doesn't occur, start looking for another job.
3) Constant pressure to deliver will slow down development in the long run. It's death by a thousand cuts. A company that can't take a sprint or two to clean up the code and build a strong foundation for faster development later will eventually end up in a slog, developing so slowly that they might as well be moving backwards.
4) Know what corners to cut, and expect management to cut some of theirs as well. Refactoring can often be left for later; testing often can not. Make sure the gray suits understand what demands create the greatest burden and ask them to compromise.
Hope that helps!