agile-greater-than-scrum

[toddlamothe]

Added one belief on agility vs scrum.

Discuss...

[andriytam]

I like these principles, one thing I'm struggling is to forget these while approaching projects. I was thinking that announcing when we get successful results based on these rules and principles might give us better use case examples.

[smara-codes]

I think the principles behind the Agile Manifesto are the gold mine in here and I would love to bring some of them in focus.

In more geeky words I feel like Agile is the abstract class while Scrum, Kanban or Scrumban are concrete classes than extend Agile. They are helpful if we want to pick something others have proved and follow a good recipe.

However Agile doesn't insist that we pick a known recipe and encourages us (through the very first sentence _ Individuals and interactions over processes and tools_ to adapt processes and tools to work for us and our collaboration rather than the other way around.

The one principle that resonates most with me today is:

Simplicity--the art of maximizing the amount of work not done--is essential.

[levijackson]

I like adding this!

I also like the idea to bring some of them into focus (maybe rephrase/add our own?). I do find alignment with the majority of the manifesto - but I also find that there can be an ebb and flow of how much weight is placed on certain things.

Value:

Working software over comprehensive documentation

I'm over here trying to raise our bus factor, and this is telling me to put documentation off :) - I get the spirit of it, but since tech debt/documentation has been one of our biggest stumbles (IMO) I'd like to speak directly to it somehow.

[smara-codes]

@toddlamothe I landed #5 so you might need to merge those changes into your branch before landing this.

[toddlamothe]

@smaraf Pulled down the latest changes and rebased with master. I'm way out of practice here and not sure I did it all right.

[lboright]

@levijackson

Value:

Working software over comprehensive documentation

I'm over here trying to raise our bus factor, and this is telling me to put documentation off :) - I get the spirit of it, but since tech debt/documentation has been one of our biggest stumbles (IMO) I'd like to speak directly to it somehow.

This is a really good point. I wonder if we could prioritize releasing working software to a user as soon as possible, but still hold ourselves to completing some sort of documentation/training within x days of release? Maybe holding ourselves to other standards, like self-documented code, etc could also help.

[toddlamothe]

I like adding this!

I also like the idea to bring some of them into focus (maybe rephrase/add our own?). I do find alignment with the majority of the manifesto - but I also find that there can be an ebb and flow of how much weight is placed on certain things.

Value:

Working software over comprehensive documentation

I'm over here trying to raise our bus factor, and this is telling me to put documentation off :) - I get the spirit of it, but since tech debt/documentation has been one of our biggest stumbles (IMO) I'd like to speak directly to it somehow.

Crap - I see what you mean here. I think when it was written, this principle was attempting to revolt against waterfall, where "documentation" referred to requirements (ie capturing 100% of software requirements before writing a line of code). I don't think they intended to devalue code comments and documentation. That'd be just sloppy.