When we attempt to understand and chronicle any product or service that delivers value, a good place to start is by asking the question “what problem is it trying to solve?”. For example the vacuum solved the problem of collecting dirt from the floor with maximum speed and efficiency. The internet solved the problem of communicating and sharing information at high speed and across the globe. A wrist watch solved the problem of telling the time at anytime by simply raising your wrist to your face. The list goes on! So our question here is to ask “What problem is agile trying to solve?” Let’s try to find out and bear with me, there is a bit of a history lesson included 🙂

Software Engineering is a relatively new discipline and ironically given the low numbers of female representation in Software Engineering,(good article here), was originally a female dominated profession. With the advent of the Computer Hardware industry in the 1950’s, producers like IBM began to recognize the need for additional software expertise to support mainframe functionality.  The fledgling computer industry had already looked to traditional engineering for formal delivery methods that focused on Gather the Requirements, Design the Solution, Build the Solution, Test the Solution, Deliver to Customer and of course, document everything you do in detail. Along with strong management and tight planning, this delivery method proved to be highly successful, as long as you were constructing a bridge or building mainframe hardware. This heavy but predictable delivery model became known as Waterfall.

The real challenges started to arise in the 1980’s and the evolution of the Personal Computer. Previously mainframe requirements much like building a bridge, tended to be static and so once the requirement was captured and design completed, there was little need for the teams to revisit requirements and make changes late in the delivery process. All that changed when the computer industry began making computers for the general population. Instead of building 10 mainframes per year, companies like Apple were producing tens of thousands of PCs per year, and with that all kinds of software products to cater to consumer needs. The arrival of the Internet accelerated the consumption of software for general use and with that came an explosion of differing requirements that tended to change frequently.

The software industry struggled under the avalanche of change and by the 1990’s, it was clear Waterfall was insufficient when building products for consumers who frequently changed their minds. Clearly a lightweight and more adaptable delivery model was required. The turn of the 21st century heralded the foundation of Agile and a philosophy for software delivery that embraced change (even late in the cycle), was fast moving, adaptable and embraced the concept of light touch management and planning over command and control. Teams were becoming self-organising.

So ‘Agile’ was invented to solve the problem of ‘change’ or to put it another way, Agile allowed customers to change their mind midway through a project without significantly impacting schedule, cost or predictability. It’s worth noting here that Agile was never meant to be an upgrade or a substitute for Waterfall. It merely caters for projects with changing requirements. I would still choose Waterfall any day if I were building a bridge, migrating data or moving products to a new platform. Basically any project where requirements are not likely to change significantly during the lifecycle of the delivery. There is another topic here called ‘Be only as agile as you need to be’ which I will cover another day.

So a little more detail on this Agile Evolution / Revolution. Anyone who was coding in the late 1990’s will probably have experienced the frontrunners to Agile, that was Incremental and Iterative development. Although its origins can be traced back to NASA in the 1960’s, it was popularized as a method for fast delivery in a changing environment. Indeed, the beginnings of SCRUM (probably the most used Agile delivery framework) can be dated back to the 1993. As can Crystal and Xtreme Programming. What all these relatively separate methods had in common was they were all trying to solve the problem of changing requirements and speed to market.

The ‘Aha moment’ for Agile can be traced back to a weekend in Snowbird, Utah in 2001 when many of the early visionaries attended the ski resort to hammer out and sign a ‘Declaration of Independence’ that articulated the philosophy that would lay the foundations for the agile software delivery revolution.

There are many myths and stories about the ‘Snowbird 17’ (now unfortunately 16, since the tragic death of Mike Beedle in 2018). The story goes that after running through a few options—like Chicago (“cold and nothing fun to do,” wrote Highsmith in 2001) and Anguilla (“warm and fun, but time-consuming to get to”)—the group settled on Utah (“cold, but fun things to do”), booking an excursion to Snowbird. There, beginning February 11, 2001, the men—and they were all men—would hit the slopes and talk software processes. James Grenning, the founder of Wingman Software, remembers a blizzard. “We were snowed in,” he says, “and it was like avalanche conditions. No one was going to go anywhere. It was an amazing thing.”

