I don't think I would like Agile

[Randall Twede]

for some reason i don't think i will like Agile/Scrum.
i should find out what it is.

[Randall Twede]

i read a little about Scrum. if that's what you have to do, OK.
i don't think i would like it though

[Jan de Boer]

Randall Twede wrote:Jan, welcome fellow apostate!
when i first found myself here at the ranch many moons ago, i posted "top down procedural programmers of the world unite!"
i have since changed my mind and love OO.

The difference between OO, procedural, functional, collection logic programming is just a way of thinking about solving a problem. I can do all of those styles easily. Frankly .. I am actually pretty smart with those things. Agile is a way of working, organizing, and I don't like it. I would not even weed the garden, or do the laundry in an agile fashion. Just imagine me and my daughter doing the laundry in a pair programming way. Should we put the purple with the blue or the red stuff, ah no let us put them all together and just decrease the temperature. After ten minutes I would say, girl go do your homework and let me just finish this without comments in silence. I can think better that way.

[Jeanne Boyarsky]

Jan,
So how do you teach your daughter to do the laundry? Isn't it slower the first time.

Also, pair laundering would give the opportunity to suggest that taking out the towels to air dry would save money . I do get that some tasks are better solitary, but had to tease about this!

[Jan de Boer]

Jeanne Boyarsky wrote:So how do you teach your daughter to do the laundry?

I would explain her, then do it together with her two or three times, then write down instructions so she won't forget.

I would not every week spend 'quality time' together, chatting about which cloth we will throw in which basket. Then write nothing down, and then after I come back from holidays find all my clothes colored since she did not remember everything, and nothing was written down because that is not agile. Or even worse, when I am on holiday, perhaps even in bed with a member of the opposite sex, get a phone call in the middle of night, her asking what temperature the blue things were run in.

That is agile, write nothing down, be interrupted constantly, and you can say everything because we are a team and we do retrospective, but if you complain about agile, you are a bad programmer.

[Jan de Boer]

Jeanne Boyarsky wrote:Also, pair laundering would give the opportunity to suggest that taking out the towels to air dry would save money.

Such a thing can be done easily when we are sitting at dinner together. If we talk about the weather, I will say that you can better put the clothes out to dry at the moment. We do not have to be connected like the Borg 24 by 7 to exchange ideas. Sometimes people need private time to think too. There is a balance between those two, and this balance is also personal for each employee. Agile has gone totally overboard with this, forcing all to join the collective, forcing everyone to be the same.

[Jan de Boer]

I will give you another example of successful domestic ‘waterfall’ organization. Every year I and or my dad guard my sister’s house. She lives in the country, no cable TV. Until recently, every year her husband quickly explained me and or my dad how the TV works. In a hurry, they had to go. It is complicated, turn on the satellite, turn on the sound system, then turn on the TV, all three have separate remotes, and there are three sets of TVs. Multiplied makes nine. Every year I forgot, every year we either called my sister in the evening, or we muck things up, or .. we just play cards since we do not dare to try.

This until finally two years ago I told my brother in law to slow down and let me take notes. Then I made the evil thing called documentation, you could even call it a manual. And to make it even worse…we printed it out on paper. Can you imagine? Paper? The thought alone. We now print out the manual every time we visit and our problem is solved. But, helas, we are so totally not agile. Preferring documents over human contact, we must be autistic!

[Jeanne Boyarsky]

Nice analogies.

I just want to point out the agile doesn't preclude documentation. My team has a culture of documenting *everything* on the internal wiki. The docs are easy to change and evolve as processes change.

I also have a "do not disturb" sign so my teammates can see if I am deep in focus, on the phone/available by IM or available for "interruption." Two of my teammates have similar signs.  Teams create culture. That's part of agile.

Now the agile manifesto does say:

Working software over comprehensive documentation

This makes sense. If the software is broken, it doesn't matter how good your docs are. And docs can be too detailed. For example, you probably don't need a doc on how to pee . "No documentation" is not something that agile states. It is a choice a team or company has made and then tried to "credit" to agile.

