Whenever I meet people hiring for tech in Toronto They say things like: 'We practice XP, We apply agile to agile!", I hear "We have no idea what we're doing, and no idea how we're going about it but we will change it whether it's working or not and expect you to jump through a lot of hoops in addition to getting your work done"

I've seen offices with Gold stars for employees and these huge whiteboards filled with different milestones and benchmarks for projects. It looks great, but the difference is the work isn't getting finished. I feel like agile can create a smoke screen (if you're not careful) where you're too busy seeing how successfully you're on track with agile and miss the opportunities or failures that are happening in the real world to your product, instead of inside your process. You can be in great shape as far as agile goes, and still be losing customers because your work comes months too late.

To me, process should never be more important than product. I come from a graphic design background where process is very important to ensuring consistent results, but you can never fetishize the design process over the results it produces or else you end up with mediocre, commoditized design that is indistinguishable from the worst stuff coming out.

You couldn't pay me enough to deal with agile in the workplace, I feel like you'd have to toss an extra 50k on the top nd I doubt anybody would pay me an extra 50k just to deal with it, so I'll continue working with non-agile folks who manage to get stuff done, like professionals! Opportunity doesn't wait for standups, timeboxing (telling people when they are allowed to talk or not), and micromanagement.

I feel like you're rejecting a strawman, rather than basing it on an honest "suspension of disbelief" experience at a well-regarded agile shop.

I joined Pivotal Labs a skeptic. Now I'm a proselyte.

The Manifesto if vague enough that you can pull anything out of it, is not really a set of concrete standards. Generally, I think it's not good to break processes when individuals feel it is appropriate, because you then have no common reliable basis for expectations. It's good to have processes that are followed consistently but which are owned by the team and which the team together is free to modify and define exceptions to -- and where everyone is free to call a halt to have the team consider the need to address a process issue in the context of a current work item. At least that's my view, is also seems a fairly common approach in the Lean literature, which seems to be based on the same values as Agile, by be stronger on on concrete, high-level framework methodology. The Agile literature seems to jump from the Manifesto to lots of low-level processes and practices without as much attention to high-level approaches which really make concrete how to effectively empower people in teams, and manage the choice and adaptation of low-level processes in a way which really reflects the Manifesto's values.

My take on this (which may not necessarily conflict with your view) is that process exists to serve individuals and interactions. For example, the standup meeting is a common practice used to facilitate interaction amongst team members, and to bring forward issues an individual may be experiencing. However, there are teams out there that communicate really well outside of standups. Individuals bring up roadblocks early on. For these teams, standups are redundant... but they are core to most agile processes. In this case it makes sense to ignore that part of the process -- it just gets in the way.

In my opinion, process should _always_ be bent and ignored when appropriate. This doesn't mean that you shouldn't be disciplined, or that you should ignore process. Additionally, I think that questioning the process should be encouraged. To which, the author also says:

> Team members reject Agile methodologies openly, as they do not want to be pushed out of their comfort zones.

To me, there's a fine line between rejecting something because it pushes you out of your comfort zone and rejecting something because it gets in the way of doing work. The fact that the author doesn't bring up the possibility that there are many valid reasons for rejecting methodology leads me to believe that he may himself be lumping anyone who disagrees with him into this category, which can be very dangerous. One shouldn't ignore the process just because you don't feel like it, but you also shouldn't blindly follow the process just because someone says that's the only way to stay disciplined.

I am not ruling out that the overhead of Agile maybe too expensive for some sort of tasks/jobs.

But in before-mentioned cases, accepting more responsibility wasn't considered appropriate by the individuals: Why would you want to do more work under the risk of being blamed?

Command & control structures have a great advantage: Blame goes up…

Let me explain this text with an example:

A team is working in Scrum mode – all systems GO, everything looks fine – when a deadline is approaching.

To meet this deadline at all costs, management decides to gather a task force including member from various other teams, thus overriding the Scrum process.