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 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.
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.
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?
I would also be thrilled to get my first signup. :)
I think this concept also describes the essence of "agile" well (along with the four points you quote).
It's new tech, just from the XIV century... It would be great if people were that up to date.
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.
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.
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.
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.
Agile puts the focus on developers, but often the wrong people are management.
That's a large part of what agility was/is about. The rest also matches up pretty well.
A vehicle for rats.
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".)
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.
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.
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.
I'll add one point:
6. Don't punish (for various forms of "punishment") the people who pro-actively do these things.
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.