≡ Menu
Pawel Brodzinski on Software Project Management

Good Quality Means Fast Delivery

Good Quality Means Fast Delivery post image

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.

in: software development

6 comments… add one

  • Josh Nankivel April 12, 2011, 8:21 pm

    Thanks Pawel. I’d like to hear more about collective code ownership myself, have you written posts on that topic already?

  • Pawel April 13, 2011, 2:49 am

    Thanks for that story, Pawel. It’s very inspiring.
    I think that one of the most important success factors (apart from good leadership, excellent engineering practices etc you are listing) was it was a side project and there was very little market (=top management) pressure.

  • Pawel Brodzinski April 13, 2011, 4:06 am

    @Josh, No I haven’t, at least not directly, but it seems I probably should.

  • Pawel Brodzinski April 13, 2011, 4:11 am

    @Pawel, Good point – lack of management pressure at the beginning was definitely one of important factors of success. But later on there was more pressure but fortunately the team had enough momentum to keep going and there was no need to cut corners on quality.

  • jfbauer April 13, 2011, 8:20 am

    Pawel, really interesting story. Even though I’ve spent the majority of my tenure in large corporate IT shops (~1000+ IT staff), I did spend a brief period managing a small shop of ~20 developers. Your story sparked a parallel experience I had in that shop. The company leadership was trying to get a major client to pay for a new service that translated into a new product. The sales cycle was extremely long with no clear detailed business requirements. All that was known was that the product would deliver a general industry service. Thus, the development team was given a percentage of time to start building the ground work for the product as the sales cycle was dragging on and on and on. Ultimately, the major client said no. The product was paused briefly before a similar sales opportunity popped up for another client. Given the product framework development was left to senior developers (and I had fires burning everywhere else), the framework and the supporting data model was able to be quickly re-purposed and sold to the new client. Compared to the point solution apps in the rest of the application portfolio that were developed against specific business requirements, the framework based product was the most mature code model and most flexible code base.

    Not exactly your experience, but I can substantiate that given loose product guidelines and relaxed time-lines, senior developers can be trusted to build incredibly flexible (and poised for revenue generating) products.

  • Pawel Brodzinski April 14, 2011, 4:19 am

    @jfbauer, Actually we can make it all about people and your story is a strong confirmation of the fact. If you work with senior engineers who know what they do and you give them enough freedom they likely surprise you with the result. And I mean a positive surprise here.

    Then you can that freedom and power from them, step by step, to the point where they mindlessly execute some low-level decisions made somewhere else.

    The real question is: who do you want to see making your technical decisions? Seasoned engineers who have seen many good and many bad solutions or some managers who only see the code when it’s discount code or something.

    Now the interesting thing is most of us would answer the question pointing to engineers and then do something completely opposite.

Leave a Comment