Hacker News Reader

Agile is barely different to how teams I worked on in the 90s operated, naturally, without trying to implement and enforce a new holy grail, chase the rainbow routine of machinic efficiency. I find it really is much ado about nothing, the emperors new clothes. An anal retentive formalising and trumpeting of common sense. I recall only one project which was waterfall, and the rest were used as soon as they were useful. I have an agile coach at my current job. As far as I can tell his job is to be the expert at drag and drop in Jira, and peeling post it notes. The only good thing I can say about agile is that it fills a space that will otherwise be filled with the next holy grail gimmick which management won't be able to resist as they sell themselves and their new magic power up the corporate ladder. I'm neck deep in this farce at the moment.

If your agile coach is dragging and dropping in Jira, they're doing it wrong. That's more likely the PO's job.

And agile coach, at least as I know them, guides several teams in their use of agile, without being part of the team. They have to be experts at recognizing whether a team functions well, which aspects need improving, and handing the team the tools to improve. It's a bit more distant from a team than a scrum master is.

> I recall only one project which was waterfall

That's because even my Software Engineering textbook first published in the early 80's warned about it, and presented iterative, agile-like, models and referenced the article by Royce that first described waterfall (without naming it) as an example of a broken model in the early 70's... Iterative processes have been widely taught since the late 70's at least.

Sure. A lot of "Agile" is actually cargo-cult agile, used as a vehicle for self-promotion: The daily scrum, the sticky-notes or the Jira.board, and all that other ceremony.

Typically retrofitted on top of a defunct process, with separate requirement analysts, "software architects" whatever that means, and a lot of control functions and processes inherited from the manufacturing industry.

What makes that work is probably the few people that actually understands software development - typically a low percentage of the massive overhead in a typical business software development center.

But you've got to start somewhere.

The Agile ceremonies are not bad, but relatively useless if there is no "real Agile" beneath. Unfortunately, they are easy to implement whereas "real" agile is not.

And what is "real" agile: The core agile ideas (the manifesto), the focus on flow-control, the incremental analysis-build-analysis cycle, continuous improvement, multi-disciplined teams, knowledge sharing, analysis methods that involves multiple people (like story mapping), empowerment (self governing teams, but also product owners).

Perhaps above all, the idea that software development processes should not be defined by business administrators, but instead by people that are actually qualified.

I guess it could be labeled as "common sense", but a few things are typically hard to reason about for a lot of people, for instance the flow-control part (such as kanban), as dynamic efficiency is harder to "see" than static efficiency.

But getting good at that is actually hard. Adding 1000 fields and workflows to Jira is easy.

Process is not going to fix a toxic work environment. But, it can make a positive difference over time.

Many teams start out productive, but they also tend to degrade over time. How many 10 year old projects have you been happy to start working on? How about 20?

Those are the places most in need of someone to cut the bullshit.

>cargo-cult agile

You just described my last job...

The reason development methodologies exist even in the face of common sense is the same reason management metrics have been around for ages: they aren't for the people doing the work, they're for the managers to quantify the work their team does for the sake of their managers.

Not every manager can understand every facet of the operation two levels down. Methodologies not only give them an understandable metric of what is going on, they also have something to point to when upper-upper management is considering a lower manager for a promotion or trying to figure out why things are taking too long or not working as expected.

Development methodologies have a place, that's for sure, but structure for structure's sake - in my experience - tends to exist primarily for the benefit of the managers, rather than the engineers.

Yeah, I'd stay far away from anyone who thinks you need 8 months to grasp the concepts of Agile. Sounds like @horse_recruiter is running the talent search.

That ridiculous expectation is probably a symptom of some pretty dysfunctional management in general.

But aren't most job requirements in our field typically written like that?

For example I remember receiving calls from recruiters looking for devs with 5+ years of .NET experience when .NET was less than 5 months old.

For a developer, no.

For someone involved in non-technical delivery, I would expect they had experience delivering agile projects.

(Of course, agile projects typically call them product owners instead, a subtle distinction.)

I've been involved with agile projects since 2006 and I am still learning new ways of delivering software that solves the right problem, developing team cohesion, surfacing risk early, and other things you don't learn in the 3 day class.

