If there's a truism, it's that Agile is and always will be a reactionary process to older Waterfall style methodologies adopted from other engineering principles. That means it suffers from some of the kinds of problems reactionary "we'll do the opposite of that old broken stuff" ideas have.
For example, I'm afraid that in many environments, Agile ends up meaning "directionless or micro-directioned iterative development"
e.g. just start building stuff, nobody has any real idea what the ends state is supposed to look like or work, but we'll iterate into something at some point. Probably when we get close to running out of money.
Old fashioned honest engineering is tossed out while the framework/technology of the month gets absorbed into this or that sprint cycle and when problems preventing what feels like forward motion are discovered, crap just gets thrown against the wall until something moves forward a step.
Things ship late, nobody can schedule anything, budgeting and hiring plans are a mess.
One of the defining aspects of being human is that we're capable of thinking a few steps ahead and formulating a plan. The way Agile works in most shops returns us to being mere beasts of coding.
Of the places I've seen, the difference between success and endless-iteration-failure-followed-by-multiple-rewrites-from-scratch-before-delivery-because-look-at-all-the-lessons-we-learned-along-the-way is that somebody sat down before any work started and defined the goal, timing, budget and expectations.
There's some planning, some mockups, some interaction prototypes, etc. at the start that's hard work to do, but defines the goals and vision the work effort should be going towards...the "shape" of the work.
Goal driven development is something that seems to be missing in too many shops. It's hard though, because you don't want to end up in the waterfall trap again, but you don't want to end up in an directionless iteration morass either.
It takes experience and lots of road miles to understand that balance and succeed.
>>For example, I'm afraid that in many environments, Agile ends up meaning "directionless or micro-directioned iterative development"
Directionless. Absolutely.
Before he retired, my uncle was the VP of Technology for a very well-known financial firm. He managed a large department of developers and IT folks across multiple countries.
We were talking about Agile vs. Waterfall once, and he said something that stuck with me: Agile works if and only if your developers have significant amounts of industry expertise. Because only then can they look at a set of vague requirements, make sense of them and translate them into solid product features using their experience and knowledge in that specific problem domain.
Whereas if you look at the software industry today, most developers specialize along languages and frameworks, rather than industry lines and problem domains. Resumes almost never say, "X years of experience in [industry]" because most companies say they want to hire developers with "X years of [insert language/framework here] experience."
So then they end up hiring developers who are really, really good at Rails/Angular/Java/C# or whatever, but have never solved problems in the company's industry because their last job was something totally unrelated. They know how to use the tools and they may be able to iterate quickly, but if they implemented the feature correctly in the first place they wouldn't need to iterate in the first place and the product would ship on time and be on budget.
This is so true. I am mediocre developer at best, but because of my domain knowledge I can solve problems that developers 100 times better than me can't. Sure my code might be rough around the edges and some of my designs lacking in elegance, but they work. Working code is a million times better than elegant code that doesn't.
Edit. I have often thought that a good way to pair program would be to pair up a strong domain knowledge / weak dev with a weak domain / strong dev. I have had the opportunity to do this on occasion and the pace at which you churn out great working code is phenomenal.
that's exactly why product managers exist. i run precisely such a team, because there are no devs out there that know enough about our vertical - and the time learning and keeping up to date would be prohibitive.
PMs can help only with one part (the "problem"), but, unless they are also good architects and designers, the end result and the process end up being pretty painful.
The devs still need to learn about the domain and they need to understand it enough to build a good solution. Having to learn a new domain on your own can be tough. Having external SMEs (subject matter experts) reducing the ramp up time and answering detailed questions is a big help.
It's pretty common for PMs not to be SMEs though...
Agile is planned, just on a shorter time scale and gets more vague over time. Sprints have end goals, and so do epics.
Waterfall had big upfront design, which meant every time a manager asked for a change it screwed up the design and had to modified which took a lot of time. So people didn't ask for changes and the resulting software didn't do what they really wanted.
Iterative development tries to embrace change, it's an attempt at controlled change.
For example, I'm afraid that in many environments, Agile ends up meaning "directionless or micro-directioned iterative development"
e.g. just start building stuff, nobody has any real idea what the ends state is supposed to look like or work, but we'll iterate into something at some point. Probably when we get close to running out of money.
Old fashioned honest engineering is tossed out while the framework/technology of the month gets absorbed into this or that sprint cycle and when problems preventing what feels like forward motion are discovered, crap just gets thrown against the wall until something moves forward a step.
Things ship late, nobody can schedule anything, budgeting and hiring plans are a mess.
One of the defining aspects of being human is that we're capable of thinking a few steps ahead and formulating a plan. The way Agile works in most shops returns us to being mere beasts of coding.
Of the places I've seen, the difference between success and endless-iteration-failure-followed-by-multiple-rewrites-from-scratch-before-delivery-because-look-at-all-the-lessons-we-learned-along-the-way is that somebody sat down before any work started and defined the goal, timing, budget and expectations.
There's some planning, some mockups, some interaction prototypes, etc. at the start that's hard work to do, but defines the goals and vision the work effort should be going towards...the "shape" of the work.
Goal driven development is something that seems to be missing in too many shops. It's hard though, because you don't want to end up in the waterfall trap again, but you don't want to end up in an directionless iteration morass either.
It takes experience and lots of road miles to understand that balance and succeed.