Hacker News Reader

Comment by bananas | Hacker News Reader

I found that no methodology works as well as getting the right people in and let them organise themselves. If you have the wrong people, it doesn't matter what methodology or process you bring in, you're screwed.

On that basis, methodology isn't that relevant.

I just watched a company apply SCRUM to apparently solve process problems and it just made things worse because the staff aren't disciplined or interested in what they do.

That's after five years of agile consultants and perpetual change.

If you want a manifesto with real values:

1. Fix shit when it goes wrong right away.

2. Tell people what you are doing.

3. Write everything down somewhere centrally that everyone can get to(tickets)

4. Have a rough vision and make sure people are working towards it. Don't plan the details too much.

5. Be opinionated. Someone's got to win an argument.

that's it.

View on HN

The point of that article is that you need to be self reflective and open to change.

I'll post it here again, without any of the other distracting things he said about verbs and so on. Just take a moment to think about what these steps actually mean:

    - Find out where you are
    - Take a small step towards your goal
    - Adjust your understanding based on what you learned
    - Repeat

If you want to work as effectively as you can, you should actively change your process constantly based on reflecting on past performance against your goals.

...if you don't care, or can't be bothered, well, that's fine too (self reflection isn't easy); just realize that your own set of pedantic dogmatic rules is no better than any other Agile process set.

Spot on. This has been sort of an obsession of mine lately using the game of hangman and decision theory to "prove" why this works and how it applies to software development.

There are so many dogmas out there (Fail fast, MVP, Agile, Lean, etc) which all boil down to the same thing: Maximizing information gain and minimizing the cost of failure.

I'm planning on a blog post/email course/talk/something in the next few weeks but it's not quite ready yet.

This has been sort of an obsession of mine lately using the game of hangman and decision theory to "prove" why this works and how it applies to software development.

Oh come on, you can't tease us like that! You have a duty to satisfy our curiosity now. :)

How can hangman with decision theory apply to software development?

Well, I've started on a landing page for an email course. It's pretty rough around the edges, but I suppose I could take this opportunity to solicit feedback. ;)

I would also be thrilled to get my first signup. :)

http://chrisconley.io/delivered/

This reminds me of the OODA loop: http://en.wikipedia.org/wiki/OODA_loop

I think this concept also describes the essence of "agile" well (along with the four points you quote).

Oh, the scientific method is great, isn't it?

It's new tech, just from the XIV century... It would be great if people were that up to date.

Assuming you know what your goal is.

If Scrum is applied well, all issues with the staff and the rest of the organisation will surface as blocking issues.

That's pretty much the #1 reason I find Scrum useful. It makes shit hurt. When introduced in a disfunctional organisation, it's basically a role-playing version of root cause analysis.

Of course, when implemented internally in a disfunctional organisation by people who are part of the problem, those issues will be swept under the rug and the problem will only get worse.

If an organisation doesn't want to change (including making the hard decision of firing the incompetent and undisciplined), not methodology will help.

And neither will your manifesto.

Yes, everything depends on having the right people and having them organise themselves (which is the very foundation of Scrum and most Agile methodologies). But in order to organise yourself it's helpful to use a clearly defined method instead of re-inventing the wheel.

Teams that fail with any Agile method are likely to fail at self-organising anyway.

No methodology solves the people problem, but some methods, particularly Scrum, are very good at identifying the exact nature of the people problem.

>> Of course, when implemented internally in a disfunctional organisation by people who are part of the problem, those issues will be swept under the rug and the problem will only get worse.

I think that's the point. Agile/Scrum is often just window dressing. If you have a good team then it will give you some nice things like frequent interim releases and a better idea of progress. But if you don't have staff who are interested, disciplined (and talented!) then you're screwed either way. And I've met a lot of staff who are not like this.

Frankly I'd rather that people had a mandatory five-year term in a disciplined team at one of the traditional, enterprise-class, quality focussed firms that demand good practice. I can work in whatever methodology you want, but that made me the software engineer I am today.

Which firms are those, in your opinion?

I spent a few years inside Big Blue. It moves very slowly but (IMHO) has world class people putting out well written, quality stuff.

It has its dark corners like anywhere else, I'm willing to concede it may just have been the teams I worked with that were awesome, it's certainly not cool, I wouldn't want to spend my whole career working for them and (frankly) god help you if you let one of their salesman in the building... But I learned a lot about doing things right. And now I'm a freelancer without the massive organisational overhead so I get to do things fast and right.

I dunno, maybe a large traditional corp isn't the only answer, but some way of enforcing good practice on people for a while, like a boot camp, so that they can take some of it with them to environments where it's not enforced as rigidly.

I think a lot of the federal contractors still have the legacy SDLC focus. Projects are huge with low margins and long timeframes. It's all about quality to keep the customer happy and not choosing the other guys.

"Development methodologies" are all about Process, as in the process to yield good results with ordinary people. For a team with good people that can self organize, processes stay in the way.

My general rule of thumb for considering somebody good (or great) is his/her ability to recognize / to be upset about problems / to care about usability or correctness of the implemented business logic ... and to roll up their sleeves and simply fix it, even without confirmation. If you have such people on the team, then the team can self-organize, if not, then prepare for sprints and meetings.

> If you have the wrong people, it doesn't matter what methodology or process you bring in, you're screwed.

Agile puts the focus on developers, but often the wrong people are management.

"getting the right people in and let them organize themselves"

That's a large part of what agility was/is about. The rest also matches up pretty well.

Actually I disagree. The large part (possibly not the intent) was about building a consulting empire around something utterly vague with multiple religious opinions about the best way to perform these manifesto actions.

A vehicle for rats.

In much nicer terms as he worked with them, that's the gist of what the article is about. Did you read it?

Yes. It doesn't deserve nicer terms. I've seen companies destroyed, careers destroyed and armies of consultants make off with people's livelihoods on a false promise.

For ref, I've migrated to the side of thing where I get pulled in (Harry Tuttle style) to sort companies out after they've been pillaged by these asshats.

But a good question is who and why brought those asshats?

senior management, of course

Exactly that. The department which is not immune to marketing and is immune to rational thinking.

So of course, you'll never see the Agile/Scrum implementations that are successful.

The original meaning of agile, the manifesto, was doing it right. The consultants jumped on the bandwagon and called themselves agile until it stuck. But I don't think the right response is to say agile is now bad, it's to reclaim the word from those who're misusing it.

Good luck.

I don't think a missused word was ever reclaimed, in any language. But while you are on that path, can you do something about "hacker" too? (Or maybe you should start with the easier, less valuable "ordinary" and "literaly".)

> The original meaning of agile, the manifesto, was doing it right.

My impression of the original Agile project (C2), from reading their wiki, was that it was an attempt to make their customer feel really bad that they were incapable of lasting a week without changing the requirements.

Also, didn't the project fail? Though, in a way where it actually got partially deployed.

The problem is that there are a lot of people who don't organize themselves, and need some sort of structure. So maybe they're not so suitable for agile development, and maybe you shouldn't hire them, but that really limits the labour pool, and in the end, someone is going to hire those people. We still need a way to make those people productive.

And they should be hired; they're often perfectly competent programmers, testers, etc, just not so good at working effectively with this kind of agility.

This reminds me of the team best advice someone ever gave me. "People. Process. Technology. In that order."

The most important factor for allowing this to happen is having as long of a runway as possible. Good vision is important too of course.

Amen.

I'll add one point:

6. Don't punish (for various forms of "punishment") the people who pro-actively do these things.

Well said.

Reply on news.ycombinator.com