Size matters: why small is better, or a story of how one picture changed a mindset

I admit I struggled with understanding agility. How do you actually do that? OK, I knew some buzzwords and catch phrases - things like "move fast and break things” but at the same time I was naturally thinking in big steps and big projects. It sounded counterintuitive to go small but all those mentors, coaches and other smart-agile-folks were preaching about iterations. One day a colleague at work draw one diagram for me and I was enlightened.
Thursday, January 5, 2023

Of course, agility is not a thing you can become an expert just by reading a book or seeing a diagram but it's muuuuch easier to go down the agile road if you really get the main principle. For me it's in this picture:

On this diagram you see comparison of two methods of work - iterative (navy color) with a small tasks vs. big chunks (let's call it turquoise ;-)).

This turquoise-like color represents "big tasks". After 8 units of time you get 8 units of size of a task (or a project or anything you build). So the turquoise color will show you an area you are covering every time you build something big for a long time.

On the other side there’s this iterative approach. You deliver small tasks (or features), one by one. In practice it can mean releasing it to production.

This diagram show 2 very different approaches (which have consequences). Let’s analyze it together:

  Big tasks, big projects Iterative approach, small tasks
Size of the unknown, feedback delay You delay the feedback for 8 units of time (let it be 8 months for example): will customers like it? does it even work? You get the feedback early on. After one unit of time (let it be 1 month for example).
Effort needed More to test, more to review - such activities are longer and more complicated. Chances of not finding a bug are higher. Tests or review are done faster and it’s easier to read/check the small piece.
Possible bugs, size Until you have it on production you don’t really know if it works properly with all dependencies etc. Number of possible bugs can be big. Number of possible bugs is lower. Does it even work? You find it out much quicker.
Ability to pivot or adjust If you found out there's something wrong about the proposed solution, will you cancel after 4 months or continue delivering the wrong solution? How easy it is to change the scope of such project in that situation? It’s easier to change the scope if the scope is initially smaller. In some situations you may even consider dropping the whole idea.
Managing the change Bigger change = more communication we need to do (to customers, with stakeholders, in knowledge databases and documentations). Sometimes small release note is enough, sometimes it’s not necessary to do even that.
Monetization Long time of development = delay of monetization. Shorter time of development - sooner it can be monetized.

Hope you find it inspiring. It’s actually quite easy to split your activities to smaller tasks but it’s counterintuitive for most of us, so you need to go outside you comfort zone first a few times and after you did that you’re on the road to agile excellency.

Good luck!