3 ms·

> we basically had our own process that just kind of evolved, a mix between waterfall and agile I guess. Interestingly enough, I find that to be something more

by lojack 11y ago

> we basically had our own process that just kind of evolved, a mix between waterfall and agile I guess. Interestingly enough, I find that to be something more in line with agile than the way most teams treat agile process. The agile manifesto itself event says: > Individuals and interactions over Processes and tools Which in a way makes most agile processes a sort of oxymoron. At the end of the day we just need to understand that we're building software, and we need to do more of what helps us build software and less of what prevents us from building software. Agile (or what people call agile) can do both.

lawl 11y ago
This. Basically, our process before was that the PM would plan a release with the customer and a few senior devs, distribute the tickets needed for that release to team members, and then the team shifted them around between eachother trying to make it work, sometimes we couldn't fit some tickets in, sometimes we were able to fit a bit more in. These were fairly long cycles like up to 3 months or even longer in one rare case. Then we became Agile. When you have 20 devs on a project, your standups won't take 5 minutes. Estimating the tickets won't be done in an hour because too many dependencies. They tried to split teams up into two, but then team A had no idea what team B was doing and there was just way more overhead. Most people will look at you in a weird way when you tell them you had 20 devs in one team. But what can I say, it certainly worked better than the other things we tried. As I said, I'm sure it can work, but you need to do it right, and we certainly didn't.
dragonwriter 11y ago
> Which in a way makes most agile processes a sort of oxymoron. There's no "sort of" about it. Rigid, context-blind processes -- whether sold as "Agile" or not -- are exactly what Agile is a reaction against. No process is Agile, and a team is only Agile insofar as it evaluates what works for the particular team in the particular context and places that ahead of preconceptions about what process should be that derive from other sources.

by lojack 11y ago

lawl 11y ago

This. Basically, our process before was that the PM would plan a release with the customer and a few senior devs, distribute the tickets needed for that release to team members, and then the team shifted them around between eachother trying to make it work, sometimes we couldn't fit some tickets in, sometimes we were able to fit a bit more in. These were fairly long cycles like up to 3 months or even longer in one rare case. Then we became Agile. When you have 20 devs on a project, your standups won't take 5 minutes. Estimating the tickets won't be done in an hour because too many dependencies. They tried to split teams up into two, but then team A had no idea what team B was doing and there was just way more overhead. Most people will look at you in a weird way when you tell them you had 20 devs in one team. But what can I say, it certainly worked better than the other things we tried. As I said, I'm sure it can work, but you need to do it right, and we certainly didn't.

dragonwriter 11y ago

> Which in a way makes most agile processes a sort of oxymoron. There's no "sort of" about it. Rigid, context-blind processes -- whether sold as "Agile" or not -- are exactly what Agile is a reaction against. No process is Agile, and a team is only Agile insofar as it evaluates what works for the particular team in the particular context and places that ahead of preconceptions about what process should be that derive from other sources.