How to explain Agile and Scrum to your grandpa in 5 mins. And to better understand both yourself
You’ll see that agile is pretty intuitive.
When you can’t explain something in simple terms, you begin suspecting that something might be off. Especially if your brain works in the same way mine does: to fully understand how a bicycle functions, I need to reinvent one.
In agile, if I had a common issue and would find a solution to it, I’d tell myself every time (or my team would tell me):
“Natasha, Stop! Don’t think.
You have merely read 3 books on the subject, went to a couple of 2 day workshops, attended an agile camp, watched several videos and had a few strategy sessions with agile coaches. Well, and also spent a few years in a sсrum process.
It’s pretty obvious, Natasha, that you ha-ha! — what could you possibly understand. Do not dare looking for an answer to your problem yourself. Write it down and wait for your agile coach consultation.”
Oh, but I really loathe it when I shouldn’t think. It’s the “shuhari” principle: you are not allowed to turn on your common sense. Doesn’t it look kind of suspicious?
Joining the camp of agile-haters is not an option for me. Everything in me embraces the agile principles. I am a change-person and I can’t do without flexibility.
I decided I will have a nerve to write a post on how agile and scrum are actually pretty intuitive, and it’s important to turn them on at the right moment. And turn them off at the right moment as well. Once again:
And turn them off of at the right moment.
So, call your grandpa over and let us begin.
Explaining agile to grandpa
— Grandpa, imagine this: you are young, you just got married. Someone let you and your wife stay over for the summer. But winter is coming, you need to build a house in time. What would you do? (My examples might look weird, but I come from Russia and for my country they are very common. The situation was very typical at the time when my grandparents were young.)
— I would build a tiny house, but with a solid foundation, so that we can move in before the cold hits. Would lay the roof in a simple fashion, just so we could pass the winter.
— And then?
— Then the next summer I would build an annex and redo the roof in a solid way. The summer after that — I’d build a porch. The summer after that one — maybe would add another floor. I’d decide with my wife what to do first and what to do next.
— Great job, grandpa. Now memorise:
We will call the house a ‘product’. Yep, don’t laugh.
Your first “just to move in to somewhere” house is an MVP. I.e. a minimum viable product.
The house with an annex and the house with the porch are increments.
You are a product owner, you take care of what the house will look like.
Your wife is a stakeholder, her opinion matters, because she will have to live in the house.
The list of the annex, porch, another floor, solid roof and whatever else you would like to build is a backlog.
When you and your wife sit down and decide what to do, you groom the backlog.
— Now tell me, grandpa, how would you go about building your house.
— Well, I’m a poor builder myself, but I’m a good setter-up, so I would keep working at the factory. I would invite my brother and uncle Vova to build the house for me. My brother is a handy person, and uncle Vova is a smart one — he can do all the blueprints and calculations. Both are great workers. Finally, I would ask my neighbor to feed them three times a day and upkeep the peace between them in case they start arguing.
— Perfect. Now put it down:
Your brother and uncle Vova are the developer team.
Their strength lies in being able to replace each other. So they are T-shaped people: they both can do one specific thing very well, but in everything else they can help each other out.
Your neighbor is a scrum master. Her main task is to upkeep the team’s spirit.
— How would you make sure they do everything well? And of not running out of building material?
— In the beginning of each week I would discuss what needs buying for the following 1–2 weeks. In the morning, before leaving for work, I’d have coffee with them at the neighbor’s. Would look closely at what they’ve completed and what they will be building. From time to time we would probably all get drunk together and then each one would complain that the others are working worse and less. But then we would be reconciled.
— Ok, grandpa, so:
Your discussion at the beginning of each week is a sprint planning.
Your morning coffee is a stand up.
To get drunk and start arguing is to run a retrospective.
— Grandpa, but what about your wife? She would probably be interested in taking part in building the house, too.
— I’d bring her along every fortnight. Just in case something might go wrong.
— See what we’ve got:
Each fortnight before your wife’s visit is the length of your sprint.
When your wife comes — it’s a sprint review. You should plan your sprint in a way that would allow you to always have something to show to her.
Your housewarming party is the product launch.
— So, grandpa, here we are. You have just reinvented agile and a major part of scrum. When we need to build something quickly and cheap, we find flexible solutions intuitively. It has happened many times in history.
While colonizing America, settlers travelled to the West, far away from the civilization. They were limited in resources and time, and they had to construct a dwelling before the winter. In the first year they would build small sod houses, with an oven made out of stone and dirt. It was their MVP. The next year they would build a cabin out of raw timber (that’s version 2.0 of their product). Only from year 3 would they usually start building an actual solid house.
Residents of favelas in Brazil have more time, and there’s no winter. But they have limited money and resources. They build their rooms with big bricks, also in an agile fashion. They build as many walls as the bricks they could afford to get. They can finish it later, and then add windows, lay a roof, and sometimes even paint the walls. When the family grows, they build the next room.
Gradnpa, developers never have enough resources to do all they want , so they also found a flexible approach and called it ‘agile’.
Agile is flexibility out of necessity. It’s being prepared to live in a small house first, meet your team often, work with those who can do several things at once, and add changes as you go.
Scrum is a framework of interactions, operations and roles which are required for flexibility.
To agile, or not to agile
— Grandpa, what would you do in case you’d have enough money and time to build a big solid house right away?
— I wouldn’t bother with a small house then and would just hire a construction company to build a ready to move in house for me. We would settle on a plan and sign up a deal. I would visit the construction site several times, to check how the work is going, but more out of curiosity, because they would definitely build everything according to the plan.
— But building a big house right away would take much more time. You wouldn’t be able to move in by September then!
— Well, I’d rather wait six months but have a solid two-storey house ready to move in to. At the end of the day I would actually save up a lot. Would not waste my resources on a temporary roof and would have a solid roof from the start.
— What if you were unsure whether you wanted to live in an apartment or in a house?
— Then I would probably build a small house first. I don’t want to wait a long time and spend a lot of money on something I might not actually need.
What is there to learn for the kids
Grandpa definitely understands everything now. What about his grandkids?
- Agile principles are intuitive. When we have limited resources, we become more flexible and go agile. I would add one more point to the Agile Manifesto: “Common sense is more important than anything else, including agile itself.”
- If we don’t know whether or not we need the product in the first place, or what the product should look like, we are better off building it in an agile way. Even if we have enough resources. Any experimental project needs an agile approach.
- If we have resources and know that we do indeed need the product and what it should look like — we should forget about agile and just build it. What we need here is good project management. In this kind of scenario we will loose, not gain from agile: we won’t be able to optimize deadlines (will be building for 3 years instead of 6 months) and expenses (will pay for two different roofs instead of just one).
P.S. The story about grandpa has a sequel: How to explain web analytics to your grandpa in under 5 mins (with pictures). Translation coming soon! Stay tuned!