Introduction
Why, would you think, are we (oh!) so agile? Why do we do Kanban or Scrum?
a) To have more fun?
b) To become a better team?
c) To follow industry standards?
„Take a wild guess!“
Laury Anderson
It is neither of it. To give you a hint, I quote the very first Google hits for „purpose of agile“:
To me, agile is all about embracing change to make our customers awesome.
Jezza Sutton in https://www.quora.com/What-is-the-purpose-of-Agile-and-why-are-so-many-companies-using-it
It puts more emphasis on creativity and innovation that is needed to maximize the business value of the solution
Chuck Cobb in https://www.quora.com/What-is-the-purpose-of-Agile-and-why-are-so-many-companies-using-it
Go down the list of all the most successful companies. They are all delivering products faster, better, and cheaper than the competition because they are Agile…
Jeff Sutherland in https://www.quora.com/What-is-the-purpose-of-Agile-and-why-are-so-many-companies-using-it
Got it? Good. So, let me summarize it. In the software industry we are Agile, because we want to
a) deliver products the customers benefit from and thus are willing to buy,
b) be more efficient (AKA faster, better, cheaper) to gather higher profits (AKA business value),
c) to stay in the market, because everybody else does it and proves it right.
Everything else comes second. To be precise about what comes second, third, fourth, or even fifth:
a) your fun, happiness,
b) team building,
c) Good parentship,
d) work-life ballance,
e) becoming a better person,
f) work from home,
g) healthy snacks.
All of these points are nice, but basically they are just a means of the primary purposes found above. They are contributing to the primary purposes, or will become obsolete, when management finds out it is not contributing.
Efficiency vs. Effectiveness
Efficiency
Efficiency can be summarized as minimizing waste or „to do things well“. Oh. Waste = Muda, which is a central Kanban term for a good reason.
Applied to requirements management, the founders of Scrum have found out, it may be less wasteful to replace fixed requirements specifications documents by a volatile and continuously reprioritized, hence more efficient product backlog.
Applied to team building, intense and immediate collaboration of all required skilled workers seem to be more efficient than silo organizations.
The push principle puts pressure on your people. Often this leads to errors, stress, unnecessary task switches, low throughput, unpredictable processing times. The promise of the pull principle in conjunction with a limitation of work in progress (WIP-limit) is the exact opposite: Happier workers produce better output more predictable.
Effectiveness
Effectiveness can be summarized as „getting the right thing done„.
This is especially tricky in volatile environments. But one thing should be immediately clear: Long cycle times lengthen the periods of feedback points, which is the main reason why a lot (not all..) of waterfall projects fail to produce good marketable products, especially compared to those with short cycle times, AKA Scrum sprints.
BTW: in our context efficacy = effectiveness.
To be continued.