Agile Is Dead, McKinsey Just Killed It
In the history of my career, I&#x27;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 <i>operated</i> using agile development practices, but didn&#x27;t realize it while simultaneously watching two separate development teams implement it[0], including purchasing&#x2F;adjusting things to include any agile hyphenated idea[1].<p>Mine was a team of six, responsible for about 11 critical, internal, applications.  We didn&#x27;t consciously decide on an agile approach, nor did we ever use that term[2].  It was simply the <i>only way we could operate</i> and manage to get anything done.  As we were serving internal teams with fully in-house developed applications we didn&#x27;t have contract negotiations or someone on the other side of it concerned with anything other than &quot;when can we have it&quot;[3]<p>We were a geographically distributed team and did stand-ups virtually via chat-rooms, but outside of that, the &quot;Agile Values&quot; were all practiced, accidentally, nearly perfectly.<p>Shortly after that job, I joined software development shop that was undergoing a large transformation.  They&#x27;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, <i>every</i> customer had a gap.  We quickly grew to seven and brought someone in to help manage the chaos with &quot;agile&quot;.  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.<p>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&#x27;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&#x27;t.<p>Here&#x27;s the thing -- if you look at the three jobs, the one I would have expected to be the <i>most</i> successful here would have been at the last shop.  They&#x27;re mature, reasonably sized, not over-or-under managed and the kind of work we do has a high degree of &quot;unknowns&quot; to it, making a &quot;complete project plan&quot; 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 &quot;company languages&quot;, very globally distributed, very difficult to hire high-quality candidates[4]).<p>All that to say, my current crop of co-workers and management are <i>excellent</i> -- the best I&#x27;ve worked with -- but it <i>doesn&#x27;t work at all here!</i>.  There are probably a million little &quot;we don&#x27;t do this exactly right or that exactly right&quot;, but the biggest -- and in hindsight, most obvious -- difference isn&#x27;t us, it&#x27;s the customers.<p>At the first company, the <i>only</i> concern was &quot;I need this as soon as possible, I can&#x27;t pay for more people, and have very little for licenses or  hardware.&quot;  In recognition that they were often giving us so little to work with, and a history of delivering, they left us <i>alone</i>[5].  If we took too long, an explanation was enough -- it didn&#x27;t cost the company more than the salaries they were paying us already.<p>At the second company, we were developing software related to a third party (OCS&#x2F;Lync&#x2F;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&#x27;m at, now, and our customers waited <i>months</i> for project starts.  That we didn&#x27;t give them a firm &quot;here&#x27;s what it&#x27;s going to cost, out the door&quot; and required them to work with us, the way we work, wasn&#x27;t negotiable.  We turned down work if they couldn&#x27;t accept the terms.<p>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 <i>not</i> 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&#x27;re going to complete something for a certain price, <i>that becomes the driving factor behind everything else</i>.  Change is allowed ... provided a change agreement is negotiated ... so adjusting to changing requirements means &quot;we don&#x27;t do it&quot;, &quot;we eat the cost&quot; or &quot;we send them a new estimate, which is usually much larger than the customer is expecting&quot;.  For the software we&#x27;re building, there&#x27;s <i>always</i> someone else out there that will do that for them.  We don&#x27;t have the money to eat the cost, and change orders can often be relationship-souring experiences.<p>I&#x27;ve thought about this problem a lot as I&#x27;m making a transition to another company (one that is already operating in an accidentally-agile manner).  There&#x27;s room to implement some of the things I liked about agile, here, and I&#x27;m inclined to believe that the nature of the work&#x2F;customers will lend itself well to this approach.  It&#x27;s making me believe that a lot of the talk about agile being &quot;broken&quot; or &quot;poorly implemented&quot; has a lot more to do with the details.  Maybe software development ala &quot;the third company&quot; simply can&#x27;t be done any better.  If you can&#x27;t find a customer who will accept -- up front -- ambiguity in &quot;final cost&quot;, you can&#x27;t really implement agile in that context.<p>[0] Well, Agile&#x2F;Scrum if memory serves.<p>[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.<p>[2] As I&#x27;m writing this, I recall the term &quot;RAD&quot;, &quot;Rapid Application Development&quot;.  I know it <i>was a thing</i> but nobody on the team could tell you what it was.  It was used entirely because management liked how it sounded.<p>[3] This is similar, but not exactly the same as, &quot;How long is it going to take?&quot; which is often hiding a financial question: &quot;How many of the hours that I&#x27;m paying you to build it is it going to take you to build?&quot;<p>[4] Nobody wanted to work for us.  We were both a &quot;boring telecom&quot; 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 <i>worst</i> times).  And, of course, they struggled during the 2000s dot-bomb, &quot;Surprise Fired&quot; half the IT&#x2F;dev staff one day on a Friday (replaced with over-seas contractors) which gave them a terrible reputation among candidates.<p>[5] My team was the only development team reporting up through the Infrastructure&#x2F;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 &quot;why do we write this in house at all?&quot;).  We <i>loved</i> these meetings; it was fun to get a large room of people to agree to something they thought was a &quot;terrible idea&quot; when they walked through the door.