Before we can even begin discussing Agile and its friends, we must understand more traditional organizational philosophies. Many organizations practice a system in which decisions cascade down a series of steps. As the flow of decisions and ideas is one way (top to bottom), the system has come to be known as the waterfall model.

This system was first formally outlined in the 70s, but was already widely practiced by this time. Even then, people recognized that the advantages of hierarchical systems marched shoulder to shoulder with some serious disadvantages. It was argued that agility and adaptability were integral parts of the development and innovation process. Despite the limitations of the waterfall model, it is still widely practiced by software companies.

Agile Software Development As A Means To Innovate And Create

In 2001, 17 leading software developers met in Utah. The product of this meeting was the "Agile Manifesto." Although an important step in the innovative move towards less hierarchical and more responsive systems of business, it was by no means the first.

Scrum is perhaps one of the most widely known and practised versions of the agile/lean philosophy. It was first formally outlined by Hirotaka Takeuchi and Ikujiro Nonaka of Japan in 1986. At the time, the Japanese economy was booming, and many Japanese companies were outperforming Western rivals. Takeuchi and Nonaka recognised that many of the best performing Japanese companies, such as Toyota, practised a system they analogized as being like a game of Rugby.

As in many ball sports, players pass the ball back and forth in Rugby. Sometimes the ball goes forward, and sometimes it goes backwards; whatever is best given the circumstances. That is how Takeuchi and Nonaka discovered how Toyota was operating. Individuals and teams were not merely receiving, adding, and passing along. Decisions and ideas were passed back and forth, up and down. This helped Toyota become more agile and lean, and in so doing, overtake its competition.

This style is not unique to Toyota, or even Japan. It has been practised widely and across cultures and industries. According to a 2016 study by Atlassian, 80% of software developers practice agile/lean in some way or another. Some may be practising Scrum, others Kaizen, or something else. At the end of the day, however, these methods are more alike than they are different. The same goes for their overarching philosophies: Agile and Lean.

According to the ‘Agile Manifesto', it's all about the end user. Through early and continuous delivery combined with sincere retrospection, agile teams aim to make what end users actually want, not what they think they want. This is accomplished by, among other things, having an agile workplace and working culture. Individuals and teams are encouraged to not only seek out and implement end user wants and needs, but also to work in close collaboration with others within the organisation: to trade ideas, share in decisions, and if necessary, re-invent processes at the micro-level. Kazien is much the same.

Kaizen comes from the Japanese Kanji "Kai" (meaning "change") and "Zen" (meaning "good"). In Kaizen, good change is achieved incrementally. It's slow and steady, and shared: "continuous improvement by everybody, every day, and everywhere."

Splitting Hairs or Distinct Philosophies And Methods

Like Agile, Lean has its origins in manufacturing. And like Agile, customer alignment (and realignment if necessary) is a fundamental principle. However, in lean development, Albert Einstein's maxim: "make things as simple as possible, but no simpler" is relentlessly pursued. This is typical of the differences between Agile and Lean, Scrum and Kaizen. Principles of user-centered design, agility and adaptability, and sincere retrospection are central to all of these systems of business, but the devil in the details. Lean emphasises minimalism, and Agile emphasises iterative processes, but there is no reason think Lean cannot be iterative, or Agile minimalistic.

So closely related are these philosophies and methods that some people say Lean is a type of Agile, while others say Agile is a type of Lean. These quibbles are unimportant. What's important are the practices that both of these espouse. Though perhaps less innovative today than they were in 1986, principles of user-centered, responsive design remain best practices.

Innovate Processes, Then Innovate Products

So whether you call your business practices Agile, Lean, Scrum, Kaizen, or something else, make sure that you keep your end users in mind, and be sure to value agility and adaptability over centralisation and tradition. There is a reason why user-centered principles are recurring in these methods. Being responsive to user wants and needs is good business.

Before the holiday break, I wrote an article on how to innovate with end-user engagement. Check it out for a fuller idea of agile and lean principles in practice.