3 ms·

I've never worked somewhere that could actually take a concept to a complete, well-tested feature delivered to users in a two week sprint. I've worked at littl

I've never worked somewhere that could actually take a concept to a complete, well-tested feature delivered to users in a two week sprint. I've worked at little startups and a medium-sized tech company as well as FAANG. In each case, we spent most of our time working on projects with 2-3 month time horizons. The small and medium companies called their development strategy "agile". In FAANG we mostly just did our work and didn't spend any time on the Kafkaesque exercise of "sprint retrospectives" and "grooming sessions". Our product manager didn't tell us what to build, but acted more as an advisor for the engineering team leads. I think in some case scrum is an attempt to compensate for inexperienced management. I assume we just weren't "doing agile", but when I was younger it always left me feeling vaguely inadequate: if I was just more efficient and competent, maybe the 2-week sprint would fit better. Maybe that was the point. Has anyone here ever delivered useful features to users on that kind of cadence? What was it like?

ebrewste 7y ago
When I was doing full stack, solo development, I could get features with real customer value delivered in <= 2 weeks. The flexibility afforded when doing solo development in an area you are competent can unleash some great velocity, but has pretty predictable downsides (can't scale past what you can do yourself, when the project gets big enough, the context switching is a killer, etc.). I don't think I personally have ever hit this level of personal development velocity when working in a group bigger than two people.
anonsivalley652 7y ago
Yep. Agile theater often happens when whoever wears (or doesn't) the PM "hat" doesn't have a clue beyond their so-called certifications and amateur "expert" non-experience because they're afraid of appearing incompetent. Then, it reverts to: Big Design Upfront -> Big Deliverables at the End -> sad, expensive fail. Agile means: - Build-test-feedback-adjust loop is as tight as possible... hours or less to get a fix or a quick feature. - The end-users are involve from the beginning to constantly get what they really need (capture good requirements, not necessarily what they ask for directly) and feedback to make usability/feature improvements. - Someone is prioritizing fixes and features from what users need right now to do something useful, rather than arbitrarily shotgunning features in milestones. - Just enough intra-sprint time is dedicated to test improvements, bug hunting and refactoring. - Using continuous integration (CI) and/or continuous deployment (CD). - You are what you measure and post publicly. A giant dashboard in the office to show key metrics like open tickets, who's working on what, app load, app latency, shopping carts/sales, current scaled-infrastructure costs, etc. - Minimum ad-hoc meetings and very few scheduled all-hands. - Let developers focus on one or two tasks rather than constantly interrupting them. Some sort of office GTD system combined with industrial andon light towers to signal: serious concentrating, light work, need to socialize, or not in. - Unless you're building an elevator, fission reactor or an intersellar space ship, be against waterfall development. I'm forgetting a million other things like mindset and differences in processes, but the above is a rough sketch. I do this all the time: It's too easy and too comfortable to get wrapped-up in technologies, methodologies or building out elaborate processes and bussiness-y minutia, which I think is a procrastination / ego defense-mechanism because of a core fear of many people of rejection from the user(s). It's so very easy to build something for yourself, but emotionally more difficult to build things others will see differently.
tirrellp 7y ago
The point of Scrum is not to deliver a full feature in a 2-week timebox. Its to deliver 'something of value' in a 2-week timebox. 'Something of value' could be stuff like: - A tracer bullet implementation of a new DB technology to de-risk full implementation - A skeleton workflow so you can validate with stakeholders that you're on the right track in terms of understanding how they work - A completely failed attempt at an implementation of a particular feature as to outline key lessons, go forward plan, and the next set of experiments you want to run to mitigate technology risk (will this work), customer risk (will they like it), or product risk (will it sell)
busterarm 7y ago
I work in a place that does this in 2 week sprints and that's probably the reason we're a public company with hundreds of millions in ARR. We're also totally a feature factory and I know for a fact that I would hate to be on one of the development teams and am absolutely glad I do ops instead here. The things we have the hardest time with are hiring and retaining senior talent and executing on difficult work that can't be accomplished over a period of a few sprints.
BigJono 7y ago
> I've worked at little startups and a medium-sized tech company as well as FAANG. In each case, we spent most of our time working on projects with 2-3 month time horizons. The small and medium companies called their development strategy "agile". In FAANG we mostly just did our work and didn't spend any time on the Kafkaesque exercise of "sprint retrospectives" and "grooming sessions". Our product manager didn't tell us what to build, but acted more as an advisor for the engineering team leads. Wtf? I've worked mainly for startups, with a couple of large companies in-between, and I've had the exact opposite experience. The engineering in every startup has been fairly lean and efficient with a few mistakes here or there, and every large business has been an 'agile' hell where everything feels ludicrously slow and nothing gets done. I've always avoided interviewing with FAANG etc because I just assumed they'd be in the latter category with the sheer number of employees they have. It's interesting to hear that Facebook actually runs smoothly.
- titanomachy 7y ago
  It likely depends somewhat on the team and specific company. However, the baseline level of individual competence and motivation is relatively high, which seems to reduce the need for process. EDIT: the medium-sized company I worked at (~200 engineers) probably falls into the category of "agile hell" you described. The startups weren't as bad.
- SeyelentEco 7y ago
  I agree with the parent poster. I've spent 6+ years at FB and the whole time I've just worked on what I thought was important. No one was ever assigned a project to me. The process normally involves managers and PMs highlighting problems and potential solutions and then developers picking projects that interest them. It sounds crazy but it is a controlled chaos. We incent people to work on non-sexy work by aligning with performance reviews. So everyone is required to show some better engineering impact (like writing documentation, unit or integration tests, cleaning up deprecated code etc). It's the longest I've stayed at a company (worked a decade at startups and web dev companies) because of the freedom to constantly work on things that are interesting. For example I've changed the type of developer I am twice since joining. So if it's worth a look if that's a style that works for you.
btilly 7y ago
I have worked at a variety of companies and on a variety of projects. What kind of cadence works varies widely. And the factors that go into it are everything from what kind of software it is to the codebase to the organization it is embedded in. There was one reporting app where I was the sole developer and it was only for internal use. My regular cadence was that I would field a series of questions every day. Better than 90% of the questions already had a documented way to solve it. But many days a new feature would be needed. Most features were delivered on the same day. That was a fun project, and my reporting system wound up adopted in every department of that company. I have worked on a legacy codebase with a Kanban style ticket system. Most features were delivered in less than a week. However a significant fraction of "features" were actually bugfixes. Such is life with legacy code. I have worked on systems where features realistically took a month or three, but we pretended to biweekly sprints. The sprint cycle seemed silly there.
tragic 7y ago
I currently work in one week sprints and we do this. Not 100% of the time of course, and it's an internal facing team where the customers are two desks away. But I've also done it on other teams with proper paying customers. The devil is in the definition. As an example, we have a tool that bootstraps a new Git repo and we're adding a feature that will include our company Rubocop config if it's a Ruby project. There is no reason on earth that this should take 3-5 developers a week to accomplish (never mind two). But it's a feature and it could be useful. And on top of all the other features, the tool is quite useful nowadays compared to the first extremely thin slice we did. The trick is reducing what you're counting as a feature to the smallest thing that is actually worth bothering to use. It won't always fit into one or two weeks, especially if you're dependent on hardware manufacture, or beholden to the iOS store approval timetable or whatever. But for your line of business SAAS apps there's absolutely no technical reason why you can't do it; there may be human obstacles to doing so. (Hell, maybe we're all wrong and you shouldn't do it.)

ebrewste 7y ago

When I was doing full stack, solo development, I could get features with real customer value delivered in <= 2 weeks. The flexibility afforded when doing solo development in an area you are competent can unleash some great velocity, but has pretty predictable downsides (can't scale past what you can do yourself, when the project gets big enough, the context switching is a killer, etc.). I don't think I personally have ever hit this level of personal development velocity when working in a group bigger than two people.

anonsivalley652 7y ago

Yep. Agile theater often happens when whoever wears (or doesn't) the PM "hat" doesn't have a clue beyond their so-called certifications and amateur "expert" non-experience because they're afraid of appearing incompetent. Then, it reverts to: Big Design Upfront -> Big Deliverables at the End -> sad, expensive fail. Agile means: - Build-test-feedback-adjust loop is as tight as possible... hours or less to get a fix or a quick feature. - The end-users are involve from the beginning to constantly get what they really need (capture good requirements, not necessarily what they ask for directly) and feedback to make usability/feature improvements. - Someone is prioritizing fixes and features from what users need right now to do something useful, rather than arbitrarily shotgunning features in milestones. - Just enough intra-sprint time is dedicated to test improvements, bug hunting and refactoring. - Using continuous integration (CI) and/or continuous deployment (CD). - You are what you measure and post publicly. A giant dashboard in the office to show key metrics like open tickets, who's working on what, app load, app latency, shopping carts/sales, current scaled-infrastructure costs, etc. - Minimum ad-hoc meetings and very few scheduled all-hands. - Let developers focus on one or two tasks rather than constantly interrupting them. Some sort of office GTD system combined with industrial andon light towers to signal: serious concentrating, light work, need to socialize, or not in. - Unless you're building an elevator, fission reactor or an intersellar space ship, be against waterfall development. I'm forgetting a million other things like mindset and differences in processes, but the above is a rough sketch. I do this all the time: It's too easy and too comfortable to get wrapped-up in technologies, methodologies or building out elaborate processes and bussiness-y minutia, which I think is a procrastination / ego defense-mechanism because of a core fear of many people of rejection from the user(s). It's so very easy to build something for yourself, but emotionally more difficult to build things others will see differently.

tirrellp 7y ago

The point of Scrum is not to deliver a full feature in a 2-week timebox. Its to deliver 'something of value' in a 2-week timebox. 'Something of value' could be stuff like: - A tracer bullet implementation of a new DB technology to de-risk full implementation - A skeleton workflow so you can validate with stakeholders that you're on the right track in terms of understanding how they work - A completely failed attempt at an implementation of a particular feature as to outline key lessons, go forward plan, and the next set of experiments you want to run to mitigate technology risk (will this work), customer risk (will they like it), or product risk (will it sell)

busterarm 7y ago

I work in a place that does this in 2 week sprints and that's probably the reason we're a public company with hundreds of millions in ARR. We're also totally a feature factory and I know for a fact that I would hate to be on one of the development teams and am absolutely glad I do ops instead here. The things we have the hardest time with are hiring and retaining senior talent and executing on difficult work that can't be accomplished over a period of a few sprints.

BigJono 7y ago

> I've worked at little startups and a medium-sized tech company as well as FAANG. In each case, we spent most of our time working on projects with 2-3 month time horizons. The small and medium companies called their development strategy "agile". In FAANG we mostly just did our work and didn't spend any time on the Kafkaesque exercise of "sprint retrospectives" and "grooming sessions". Our product manager didn't tell us what to build, but acted more as an advisor for the engineering team leads. Wtf? I've worked mainly for startups, with a couple of large companies in-between, and I've had the exact opposite experience. The engineering in every startup has been fairly lean and efficient with a few mistakes here or there, and every large business has been an 'agile' hell where everything feels ludicrously slow and nothing gets done. I've always avoided interviewing with FAANG etc because I just assumed they'd be in the latter category with the sheer number of employees they have. It's interesting to hear that Facebook actually runs smoothly.

titanomachy 7y ago
It likely depends somewhat on the team and specific company. However, the baseline level of individual competence and motivation is relatively high, which seems to reduce the need for process. EDIT: the medium-sized company I worked at (~200 engineers) probably falls into the category of "agile hell" you described. The startups weren't as bad.
SeyelentEco 7y ago
I agree with the parent poster. I've spent 6+ years at FB and the whole time I've just worked on what I thought was important. No one was ever assigned a project to me. The process normally involves managers and PMs highlighting problems and potential solutions and then developers picking projects that interest them. It sounds crazy but it is a controlled chaos. We incent people to work on non-sexy work by aligning with performance reviews. So everyone is required to show some better engineering impact (like writing documentation, unit or integration tests, cleaning up deprecated code etc). It's the longest I've stayed at a company (worked a decade at startups and web dev companies) because of the freedom to constantly work on things that are interesting. For example I've changed the type of developer I am twice since joining. So if it's worth a look if that's a style that works for you.

btilly 7y ago

I have worked at a variety of companies and on a variety of projects. What kind of cadence works varies widely. And the factors that go into it are everything from what kind of software it is to the codebase to the organization it is embedded in. There was one reporting app where I was the sole developer and it was only for internal use. My regular cadence was that I would field a series of questions every day. Better than 90% of the questions already had a documented way to solve it. But many days a new feature would be needed. Most features were delivered on the same day. That was a fun project, and my reporting system wound up adopted in every department of that company. I have worked on a legacy codebase with a Kanban style ticket system. Most features were delivered in less than a week. However a significant fraction of "features" were actually bugfixes. Such is life with legacy code. I have worked on systems where features realistically took a month or three, but we pretended to biweekly sprints. The sprint cycle seemed silly there.

tragic 7y ago

I currently work in one week sprints and we do this. Not 100% of the time of course, and it's an internal facing team where the customers are two desks away. But I've also done it on other teams with proper paying customers. The devil is in the definition. As an example, we have a tool that bootstraps a new Git repo and we're adding a feature that will include our company Rubocop config if it's a Ruby project. There is no reason on earth that this should take 3-5 developers a week to accomplish (never mind two). But it's a feature and it could be useful. And on top of all the other features, the tool is quite useful nowadays compared to the first extremely thin slice we did. The trick is reducing what you're counting as a feature to the smallest thing that is actually worth bothering to use. It won't always fit into one or two weeks, especially if you're dependent on hardware manufacture, or beholden to the iOS store approval timetable or whatever. But for your line of business SAAS apps there's absolutely no technical reason why you can't do it; there may be human obstacles to doing so. (Hell, maybe we're all wrong and you shouldn't do it.)