I hate "Agile" as it has been applied in my jobs

[Jeff Horan]

It seems that either the scrum master was my manager or else the manager had visibility into performance tracking stats that I thought were not supposed to be available to management. So, as a developer, management or more experienced developers, not negotiating with story-point poker, would assign the points and or time expectations and then complain when it wasn't done on time and ask what am I going to do about meeting my obligation. They weren't so interested in team building as much as they were in spinning the revolving hiring door until they got the team they wanted.

[Junilu Lacar]

You are not unjustified in feeling the way you do. Many companies say they practice "Agile" when in fact they are doing everything but.

[Jeanne Boyarsky]

Jeff Horan wrote:It seems that either the scrum master was my manager

Yuck. That's so easy to not go well.

Jeff Horan wrote:or else the manager had visibility into performance tracking stats

Do you have an example of such a stat?

I agree that's not agile. If it was, you could put in the retrospective that the team should estimate and to use cards. And that would launch a discussion and make change. Still might be worth trying in case they don't know there is a better way. My favorite thing with the story point cards is the discussion that comes with them. Sally puts 8 story points, Bob puts 2 and Fred puts 5. This gets a good discussion going where we learn that Sally realized a complication that nobody else did while Bob didn't understand the scope. All good things to know before coding starts!

[Tim Holloway]

The Agile Manifesto is pretty clear that Agile is not supposed to be a straitjacket or require special tools (overpriced products and Dogbert consultants).

However, there's virtually no good idea that a bad business cannot ruin. And generally turn into a blunt instrument to punish people with.

I was doing agile back in the early 1980s. But since the term hadn't been invented then (much less scrum, pair programming or other such nonsense), I and my users were quite happy with the way I did it.

[Junilu Lacar]

I don't know if I'd lump in pair programming with "other such nonsense" but yeah, I think it was Uncle Bob who said that "Agile is how professional developers work in the wild."  There were many good agile developers long before there was Agile as however it's known today.

[Andrew Stellman]

First of all, Jeff, I'm sorry that you had to put up with that sh*t. Agile practices are just tools, and like any tools they can be abused. Your managers are trying to control the uncontrollable. They fear that they won't deliver what's expected and they distrust the team, so they try to lock them into commitments by assigning durations and closely monitoring everyone on the team. It's a terrible atmosphere – and a highly counterproductive one, because that kind of pressure causes people to take shortcuts and cut corners. The code is probably full of all sorts of hacks because

And it's terrible for the team. A lot of times, people on teams feel like this:



That image is from our chapter in Head First Agile on Lean and Kanban.

A lot of people forget (or never really understood in the first place) that agile is more than just a toolset; it's a mindset too. Scrum, for example, works really well in an environment where the team is trusted, where people feel comfortable being open about their work, where they're allowed to focus on their work and not asked to multitask unreasonably, where they're allowed to openly question things, and where they're generally treated with respect. In an organization where those things aren't valued, Scrum doesn't work so well. It still works, in that the project gets managed, but it feels... well, exactly like you described.

So what do you do? Try to talk about these things with your management. Or... well, honestly, you don't necessarily want to do that, because in a lot of companies it's a good way to be fired. We talk about "CYA culture" in Learning Agile, where there's a culture of blame, where sh*t rolls downhill, and where you need to constantly protect yourself from blame. Agile doesn't work well in an environment like that; a strict waterfall process is a much better choice. ("The project is late, but it's not my fault! I followed the plan and the requirements specification. Someone else screwed up"!)

[Jan de Boer]

Andrew Stellman wrote:it's a mindset too.

Doing your job right is a mindset. You do not have to put a label on it. If you generalize agile to values and mindset, then what is it? This good mindset, and good values exist without agile. They would have existed if no-one ever invented the word agile in the software context. It is like saying socialism is not a certain way to organize your economy, but a mindset of sharing, and the values of caring for each other. Sharing and caring exists without socialism. Replace socialism with agile.

[Andrew Stellman]

Jan de Boer wrote:Doing your job right is a mindset. You do not have to put a label on it. If you generalize agile to values and mindset, then what is it? This good mindset, and good values exist without agile. They would have existed if no-one ever invented the word agile in the software context. It is like saying socialism is not a certain way to organize your economy, but a mindset of sharing, and the values of caring for each other. Sharing and caring exists without socialism. Replace socialism with agile.

Yes, a lot of people say something like this when they first run into the idea of agile as a mindset and not just a set of practices. Agile values are actually the opposite of generalization – the values of agile and agile methods and frameworks like Scrum, XP, and Kanban are very specific.

A response like the one you gave is especially common when people first see the Scrum values of openness, courage, focus, commitment, and respect. "These things sound so general, vague, and positive. Can't they be applied to any team?" But it turns out that attitude actually holds back an agile team, and becomes a self-fulfilling prophecy. I'll explain why.

