Programming

Someone would look at our process and say "that's not agile!" and they might be correct, technically speaking. I don't personally care what it's called as long as it works.

We agree to requirements up front with our customer; we might change stuff as we go along if our customer realizes that what they asked for won't work (this happens occasionally), which is fine, but otherwise we don't let them change stuff around on a whim, and we don't allow scope creep. If they want a new feature, that's version 2 (or 3, or 4).

We don't meet very frequently. We do check in to make sure we're on target, and deliver features incrementally when it makes sense to do so. We do sprints. We talk about when things are working and when they aren't, but only when we think it's a good time to do so.

At the end of the day, you need to tailor the process to your needs and what makes sense to you and your team.

I liked agile as it was practiced in the "Extreme Programming" days.

• Rather than attempt to design the perfect system from the get-go, you accept that software architecture is a living, moving target that needs to evolve as your understanding of the problem evolves.

• Rather than stare down a mountain of ill-defined work, you have neat little user stories that can be completed in a few days at most and you just move around some Kanban cards instead of feeding a soul-sucking bureaucratic ticketing, time tracking and monitoring system.

• Rather than sweat and enter crunch mode for deadlines, the project owners see how many user stories (or story points or perfect hours) the team completes per week and can use a velocity graph / burndown chart to estimate when all work will be completed.

.

But it's just a corporate buzzword now. "We're agile" often enough means "we have no plan, take no responsibility and expect the team to wing it somehow" or "we cargo cult a few agile ideas that feel good to management, like endless meetings with infinite course changes where everyone gives feel-good responses to the managers."

Having a goal, a specification, a release plan, a vision and someone who is responsible and approachable (the "project owner") are all part of the agile manifesto, not something it tries to do away with. I would be sad if agile faces the same fate as the waterfall model back in its time and even sadder if we return to the time-tracking-ticket-system-with-Gantt-chart hell as the default.

Maybe we need a new term or an "agility index" to separate the cases of "incompetent manager uses buzzword to cover up messy planning" from the cases of "project owner with a clearly defined goal creates a low-bureaucracy work environment for his team." :)

The project manager's revenge: the last Scrum Master.

Honestly a little confused by the hatred of agile. As anything that is heavily maligned or exalted in tech, it's a tool that may or may not work for your team and project. Personally I like agile, or at least the version of it that I've been exposed to. No days or weeks of design meetings, just "hey we want this feature" and it's in an item and ready to go. I also find effort points to be one of the more fair ways to gauge dev performance.

Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed.

I'm not really sure how this relates to agile. A good team listens to the concerns of its members regardless of what strategy they use.

A neverending stream of patches indicates that quality might not be what it once was, and code turning up in an unfinished or ill-considered state have all been attributed to Agile practices.

Again, not sure how shipping with bugs is an agile issue. My understanding of "fail fast" is "try out individual features to quickly see if they work instead of including them in a large update", not "release features as fast as possible even if they're poorly tested and full of bugs." Our team got itself into a "quality crisis" while using agile, but we got back out of it with the same system. It was way more about improving QA practices than the strategy itself.

The article kinda hand waves the fact that the study was not only commissioned by Engprax, but published by the author of the book "Impact Engineering," conveniently available on Engprax's site. Not to say this necessarily invalidates the study, or that agile hasn't had its fair share of cash grabs, but it makes me doubt the objectivity of the research. Granted, Ali seems like he's no hack when it comes to engineering.

Normal development: measure twice, cut once. Agile development: measure once, cut twice.

Shockedpikachu.jpg when things fall apart.

Ha, "fail faster" indeed

With 65 percent of projects adopting Agile practices failing to be delivered on time

They're not "failing to deliver", they're being Agile in disappointing everyone involved!

Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed.

Which shouldn't surprise anyone, but I know some managers, directors and users loathe the idea of the people who'll do the actual job having any say other than "yes, sir".

In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates.

Good documentation is critical and process-agnostic. If people can read and understand it, it's good. It's something that can be used as a shield and weapon against users/higher ups who want too much, it can create a trail of responsibility.

Agile is LinkedIn religious bollocks. Might as well just pray. Bunch of corporate nonsense.

BUt YoUrE NoT DoINg it RIghT!!1!

Should be reciting the creed in Latin, presumably.

Lol I'm going to send this to my project manager