I can teach Scrum in 30 minutes, but there should be an actual expert around until enough of the group has internalized the reasons for the concepts and feel like they can adjust it to suit their situation without fear of dogma. (This expert, however, won't usually cost $200,000 unless they signed the manifesto themselves or are otherwise agile-famous.)

(Here's the 30 seconds if you don't have anyone around. Start with trying to group the next most important thing to do in a 2 week chunk. Every day, talk with each other and make sure to surface any problems and risks as fast as possible. Have at least one person who will use the software sitting with the team to answer questions as they pop up. And every week, take an hour to figure out what's working well, what isn't, and what you need to adjust to make things work more smoothly. There are dozens of technical and organizational practices to go through and try, but the best is to keep the ones that work for you, ditch the ones that don't.

Standups and Demos are just 2 of those organizational processes. Use them if they work, ditch them if they don't. For example, I'm currently working with expert practitioners and we're not doing a standup because we're small enough, work close enough together, and have worked with each other long enough to just talk.

>> Here's the 30 seconds if you don't have anyone around. Start with trying to group the next most important thing to do in a 2 week chunk. Every day, talk with each other and make sure to surface any problems and risks as fast as possible. Have at least one person who will use the software sitting with the team to answer questions as they pop up. And every week, take an hour to figure out what's working well, what isn't, and what you need to adjust to make things work more smoothly

Pretty darn good summary.

Product Owner is not the same as Project Manager. Product Owner is similar to Product or Program Manager in software, though the Product Owner role is usually a subset focused on software development and does not include go to market and P&L.

SCRUM Master role is the closest to a Project Manager.

The SCRUM Master isn't on all agile projects, but the SCRUM Master can be any combination of rotating team member responsible for following up on team tasks and facilitating SCRUM rituals to a full agile coach responsible for team coaching, organizational-wide systems/process analyst and change agent. Sometimes they get saddled with traditional project management deliverables as well.

The product owner, however, controls the backlog, and the yes/no in what defines the product is most often the most important (and difficult) position of the PM.

Right, Product Owners (like Product Managers) define the "what" of the product, effectively guiding the team on what market problems to solve and for which customers.

That's different from the Project Manager who works on resourcing and timing of a project.

Great comment. I'll just note that anyone can sign the manifesto, I guess you meant the authors. I'll sign it now if it means I can get 200k€ ;)

http://www.agilemanifesto.org/sign/signup.cgi

I meant original signatories, but I'll be impressed enough if anyone knows that anyone can sign it. :)

> And that's the reason why the executives don't find workforce. Being less-skilled means they don't value the engineering profession up to the required level to compromise and give good salaries.

Came to post this

> (Spanish dev here --working abroad obviously--.)

Same here ;)

Same here. Spanish dev working from the US. Sad to see many people like us here. Most of my fellow graduate students are in the same boat, really few stayed in Spain.

It is not competitive at all compared to the US of other european countries. That along with the "special" office politics and extreme inefficiency that plague Spanish companies, makes it extremely uninviting to come back to Spain.

200,000 euros is possible for what's essentially a contract digital transformation consultant, and there are agile qualifications on offer - and when you're dealing with the enterprise, they're often more valued than experience.

It is possible, but that's a very niche market. When you need people who can deal with multiple layers, including senior execs, and run tech teams, you are usually not looking for developers anyway. I don't find it very strange there is a shortage of those; I think you'll find that in most countries. It depends on the exact job description as this is all a bit vague though.

Agreed. I think it's entirely possible that they cannot easily find the skill set they need at 200000€/yr and it's simply that the tech writer did a poor job of communicating the job requirements.

You know, there is a bit of politics, but I've come to the conclusion that it's better to just hose down the managers with "techy-stuff" rather than try to sell them power points with bullshit. After all, if they are making the decision, they should actually either get it, or trust you to get it for them.

The one thing that does not fly is developers that does not know the business case, or worse, those that don't care and acts like the company's purpose is to give them new toys (frameworks) to play with. But grokking a business case is marginally harder than resolving a merge-conflict so most people are actually presentable in a steering committee meeting.

Anyway; 200.000 € is probably not a developer, but possibly someone with a development background.

Unfortunately only a few people can sell things to the (non-tech) management - that is typically harder for us square-headed developers, as you have to be able to skimp some details in order to convey the big idea. But selling ideas is a unique skill anyway.

I agree with the parts that say "bullshit".

What the hell even is an Agile qualification? Isn't it something you pick up on the fly? Some boss tells you that you're going to build an mvp prototype and you get to build more iterations after the first one is done, so don't break your heart over getting it right. And you say "ok bro I'm on it" and then you go code. What else is there?

> Spanish executives are less-skilled than their competitors in Germany, France or Italy

This is hilarious. Say that to Amancio Ortega :-)

Your comment is hilarious, in itself. Actually, you're hilarious.

Glad to be able to put some happiness in your world. Now seriously; do you think that one single unnamed study can be token as proof of what they are claiming? This is not much different to that 'The scientists say that...' mantra. How many executives were evaluated? 3?, 5?, 50?. We don't know.

That's why we Spaniards need to pitch in give our opinion about each point raised.

Because one person is a good sample size. Also, Italy has a lot of bigger and fancier clothing brands, so your example doesn't really prove much.