Most teams actually struggle with the values—so much so that it's the true root cause of their problems with agile, even if they only see symptoms. When Scrum teams complain that they feel like they're "just going through the motions" (Google for "cargo cult agile"), that's an important symptom of a culture that runs counter to the values that make Scrum effective. We call this "better-than-not-doing-it results" in Learning Agile – it was going agile because the team is better than before, but they're only doing marginally better. Where are the "astonishing results" or "hyperproductivity" we were promised? It turns out that when the team's culture doesn't match the mindset needed for the method or practices, they get much worse results, and productivity is much lower—and it's palpable and obvious as to everyone on the team that there's a problem, even if they don't know what's causing it.

Jenny and I also came up with a little exercise in Learning Agile called "Are you OK with?" to help teams understand whether or not their team has a culture that matches the mindset. For example, when a lot of times, when people first encounter the Scrum values (openness, courage, focus, commitment, respect), a lot of people people think, "Who could be opposed to 'respect' as a value? What does that even mean? Isn't that just a really vague concept?" But it turns out that it's actually something very important that's missing on a lot of teams. So we ask people to honestly answer these questions:

In 'Learning Agile' (p164), Jenny and I wrote wrote:To understand if you’re ready for respect, ask if you, your team, and your boss are OK with:
• Trusting the team to do the right thing, and deliver each feature at the best possible date based on relative value and how the project progresses—even if it causes the project to take longer than you expect?
• Giving the team enough time to do the work, and not demanding overtime of them?
• Trusting the team to choose the tasks that are right for them and for the project, rather than relying on strict roles, RACI matrices, etc.?
• Not being able to ever say again that you don’t know why the team decided to do something the way they did?

Have you been on teams that can honestly say "yes" to all of these questions? I have, and they're much more effective than ones that can't.

Most teams, if they're being honest, will answer "no" to most or all of those questions. That indicates a mindset problem – a clash between the team's culture and the Scrum values – that will lead to friction, delays, and project failures.

I hope this helps to explain the value of putting a label on mindset, and why it's more specific than just saying a mindset is "good" or "bad."

[Junilu Lacar]

Robert Martin likes to say that "Agile is how professional developers work in the wild" implying that if there was no such thing as Agile as we refer to it, most good developers would work that way anyway. That's pretty much what Jan is getting at, I think.

When I read Fowler's Refactoring book, I recognized many things from my own practice. I was already extracting, renaming, and doing all kinds of things similar to what Fowler wrote about.  What I found awe-inspiring in what Fowler wrote, however, was the way he showed how all those disparate things I did to improve my code could be organized and systematically applied. His approach to applying the same techniques were much more coherent, purposeful, and disciplined.  

That's kind of the same thing that each flavor of Agile brings to the table: an organized, systematic, and disciplined way to apply many of the things good developers already do in some form or fashion in the wild. The synergy created by combining mindset, culture, practice, and organizational structure can lead to results that far exceed what you can get without it.

[Liutauras Vilda]

Jan de Boer wrote:Doing your job right is a mindset. You do not have to put a label on it.

I gave you a cow earlier today for very first and might second sentence, really liked them.

Once came back home took a book from my bookshelf about the agile and read it for the past 3 hours or so now.
Jan, based on what you are talking, it doesn't seem much you are against Agile. But I'll tell you how I look at all it from the abstract view after reading it 3 hours or so.

If somebody would have asked me to describe what is an Agile in a short sentence, I'd start something along the next lines:
"A framework, which helps easier to find and assemble the team of members with the same world outlook, which agree to sign a professionalism contract by the simple handshake only."

That may read obvious, but that means such team members don't need over and over to discuss what is good practices set according to theirs standards and what is not. They agreed on those beforehand they formed the team without even discussing about them. In short - straight to business.

Further set of principles I'd relate also with somewhat known or experienced already, for instance design patterns. They have set of principles, defined situations when they occur, at which situations they are best re-used. You could discuss them at the code level only if you wanted to, but everything is way simpler - they have names and known ideas behind, meaning they make technical vocabulary much simpler, which itself makes communication easier and more understandable across the team. You could also argue, why to put the labels on those design paterns, let's talk at pure technical level what is going on - but doesn't that adds unecessary complexity layer?

I don't find nothing frustrating in it. Even though at our company's team we don't put those labels (clarification: we don't do agile either) as Jan says, but I'd see it as a kind of reserve for improvements.

[Tim Moores]

Jan de Boer wrote:
Doing your job right is a mindset. You do not have to put a label on it.

It does make it easier to talk about, though. Saying that a team's approach is agile implies certain things, and rules out some others. It's much briefer than mentioning all those things. In that sense it's shared professional vocabulary.