One of the rare reasons why I’m proud to be Italian is a sentence by an anonymous author, back in the 1300’s.
More than 700 years ago. Yet I think it has something to teach us about Agile.
Niuna impresa, ben che minima, può avere cominciamento e fine sanza queste tre cose e cio è: sanza sapere, sanza potere e sanza con amore volere.
This is Old Italian and part of its beauty is concealed in its funny and weird sound. I’m not able to translate it properly. My best attempt (thanks, Iacopo!) is:
No endeavour, not even the smallest one, can be undertaken and accomplished without these three things: knowledge, authority and loving yearning
Please, read it carefully. I find it amazing.
I think this sentence is a masterpiece of synthesis. No single word in it is useless nor redundant. It’s pure KISS, a clean-code sample from 1300’s. It has a quite perfect cohesion: each single word is there for a precise, single reason (I would say: single responsibility). Take away a single random word off from it and you will loose a vital piece of the whole meaning.
The sentence doesn’t simply refer to doing stuff, but to do endeavors. The original Italian word also means business, and, more broadly, enterprise. It’s funny, isn’t it?
Hence, it’s about doing challenges, not just common and trivial things.
In this context, accomplishing a challenge refers to something that, once achieved, leaves its mark and improves, even if only minimally, the world. It’s about things that have a valuable significance.
Something that has a business value.
Inception, Done done
It doesn’t just say that you could not complete a project, but also that you could not start it, you could not conceive it.
That’s a very strong statement: if you start something badly, you’re only persuaded to have begun it. You have not designed a challenge, but a caricature of it.
In order to conceive a challenge you need the same requisites needed to win it to be satisfied. They must be constantly satisfied. Yes, you can progressively refine your work but the intent must be consistent.
Start badly something means to begin working, then to neglect it for too much time.
XP prescribes to put in the trashcan the code you haven’t finished in the day job. Don’t commit it, it has badly begun.
Kanban’s leit motive could be: Stop starting, start finishing.
Undertaking a challenge is as difficult as accomplishing it.
It’s a meaningless thing: pull away
It says that the principle applies regardless of the size of the project.
“Ok, here you can pull away, it is just a little piece of code, just a trifle“.
Nope, man. Avoid this approach. Even the longest journey begins with one single step. No single step is meaningless.
Clean Code teaches us to actively look for the trifle: neglecting the little things ruins the great.
TDD demands little improvements and each one must be carefully protected by tests: be sloppy and careless declaring your intents before writing a single method and you will pay it with more maintenance later. Never increase your technical debt.
A big, excellent project is the result of many small challenges. You must apply each single principle to each sprint (a small scale) if you want them to be applied to a greater scale.
Each sprint has the value of the entire project and it is worth the same effort.
It says that knowledge and technical capability are necessary. If you are not good at something, you won’t be able to do it properly. Quite obvious.
XP requires as prerequisites an experienced coach, team members with strong design skills and a set of shared and well known team agreements. It makes a sense.
The message here is: knowledge is necessary, but not sufficient. Knowledge alone is not enough without will.
You must also have freedom, autonomy and power to decide things that matter, or the project will fail. You have to be free from constraints that limit your authority.
Hierarchical structures and bureaucracy often deny that.
With Waterfall, especially with high structured hierarchies, decisions are taken at the beginning of times and from above. Developers don’t partecipate to meetings: somehow, they just have to follow dictates.
In terms of authority, freedom means the freedom to partecipate. Partecipate to meetings, where decisions are taken and knowledge is shared.
I think that makes the real difference between a Waterfall, old-fashioned Team Leader and a Scrum Master.
Wikipedia defines a team leader as
someone who provides guidance, instruction, direction, leadership to a group of other individuals
A Scrum Master doesn’t instruct people nor guides them. She’s not a leader in that sense.
A Scrum Master is accountable for removing impediments to the ability of the team to deliver the sprint goals. The ScrumMaster is not the team leader but acts as a buffer between the team and any distracting influences.
A Scrum Master serves as a facilitator for both the team and the Product Owner. She does not limit the authority nor the power of team members: she enforces them, she gives the opportunity to employ them.
XP’s Real Customer Involvement and the concept of On-Site Customer mean that the customer is close to team members, and communication happens without filters. Developers have a real, close control over knowledge. Control means power.
Knowledge and power for themselves, in turn, are not enough: only deeply wishing you’ll bring to conception and to completion a challenge.
Since you can not force anyone (even if it is wise and powerful) to properly conceive and complete a business against his will, you must involve him.
Yes, of course: you can force someone to work. But not to work properly. Anyone will be far from excellence if he feels obliged. Dalai Lama said
The nature of our motivation determines the character of our work.
Stand-up meetings are about involving people and building a cohesive team. Open spaces, pair programming, informative workspaces and retrospectives serves this objective too (not this only, of course).
Yet longing is not enough.
My customer really desires the project to be delivered. She needs it for her business.
I want to deliver the project as well. Yep, because I need a vacation, or a promotion, or because I want to start a new project or whatsoever. We both desire the same, for different reasons.
More commonly, the customer wishes a product for its business value. We programmers wish to produce cool code.
Cool code is not about business. The customer doesn’t care.
In order to undertake and accomplish a challenge, just wishing is not sufficient: you need to loving wish.
To me, it means that you’d need to love the idea of how and how much the challenge will be changing the world when accomplished; it’s about the deep significance and value of your endeavor.
I’ll be able to really deliver value only if I’ll be wishing the same thing the customer wishes: or, in other words, only if I’ll desire to see my customer happy.
XP considers the customer part of the team.
Ubiquitous Language is useful to capture requisites, reduce ambiguities and understand the problem. Yet I think it’s also useful to move developer’s desires from code and technical stuff to what the customer thinks do really matter. It helps the developer to love the idea of a result the same way the customer loves it.