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.
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. :)
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.
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.
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.
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.
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.
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.
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.
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.