[Jan de Boer]

If I for example would use that "do not disturb" sign I would expect to hear from my manager that I am being incommunicative and that it's not Agile.

Actually everything I tried to say during retrospective like things 'bounced' back at me. So if I want some time in which I am not disturbed, see above. If I asked the Product Owner to more accurately define the story on the backlog and write it down, because after two weeks when I would begin the story I would not remember the details, that is also like doing waterfall, changes anyway, ask again, you have a bad memory. Goes for more 'documentation' things. Like not cool, not agile, if you don't like it... fill in the rest. So after a few months I stopped complaining. Now they ask me if I am happy. And it is probably because they see I am not happy. I say nothing because well if I say something, I only 'get it back', and I have given it up that they would change, help me, or what. Our manager thinks we are doing Agile and we all love Agile! And I am not the only one here thinking what I am thinking, I know that.

[Tim Holloway]

I was doing "Agile" many, many years before the term was invented. I was in mainframe technical services and part of my job was to provide specialized services to in-house users. A lot of these services were fairly small, and I learned not to design them to be "perfect", because once the user had it and saw what was possible, their requirements adapted to their new capabilities.

Agile according to its Manifesto is mostly about flexibility and delivering in digestible chunks, as opposed to the wait-forever and finally (we hope) receive something that turns out not to be what we really needed.

But, alas, like all good ideas, the PHBs and Dogberts too often mangle it by insisting that it can only be done with overpriced proprietary tools, that it be done according to rigid schedules, often under restrictive conditions (such as mandatory pair-programming).

Done well, Agile can lead to happier users, managers, and developers. Done bureaucratically, it can be yet another hammer in the corporate soul-crushing toolbox.

[Jeanne Boyarsky]

Jan de Boer wrote:Our manager thinks we are doing Agile

And that's the problem!

[Jan de Boer]

Seriously, I am not going to discuss Agile anymore.

And yes, also our manager says that all other managers are saying they are doing agile but he is the only one who is really using agile, so ...

And even the latter I would not have wanted to say.

[Jan de Boer]

Tim Holloway wrote:I was doing "Agile" many, many years before the term was invented..

Tim .... Everybody was doing "Agile" before the term was invented. The term "Waterfall", and especially the "Agile" view of what "Waterfall" was, is also invented by "Agile". And THAT is the whole problem.

[Junilu Lacar]

Tim Holloway wrote:Done well, Agile can lead to happier users, managers, and developers. Done bureaucratically, it can be yet another hammer in the corporate soul-crushing toolbox.

Perhaps one of the most unfortunate things that happened in this space was the shift in the word "Agile" from being an adjective to being a noun. This is one of the reasons that led Dave Thomas, one of the original signatories of the manifesto that arguably started the movement, to write the article Agile is Dead (Long live Agility!). In light of what Dave wrote, what Tim said could be rephrased as "When done with agility, software development can lead to happier users, managers, and developers. When you "do Agile," the process just becomes yet another hammer in the corporate soul-crushing toolbox."

[Jan de Boer]

Junilu Lacar wrote:Perhaps one of the most unfortunate things that happened in this space was the shift in the word "Agile" from being an adjective to being a noun.

Dear Junilu, forget it. It is the values again? Those values exist outside of that manifesto. Values are common, they do not need a religion, they exist outside of that religion. Those values would exist, and be appreciated maybe even more, without the agile movement around it. Agile will die. It will evaporate. Now every thing is called agile, so soon nothing is agile. Sure some techniques will stay, but those would have been used if nobody started this nonsense too. The agile religion is dying like ISIS. I am sure!

[Tim Moores]

Jan de Boer wrote:The term "Waterfall", and especially the "Agile" view of what "Waterfall" was, is also invented by "Agile".

Any new methodology will have its own particular view of what came before, but the waterfall approach (and the term itself) was used long before any methodologies that could be described as agile were in common use.

