Meet the new boss, same as the old boss. Whether called Agile or Lean, Scrum or Kaizen, a number of recurring principles have become the underlying theory of software development, and the backbone of innovative software developers. But what are these principles and philosophies? Are they distinct? Or are they merely new names, same faces?
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.
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."
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 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.