This is the story about trust and excellence.
Once upon a time, in some not-so-big software shop, development of a new project was launched. It was kind of side project in terms of day-to-day business. Actually one might say it was very, very side project. Anyway, a small team was formed to cope with a task.
Five brave people formed a fellowship. They all had their talents and they were dispatched to deal with different roles: development, testing, deployment etc. The team had a leader, guy with some battle scars who had seen quite a lot different projects.
Since it was the side project which they were working on the leader told the team they’re free to choose any methods they want – there was no pressure of time, at least at the beginning, and everyone wanted to make it pretty damn good in terms of quality.
So yes, they were allegedly wasting time on things like unit tests, refactoring, collective code ownership, code reviews, continuous integration and such. Yes, they could have been delivering features faster at the beginning, but they chose not to. They chose they’re going to keep all those practices as long as possible.
The leader never put the team’s choice to a question. He used to ask whether they believed they were doing the right thing. He used to see their head nodding as an answer. He trusted the team.
Fast forward: year and a half.
The fellowship kind of achieved the goal they were chasing. The product was kind of complete. The team was disbanded and everyone chose their own direction. But something stayed there. The product. The product which had to be maintained.
New mercenaries took over the code. It was kind of checkpoint for all the choices the original team had made over the project life span.
A couple of opinions which popped up:
- Did they really build it in such a small team in a year and a half? Impressive.
- This is one of best pieces of code I’ve seen here.
Now, doesn’t it sound a bit contradictory?
The punch line: the fellowship did a great job both in terms of quality of the product and pace of building it. They all wanted to excel and they were allowed to. The leader could not possibly verify whether their choices were good, so he decided to trust them.
And the outcome was something which falls into “pretty damn good” category if you ask me. Actually up until project takeover it was kind of speculation, but then the project became a living proof that it’s worth to invest in best engineering practices.
It pays off.
It pays off even when there are some counterintuitive things to deal with at the beginning. Actually it was easy to choose gung-ho approach and jump on building as many features as possible from the very beginning. But somehow from a perspective of time the chosen method resulted in both: good quality and relatively fast delivery.
Of course, all characters in the story were totally fictional and any similarities to real people completely accidental.