Agile will die. It will evaporate. Now every thing is called agile, so soon nothing is agile.

I agree that the agile approach has been overhyped, and by attaching the word to everything it means nothing. Followers of the Gartner hype cycle will have seen this before with lots of technologies, tools and methodologies. Don't bet on the approach going away any time soon. Many teams and companies find that it adds value, and so will continue to use it until something better comes along. Right now, I see nothing that seems poised to replace it.

[Andrew Stellman]

Jan de Boer wrote:

Tim Holloway wrote:I was doing "Agile" many, many years before the term was invented..

Tim .... Everybody was doing "Agile" before the term was invented. The term "Waterfall", and especially the "Agile" view of what "Waterfall" was, is also invented by "Agile". And THAT is the whole problem.

This actually made me laugh out loud. It's true, everyone was doing agile before the term was invented. Just to be clear, the term agile was adopted in 2001 (at the meeting in Snowbird, Utah), and many of us were doing Scrum and XP in the '90s.

One small nitpick. The term "waterfall" is widely credited to an engineer named Winston Royce, who introduced the concept in a 1970 paper called Managing the Development of Large Software Systems (pdf). Ironically, in that paper he described it like this: "I believe in this concept, but the implementation described above is risky and invites failure."

But reading this thread, I wanted to call out a couple of things:

Jan de Boer wrote:This until finally two years ago I told my brother in law to slow down and let me take notes. Then I made the evil thing called documentation, you could even call it a manual. And to make it even worse…we printed it out on paper. Can you imagine? Paper? The thought alone. We now print out the manual every time we visit and our problem is solved. But, helas, we are so totally not agile. Preferring documents over human contact, we must be autistic!

Anyone who tells you that agile teams never use documentation doesn't really understand agile very well. Like it says in the Agile Manifesto, we value working software over comprehensive documentation – but we still value comprehensive documentation. Not just documentation... comprehensive documentation.

Based on the things that you've said, like this:

Jan de Boer wrote:That is agile, write nothing down, be interrupted constantly, and you can say everything because we are a team and we do retrospective, but if you complain about agile, you are a bad programmer.

it makes me think that you're working on a team that has agile zealots as members. In my experience, an agile zealot is typically someone who found that doing agile in a very specific way solved some problems they've had in the past. Then they think, "Aha! I've found the magic formula that will solve every project problem!" and insist, loudly, that this is the One True Way of doing agile, and loudly shout down any deviation from their way of doing things.

They are very frustrating to work with.

And, worse, many of us have gone through a zealot phase ourselves. It's often part of growing and learning, I think. So I'm sympathetic, but it doesn't keep me from wanting to occasionally wring their necks when I meet them.

I hope you get a chance to work with an effective agile team in the future. I think you'd enjoy it, and find it to be a very different and much more positive experience than the team you're describing.

[Junilu Lacar]

Andrew Stellman wrote:...an agile zealot is typically someone who found that doing agile in a very specific way solved some problems they've had in the past. ...many of us have gone through a zealot phase ourselves. It's often part of growing and learning, I think.

That's a good observation. There's a tendency by some to conflate passion and sincerity with religion and zealotry though, not unlike how some people confuse certain forms of public expression these days with being unpatriotic. Context and motivation matters, and so does perspective.

When it comes to practices to help you work with more agility, there are no sacred cows. You should always question what you're doing if you find you're not getting the expected benefits out of it. Don't be quick to blame a lack of success to a lack of effort or execution. As with patterns and anti-patterns, a practice taken out of context can easily be more detrimental than beneficial.

Effective teams debug their own practices. For example, if the team sees they're not achieving a state of flow when they do Kanban, they may figure out that it's due mainly to external dependencies that are not in their power to control. If they find that writing certain types of unit tests are actually slowing them down, they might figure out that it's better to turn them into integration tests that they run as a second phase of the build.

On the other hand, if your team is just trudging along and blindly following the "marching orders" of one or two individuals in authority, then you probably do have a dysfunctional team.