Agile, Lean, Scrum, Kaizen: New Names, Same Faces?


Before we can even be­gin dis­cussing Agile and its friends, we must un­der­stand more tra­di­tional or­ga­ni­za­tional philoso­phies. Many or­ga­ni­za­tions prac­tice a sys­tem in which de­ci­sions cas­cade down a se­ries of steps. As the flow of de­ci­sions and ideas is one way (top to bot­tom), the sys­tem has come to be known as the wa­ter­fall model.


This sys­tem was first for­mally out­lined in the 70s, but was al­ready widely prac­ticed by this time. Even then, peo­ple rec­og­nized that the ad­van­tages of hi­er­ar­chi­cal sys­tems marched shoul­der to shoul­der with some se­ri­ous dis­ad­van­tages. It was ar­gued that agility and adapt­abil­ity were in­te­gral parts of the de­vel­op­ment and in­no­va­tion process. Despite the lim­i­ta­tions of the wa­ter­fall model, it is still widely prac­ticed by soft­ware com­pa­nies.

Agile Software Development As A Means To Innovate And Create

In 2001, 17 lead­ing soft­ware de­vel­op­ers met in Utah. The prod­uct of this meet­ing was the “Agile Manifesto.” Although an im­por­tant step in the in­no­v­a­tive move to­wards less hi­er­ar­chi­cal and more re­spon­sive sys­tems of busi­ness, it was by no means the first.

Scrum is per­haps one of the most widely known and prac­tised ver­sions of the ag­ile/​lean phi­los­o­phy. It was first for­mally out­lined by Hirotaka Takeuchi and Ikujiro Nonaka of Japan in 1986. At the time, the Japanese econ­omy was boom­ing, and many Japanese com­pa­nies were out­per­form­ing Western ri­vals. Takeuchi and Nonaka recog­nised that many of the best per­form­ing Japanese com­pa­nies, such as Toyota, prac­tised a sys­tem they analo­gized as be­ing like a game of Rugby.

As in many ball sports, play­ers pass the ball back and forth in Rugby. Sometimes the ball goes for­ward, and some­times it goes back­wards; what­ever is best given the cir­cum­stances. That is how Takeuchi and Nonaka dis­cov­ered how Toyota was op­er­at­ing. Individuals and teams were not merely re­ceiv­ing, adding, and pass­ing along. Decisions and ideas were passed back and forth, up and down. This helped Toyota be­come more ag­ile and lean, and in so do­ing, over­take its com­pe­ti­tion.

This style is not unique to Toyota, or even Japan. It has been prac­tised widely and across cul­tures and in­dus­tries. According to a 2016 study by Atlassian, 80% of soft­ware de­vel­op­ers prac­tice ag­ile/​lean in some way or an­other. Some may be prac­tis­ing Scrum, oth­ers Kaizen, or some­thing else. At the end of the day, how­ever, these meth­ods are more alike than they are dif­fer­ent. The same goes for their over­ar­ch­ing philoso­phies: Agile and Lean.

According to the ‘Ag­ile Manifesto’, it’s all about the end user. Through early and con­tin­u­ous de­liv­ery com­bined with sin­cere ret­ro­spec­tion, ag­ile teams aim to make what end users ac­tu­ally want, not what they think they want. This is ac­com­plished by, among other things, hav­ing an ag­ile work­place and work­ing cul­ture. Individuals and teams are en­cour­aged to not only seek out and im­ple­ment end user wants and needs, but also to work in close col­lab­o­ra­tion with oth­ers within the or­gan­i­sa­tion: to trade ideas, share in de­ci­sions, and if nec­es­sary, re-in­vent processes at the mi­cro-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 in­cre­men­tally. It’s slow and steady, and shared: “continuous im­prove­ment by every­body, every day, and every­where.”

Splitting Hairs or Distinct Philosophies And Methods

Like Agile, Lean has its ori­gins in man­u­fac­tur­ing. And like Agile, cus­tomer align­ment (and re­align­ment if nec­es­sary) is a fun­da­men­tal prin­ci­ple. However, in lean de­vel­op­ment, Albert Einstein’s maxim: “make things as sim­ple as pos­si­ble, but no sim­pler” is re­lent­lessly pur­sued. This is typ­i­cal of the dif­fer­ences be­tween Agile and Lean, Scrum and Kaizen. Principles of user-cen­tered de­sign, agility and adapt­abil­ity, and sin­cere ret­ro­spec­tion are cen­tral to all of these sys­tems of busi­ness, but the devil in the de­tails. Lean em­pha­sises min­i­mal­ism, and Agile em­pha­sises it­er­a­tive processes, but there is no rea­son think Lean can­not be it­er­a­tive, or Agile min­i­mal­is­tic.

So closely re­lated are these philoso­phies and meth­ods that some peo­ple say Lean is a type of Agile, while oth­ers say Agile is a type of Lean. These quib­bles are unim­por­tant. What’s im­por­tant are the prac­tices that both of these es­pouse. Though per­haps less in­no­v­a­tive to­day than they were in 1986, prin­ci­ples of user-cen­tered, re­spon­sive de­sign re­main best prac­tices.


Innovate Processes, Then Innovate Products

So whether you call your busi­ness prac­tices Agile, Lean, Scrum, Kaizen, or some­thing else, make sure that you keep your end users in mind, and be sure to value agility and adapt­abil­ity over cen­tral­i­sa­tion and tra­di­tion. There is a rea­son why user-cen­tered prin­ci­ples are re­cur­ring in these meth­ods. Being re­spon­sive to user wants and needs is good busi­ness.

Before the hol­i­day break, I wrote an ar­ti­cle on how to in­no­vate with end-user en­gage­ment. Check it out for a fuller idea of ag­ile and lean prin­ci­ples in prac­tice.

Discover Software


Eban Escott

Big pic­ture thinker and Star Wars fa­natic

Get cu­rated con­tent on soft­ware de­vel­op­ment, straight to your in­box.

Your vi­sion,

our ex­per­tise

Book a chat