In the history of my career, I've watched the evolution of agile as either a direct or indirect participant. My first experience with it was at a large telecom

In the history of my career, I've watched the evolution of agile as either a direct or indirect participant. My first experience with it was at a large telecom where I worked on a team that operated using agile development practices, but didn't realize it while simultaneously watching two separate development teams implement it[0], including purchasing/adjusting things to include any agile hyphenated idea[1]. Mine was a team of six, responsible for about 11 critical, internal, applications. We didn't consciously decide on an agile approach, nor did we ever use that term[2]. It was simply the only way we could operate and manage to get anything done. As we were serving internal teams with fully in-house developed applications we didn't have contract negotiations or someone on the other side of it concerned with anything other than "when can we have it"[3] We were a geographically distributed team and did stand-ups virtually via chat-rooms, but outside of that, the "Agile Values" were all practiced, accidentally, nearly perfectly. Shortly after that job, I joined software development shop that was undergoing a large transformation. They'd been a two-developer operation that was started in order to help land customers for the larger consulting business -- now when the product we were helping organizations deploy had some limitation, we had a team of folks who could write something to fill the gap. And because of the product, every customer had a gap. We quickly grew to seven and brought someone in to help manage the chaos with "agile". It worked about as well as I expect it can; this time we more closely followed a scrum process, daily stand-ups, sprints, retrospectives, etc. I moved on to another shop a couple of years later. They were a larger organization doing bleeding-edge development -- my role involved writing software for large products that a third-party wanted to create but didn't have the in-house talent to do so. At this job, however, agile worked a lot like I had been hearing from other developers -- it didn't. Here's the thing -- if you look at the three jobs, the one I would have expected to be the most successful here would have been at the last shop. They're mature, reasonably sized, not over-or-under managed and the kind of work we do has a high degree of "unknowns" to it, making a "complete project plan" impossible until very near the late stages. I would have expected the first to be a complete failure given the size of the organization (15,000 employees, three official "company languages", very globally distributed, very difficult to hire high-quality candidates[4]). All that to say, my current crop of co-workers and management are excellent -- the best I've worked with -- but it doesn't work at all here!. There are probably a million little "we don't do this exactly right or that exactly right", but the biggest -- and in hindsight, most obvious -- difference isn't us, it's the customers. At the first company, the only concern was "I need this as soon as possible, I can't pay for more people, and have very little for licenses or hardware." In recognition that they were often giving us so little to work with, and a history of delivering, they left us alone[5]. If we took too long, an explanation was enough -- it didn't cost the company more than the salaries they were paying us already. At the second company, we were developing software related to a third party (OCS/Lync/Skype for Business) which had all of about four organizations, globally, that specialized in that. We charged more than double what my hourly rate is billed at where I'm at, now, and our customers waited months for project starts. That we didn't give them a firm "here's what it's going to cost, out the door" and required them to work with us, the way we work, wasn't negotiable. We turned down work if they couldn't accept the terms. At the third company, though we are doing innovative work, there is enough competition that our customers generally focus heavily on the price tag. Since our market tends to be non-tech companies, the idea of not having some form of firm estimate in place is a non-starter. Estimates require plans, plans require more knowns than unknowns. The problem is that when you have a commitment that you're going to complete something for a certain price, that becomes the driving factor behind everything else. Change is allowed ... provided a change agreement is negotiated ... so adjusting to changing requirements means "we don't do it", "we eat the cost" or "we send them a new estimate, which is usually much larger than the customer is expecting". For the software we're building, there's always someone else out there that will do that for them. We don't have the money to eat the cost, and change orders can often be relationship-souring experiences. I've thought about this problem a lot as I'm making a transition to another company (one that is already operating in an accidentally-agile manner). There's room to implement some of the things I liked about agile, here, and I'm inclined to believe that the nature of the work/customers will lend itself well to this approach. It's making me believe that a lot of the talk about agile being "broken" or "poorly implemented" has a lot more to do with the details. Maybe software development ala "the third company" simply can't be done any better. If you can't find a customer who will accept -- up front -- ambiguity in "final cost", you can't really implement agile in that context. [0] Well, Agile/Scrum if memory serves. [1] Agile Workspaces, which went over like a lead balloon when the developers with large offices were told they were moving out to tiny, identical, unassigned desks. [2] As I'm writing this, I recall the term "RAD", "Rapid Application Development". I know it was a thing but nobody on the team could tell you what it was. It was used entirely because management liked how it sounded. [3] This is similar, but not exactly the same as, "How long is it going to take?" which is often hiding a financial question: "How many of the hours that I'm paying you to build it is it going to take you to build?" [4] Nobody wanted to work for us. We were both a "boring telecom" and a company that tended to want to hire developers at their big HQ, located in a region of the country with 1% unemployment for that job category (during its worst times). And, of course, they struggled during the 2000s dot-bomb, "Surprise Fired" half the IT/dev staff one day on a Friday (replaced with over-seas contractors) which gave them a terrible reputation among candidates. [5] My team was the only development team reporting up through the Infrastructure/Support organization. They tried to move us under development every time someone up the reporting chain (anywhere in IT) noticed the out-of-place department, nearly every year (this was the second most common org-related meeting, the other was "why do we write this in house at all?"). We loved these meetings; it was fun to get a large room of people to agree to something they thought was a "terrible idea" when they walked through the door.