There were other great stories about who was meant to be there but didn’t bother in the end. Ken Schwaber recalls the group did invite “a whole bunch of really pretty knowledgeable women” but that none showed. “They thought it would just be a carousing and smoking weekend,” Schwaber says. “They didn’t think we were going to do anything intellectual or productive.”

But indeed they did. The ‘Snowbird 17’ were made up of Business Analysts, Developers, Testers and Project Managers. They got together, compared their varying software delivery models and came up with the 4 Core Values and 12 Agile Principles that would become known as the Agile Manifesto. This Agile Manifesto was not meant to be a replacement for existing iterative and incremental methods such as Scrum, XP, Crystal. Instead it laid out the overarching and common agile philosophy that would guide all agile software delivery methods.

This new philosophy needed a name, and not everybody was satisfied with the “Lightweight” working title. “It somehow sounds like a bunch of skinny, feebleminded, lightweight people trying to remember what day it is,” Highsmith recalls Alistair Cockburn, another participant, saying. Cockburn remembers facilitating the search for the word. “It wasn’t like somebody said, ‘Agile! Oh great, let’s go,’” Cockburn recalls. “It was really a lot of work.” The other finalist, he says, was “Adaptive.” “The only concern with the term ‘agile,’” writes Highsmith in his 2001 summary of the retreat, “came from Martin Fowler (a Brit for those who don’t know him), who allowed that most Americans didn’t know how to pronounce the word ‘agile.’” Fowler eventually got over it.

2001 and the Agile Manifesto changed so much in the software industry. However it didn’t prove to be the great panacea. As the world of computing and the internet changed everything, the software industry itself struggled to find a balance between producing products quickly that meet the needs of its customers, but also includes a level of predictability around cost, scope and schedule. In a rush to be seen as highly adaptable, many in the industry struggled to balance the need for predictability with adaptability.

2003 saw the rise of Lean Methodologies first developed by Toyota in the 1980’s for car manufacturing. It’s focus on reducing and eliminating waste from the delivery process (also known as ‘from concept to cash’) began solving a significant problem blocking agile software development. In order to be agile, your processes and flow must be smooth and highly repeatable. The Lean Mindset, through pioneering work by the Popppendiecks provided a method whereby teams could analyse the processes they were using and through Value Steam Mapping, identify bottlenecks or wasted effort which was slowing down the process and limiting agility and speed of change.

The idea of Lean was further built upon when the software delivery methodolgy ‘Kanban’ was introduced to the software industry in 2005 by David J Anderson. Not to be confused with the Japanese word ‘kanban’ which translates to ‘signal card’ relates to lean processes. Built upon the processes introduced by Taiichi Ohno of Toyota, this system was created as a simple planning system, the aim of which was to control and manage work and inventory at every stage of production optimally. In terms of software delivery, Kanban is a non-disruptive evolutionary change management system. This means that the existing process is improved in small steps. By implementing many minor changes (rather than a large one), the risk to the overall system is reduced. The evolutionary approach of Kanban leads to low or no resistance in the team and the stakeholders involved.

As Agile models have matured over the last decade, the next focal point was scaling agile for large organisations and multiple teams. While agile methods such as Scrum work very well for small numbers of teams, what happens when you have 100 teams delivering multiple interrelated but separate products? Enter Scaled Agile and the two most common frameworks known as SAFE and LESS. Scaled Agile Frameworks  are sets of organization and workflow patterns intended to guide enterprise in scaling lean and agile practices. SAFe along with large-scale Scrum (LeSS), disciplined agile delivery (DAD), and Nexus, represent a growing number of frameworks that seek to address the problems encountered when scaling beyond a single team.

And there you have it! The journey from mainframe computers to multiple teams delivering changing requirement in a highly lean, yet adaptable working environment. So we have cracked it then? Software delivery is now a doddle? No, unfortunately not. The one thing all these software delivery approaches have in common is that they require discipline and self organization to be successful. They also require change to be implemented across teams and the organization to be successful.

Supporting the changing processes and changing habits is where your Agile Coach comes in.