Extreme storytelling -- not "one size fits all"

[Darren Dirt]

After the years I've spent working essentially ALONE in almost everything I develop, I wonder how different my skillset -- and personality -- would be if I had taken a different path, got my roots sunk into a company that did all the Agile stuff that you guys so casually talk about all the time and make me feel excluded and weak and obsolete ... 

AHEM.

Anyway. Found this interesting article that points out that some people take certain elements of Agile development a bit too far, a bit too black-or-white, a bit too ... extreme.

So maybe I am fortunate to have been so sheltered and thus not pressured to conform, be Borg-icized, etc. (Or maybe I'm just justifying my occupational laziness... puhtayto pyhtahto...)

There are beautiful, simple ideas in today's Agile development methods that work really well. And some that don't. Like defining all of your requirements as User Stories.

http://c2.com/cgi/wiki?UserStory

I don't like the format that most teams use to write stories. And I don't like how they use them.

...

Short summary stories to be detailed later or detailed requirements worked out early -- different problems and different situations need different approaches.

Stories started off as simple, free-form descriptions of work that the development team needed to do, like "Warehouse Inventory Report". But now, the Role-Feature-Reason template also known as the Connextra template/format (because somebody working there came up with it back in 2001) is the way that we are told we should all write user requirements.

as a {type of user}, I want to {do something}, so that {reason}

How did this happen? And why?

...the amount of verbal gymnastics I've seen people go through to try to make a simple and obvious requirement into a "User Story" proves that despite what Agile says, it's not always the best way to go.

...robotically following a standardized story template leads to stories that "are grammatically correct but completely false"... "They are nothing more than functional task breakdowns, wrapped into a different form to pass the scrutiny of someone who spent two days on some silly certification course, and to provide the organisation some fake comfort that they are now, in fact, agile."

Even some of the people who developed the original idea of User Stories agree that not everything can or should be done as a story. http://c2.com/cgi/wiki?LimitsOfUserStories

...the Story Template is a tool that should be used for beginners in order to learn how to ask questions. Like the "snow plow" technique for beginning skiers -- something to be thrown aside once you know what you're doing. ..."use whatever you need to capture requirements: pictures, slides, notes, acceptance tests ... stories are not enough. They are just one tool, a usage view. There are so many more options".

Don't get caught up in "Story Mania". Let's all stop telling stories and get some work done.

[Mr. Analog]

DISCLAIMER: I've worked my entire career in teams both functional and otherwise, I have a lot of experience with both waterfall and agile, I have seen both work and both fail.

There are two sides to this coin, developers who don't like change/working in teams and people who don't know how to run agile. And the above sounds like where these two streets meet

For work that is not user driven (the user being EITHER an external OR internal customer) there are stories that are classified as technical debt, and much like a bug they do not garner story points.

Having a product owner not being able to sort out the difference between a bug, a technical debt work item or an actual user story is the root of many problems and means that the product owner needs to learn more about agile or the scrum master needs to help the product owner classify things as they come in.

All agile is supposed to do is describe work you are already doing so progress can be tracked, and not just so some manager can look at your KPIs and see at a glance what a project team is up to (though this is obviously useful) but also so each team member can get better at breaking down and estimating work. As the complexity of IT increases as well as a shift to more team driven environments the ability to provide good estimates and break down huge impenetrable tasks into small manageable ones is an extremely valuable skill to have and brings you closer to feeling like you achieve things on a bi-weekly basis (or if you didn't achieve what you set out to do an understanding of what went wrong or what things are impediments to your work.)

Some people really do get stuck in the Ritual aspects of scrum without truly understanding what it is or how it works or where it fails and where you need to be flexible, but then there are others who actually enjoy living dangerously with waterfall and don't understand that they have an impact on people outside their own personal space or outside their own development lifecycle.

The elephant in the room is this; it doesn't matter what development methodology a team is using if team members can't work together then there is dysfunction that absolutely needs sorting out. If a team can't work it out then unfortunately there is a culture clash and the minority will have to go (both for their sanity and the rest of the team).

I work with a guy who wants to do things his way even though it has a detrimental effect on himself and the rest of the team, it's actually a lot less hassle for us all to let him move on to a company that he can be happy to work in than stick around and make everyone miserable with a constant sour attitude. GO! BE FREE!!

[Darren Dirt]

DISCLAIMER: I've worked my entire career in teams both functional and otherwise, I have a lot of experience with both waterfall and agile, I have seen both work and both fail.

grunch: ^ this ^ is exactly what I was hoping my OP would bring out of at least one of you... And now, back to actually reading it...

All agile is supposed to do is describe work you are already doing so progress can be tracked, and not just so some manager can look at your KPIs and see at a glance what a project team is up to (though this is obviously useful) but also so each team member can get better at breaking down and estimating work. As the complexity of IT increases as well as a shift to more team driven environments the ability to provide good estimates and break down huge impenetrable tasks into small manageable ones is an extremely valuable skill to have

#jelly

...I wonder how different my skillset -- and personality -- would be if I had taken a different path, got my roots sunk into a company that did all the Agile stuff that you guys so casually talk about all the time and make me feel excluded and weak and obsolete ... 

Seriously though, thanks for your honesty and boldness and clarity, my friend -- even though it makes me feel all the more trapped "here" than ever before (my own fault though, not that I'm miserable here, just sometimes wonder what I am missing out on)...

[Mr. Analog]

Well if it's comfortable why rock the boat, like the old saying goes the grass is always greener on the other fellas lawn