[maxxxxx]

With a lot of agile stuff I feel like you tend to end up with a result like a PT cruiser car. Some years ago I rented one and they had done everything right: Interesting design, cool features on the inside, analog clock on the dashboard and everything else. They had checked off all user stories of the car.

But the end result was a crappy car. A lot of features were implemented in a subpar way. Nothing really fit and the car just didn't "feel" right.

With strict agile structures I feel the same happening. You check off stuff and on the surface you are doing everything right in a methodical way. But there is no mechanism to check if the overall result feels right and has cohesion.

[valuearb]

It's akin to technical debt, maybe call it Agile Feature Debt.

You implement a feature, it's done, all obvious bugs are fixed. But now that you have finished it you've gained additional knowledge from actually using it. And you realize the way it was designed or implemented isn't optimal, in fact sometimes you realize the way it works is dead wrong, and makes the product less usable.

Too late. It matches the spec. It's been checked off. Time to move on to the next imperfectly designed feature and ignore what happens when it actually works.

In my case our product was designed with a UI that was overly complex, with far too many taps and views to navigate through to accomplish a specific task. And apparently the implementors were either incompetent or totally under the gun to make tight deadlines. Because it's performance is terrible, making the long trip through all those views slow and twice as onerous.

But it matched the spec, exactly.

[jacalata]

A significant part of the agile process is that meeting the spec isn't the goal, being accepted by the customer is. Your description sounds like there were no sprint reviews to get customer feedback, or it was ignored. So you're arguing that a significant problem with agile is that if you skip a fundamental piece, it results in bad outcomes?

[valuearb]

Oh, we passed all sprint reviews.

In our case the "product owner" is marketing. The lower level marketing personnel I have contact with just match the work to the spec, and can't or won't authorize any work that doesn't exactly match spec. Eventually things are bubbled up to their boss, and communicated somehow and they are handed back a list of priorities.

For example, I recently on my own time implemented a caching mechanism for the most often used views in our product, it increased their loading performance and usability by massive amounts. It was very encapsulated and easy to test, I asked to check the change in for our last sprint, and was told no, it's out of scope.

I'm not saying these are examples of problems with Agile. I'm saying these are examples of problems with Agile as it is sometimes implemented.

[maxxxxx]

A few problems with the customer feedback thing:

- the person assigned to you as voice of customer does not use the product - the person doesn't have time to engage with the dev team - the person doesn't care

Over the years I have seen exactly one product owner who could give useful feedback. All the others in the end had no idea what they were after.

[meheleventyone]

Hence the growth in people caring about things like UX design, user testing and releasing early to get feedback.

[forinti]

It worries me that I'll paint myself into a corner with Agile one day. Plus, the design documentation gets pulverized into lots of tiny user stories, so it's hard to get new people on board.

[sixdimensional]

I use a technique where I can visualize user stories as if they were part of a regular functional specification. It involves categorizing user stories into features/functions on paper first, and then entering them into our agile tracking tool, and then keeping the paper up to date when new user stories come up.

I use dot notation for functional specification grouping into features to uniquely identify user stories, which get tagged in the user stories in the tracking tool. Often they look like "Admin.UserManagement.CreateUser" or similar naming. I give meaning to each level of the hierarchy and document each, so they become like natural epic, feature and story levels.

It's extra work, but you basically end up with almost the same thing as if you had written a functional specification with use cases, just lighter weight.

If you have the features to do it in your agile tracking tool, you can use tags or categories and then produce a report of user stories that looks the same.

I remain convinced that agile and waterfall use almost the same basic tools but just in different ways.

I could go on how one can use formal project management Gantt charts to visualize sprints too.

[ryanong]

The most important part of agile is the feedback cycle and non rolling release products don't have a very good feedback cycle. it can still help if you figure out pre-release feedback loops but sometimes they are poor representatives of actual results.

[talldan]

Is agile considered a product development framework or just a software development methodology? I think that's quite a difficult question to answer. I'm sure anyone that has worked on product development finds it difficult to figure out how things like research, design and maybe even quality assurance should fit into the agile way of doing things.

Agile is so flexible that it doesn't really answer the question of how some of the non-software dev things fit in, ultimately it comes down to strong leadership, and the honesty to say when something is going wrong. At the very least, agile provides the opportunity to fix bad decisions.

[joncp]

Following your metaphor of the PT Cruiser: it seems like they followed a waterfall process. They came up with a list and then built a car that fulfilled that list without evaluating what they were building st every step along the way. If they'd done it agile-ly, the crappyness may have surfaced much earlier in the development of the car... Maybe early enough to have done something about it. Alas, agile doesn't really work well with design of expensive tangible products like cars.

[stult]

Agile doesn't work with cars because you can't deliver value incrementally by designing additional features. Producing a brake pad this week doesn't help if the chassis is still unfinished. Similarly having the entire car except the brake pads complete doesn't deliver any value. It's all or nothing.

[Huggernaut]

Not sure I totally agree that it can't be done. I have no idea whether it's at all realistic/sensible/pragmatic to create a car via agile but taking your brake pad example it would seem very alright to have a set of stories such as:

"As a driver, I can stop the car at a reasonable pace" - ok, maybe you get some awful brake pads to begin with (or maybe if you are cheeky you just say...well, air resistance does that!)

"As a driver, when the car is travelling fast, I can stop the car extremely quickly" - ok so now we probably need some reasonable brake pads.

"As a driver, I don't need to replace the stopping mechanism all the time" - ok so maybe now we need to make sure the brake pads fitted are of a certain quality.

I think you can see where this is going. Sure the car probably needs brake pads...but assuming you didn't know much about cars (something agile is suited for), at each stage you could decide you need to do something different for the stopping mechanism. Additionally, many of the qualities of the brake pads demonstrate that things are not "all or nothing" necessarily.

[maxxxxx]

I think I should have used the word "scrum" instead of "agile". Most scrum teams I have seen look like a micro-managed waterfall that are extremely reluctant to change anything because they need story points.

True agile works fine but it seems most agile frameworks lead to non agile work.

[lotsofpulp]

I don't think I've ever heard anyone compliment anything about the PT Cruiser before. From what I've read, they did everything wrong (assuming you want a car that drives well and lasts a long time, and doesn't look hideous).

[maxxxxx]

I think they had checklist like this: Retro design, quirky, different. I actually like the concept. But the implementation is just terrible.

[Infernal]

I think the number one item on the checklist was "how can we build a car that /just barely/ crosses the line into 'light truck' category so has much lower fuel mileage targets per CAFE standards". On that point they did very well.

[nebabyte]

> But the end result was a crappy car. A lot of features were implemented in a subpar way.