So you might think Agile is new, but you’d be wrong

The title may sound provocative, and that’s on purpose because I’m going to try to convince you that the principles and values defined in modern Agile frameworks, like Scrum, are founded on software engineering best practices that reaches 20 and 30 years ago.  Scrum is not new in the concept sense, but it certainly has exploded in modern software company practices.

In the IT world, within software development companies, process frameworks are commonly relied upon to structure how a project is run. The most common process frameworks used for software projects today are Agile frameworks. There are more than 40 official software process frameworks but only a few have significant popularity, Kanban, XP (Extreme Programming), Scrum topping the list.  The frameworks’ broad usage and adoption are easy to understand since projects organised using an Agile framework typically bring more value to the client in the very early stages of the project and deal better with scope changes (which can be more challenging and disruptive using legacy approaches like Waterfall).

Let’s recall the basic structure of the Scrum Agile framework: a Product Owner encodes business requirements into value statements called “User Stories”, and these are stored in a database called the Product Backlog. The User Stories are frequently refined over time, with larger ones broken down into smaller pieces, to make development easier, per story. The User Stories are considered “ready for development” when each User Story represents one week of development effort or less.  When there are enough User Stories to fill up a Sprint, development can start, because the Development Team only commits to the scope of User Stories chosen for a given Sprint. The User Stories are ordered in the Product Backlog by customer value, with the higher value items at the top of the Product Backlog. The Scrum team commits to developing a “Sprint Backlog”, which represents a subset of the Product Backlog User Stories, taken from the top of the Product Backlog, that the development team is confident they can finish within the timebox defined by their Sprint length. The Development Team (consisting of staff skilled in writing and testing software) self-assign the User Stories from their Sprint Backlog, as they see fit, because they are a self-managed team, with the expertise to understand how to best organise their work. The Development Team works on the User Stories until they are “Done”, that is, they entirely fulfill the business needs. The whole cycle, beginning with Sprint Planning, through to the end of the Sprint timebox, is called the “Sprint”.  During a Sprint, the Scrum Master supports both the Product Owner and the Development Team by supporting the daily Stand-up, and by helping to remove any impediment anyone on the Scrum team may have.  A product or service roadmap typically requires multiple Sprints to define a Release that the company is targeting to customers.  However, because Scrum is delivering that product roadmap with a series of Sprints, incrementally building the product or service, the Scrum process framework supports getting customer feedback, and reprioritised User Stories, at the junction of each Sprint. This flexibility means Agile development can deal with changing requirements as a core capability of the framework. That’s it, Scrum in 60 seconds!

Software was born in the 1960’s, so did it take until the advent of Agile for software engineering to recognise the value of doing things in an iterative way, or using any of the other Agile framework principles?  Let’s explore this question…

Late Millennials and early Generation Z, those born around 1995, and who only recently joined the workforce as developers, tend to believe that the Agile way of doing things is a new concept, bringing software development into modern times.  They may be right, in so far as the popularity of Agile frameworks has logarithmically accelerated in the past 10 years, but as a concept, is Scrum really new? The answer, which may surprise you, is no.

I started my software developer carrier as an intern for an investment bank in Brazil, back in 1996, when millennials were still babies or hadn’t even been born yet. At that time, our (the bank) computers were not even connected to the internet, and we kept the installer of the software we were working on floppy disks! Aside from that, to complete the context, there are two aspects that need to be highlighted in this previous experience: i) we don’t fool around with other people’s money; ii) Brazil, as much as it can be claimed to be chaotic (I can say that, I’m Brazilian) does something extremely well: IT development and the managing of IT policies and regulations for the financial market. Many years of hyperinflation led us to develop one of the most adaptative financial IT environments in the world.  Brazilians are not afraid of changes in regulations, that usually turn existing software solutions upside down. Even our currency has changed its name and value four times in the last 40 years.

The Brazilian government got into the Agile act just as fearlessly.  Around 1998 I was a member of a team of developers working in the Shareholder system for investment funds. The Brazilian government wanted to anticipate the receipt of taxes of fixed income funds by collecting them on a monthly basis, not only on the redemption of the money. As the old saying goes: “there are only 2 things in life that we can be sure of, death and taxes”, and so it is in Brazil too. According to the Brazilian government…since it’s unavoidable, let’s just calculate taxes correctly, to prevent from future problems.

Back then, when I was working in the finance sector in this specific assignment for the government, our daily processes and routine had a lot in common with Scrum, even though Scrum wasn’t even a framework yet. How did we organize our team to meet those requirements? We had a person (the back-office leader for the Asset Management area) that was responsible for all software requirements that could affect his area, and for refining them. He didn’t know at that time (neither did we), but he was playing the role of product owner without being labeled specifically as such.  The development team itself consisted of 3 developers, doing pair programming, and reviewing each other’s code, collaborating as suggested by Scrum. The team was also responsible for unit tests. We had a specific requirement, although mandatory, that would bring a lot of value – real value – to the client (the government). As for the shareholders, they were not very happy with that change, but we cannot have it all. Was it cyclic? I’m afraid not. At that time, the due date was very challenging, and we didn’t think of doing things and then refining them. We had one shot. We didn’t have a scrum master (in fact, we hadn’t even heard of it before), but we felt we had to manage this project in the better possible way to prevent from falling behind schedule and not making the deadline. How did we do that? Using common sense and conducting daily status meetings to check for advances and impediments that needed to be removed.

Sounds familiar? I’ve demonstrated, using references to my financial and government-oriented software engineering experience in Brazil, that software teams were using practices that are very similar to modern Agile/Scrum practices, and that these “best practice” guides are not revolutionary, but more representative of the evolutionary advancement of our software profession, over decades and decades.

The point in all this is that, in software development, a “new” framework will hardly ever be a disruptive new approach, different from everything we have seen before. Most likely, it will be the formalization and standardization of good practices proven to be effective in the past. Just like Darwin’s evolution theory. In the same way, a new species doesn’t come from anywhere but instead is a sum of tiny changes over time, and so is a software development framework.

To find out more about our Software Development capabilities, contact the team today.