How can five brilliant people screw up a release?

Not sure if I should count myself as brilliant... so see it as four or five as you find appropriate. Anyways the point is, being part of a leading product development company, as you would expect, this team of five is technically impeccable. They are reliable and hard working wherever necessary. So, how could a release be goofed up with such a combination?

On retrospect, the answer is pretty simple. We were brilliant in our individual affairs and were not really working together towards a common vision. Each one had our set of tasks that we completed to "OUR" level of satisfaction. The "OUR" really demands an emphasis. There was absolutely no acceptance or definition of done. There were nobody to certify that this is actually done. Real stakeholders who were concerned or beneficiaries were never consulted. There were no testers in the team. The central group of testers sitting in another corner of the floor chip in only after the sprint is over or product is available as a build.

Although everyone in the team seem to feel that they could have better handled the process, nobody wants to meetup for defining any part of it!

I think my team is no different; half of world software development community works this way. Requirements come in from product manager, architects, engineering managers, service engineering team, customers, solutions team and sometimes from the dev team itself. The busy engineering team manager decides priorities on the fly and usually, the team is confused on what should go in the next release and is always contemplating where the new bug will find a place in the managers head (towards a release fitment).

Although it is ok for inexperienced teams to get started this way, I hope the team realises this fact that process also evolves just like the product and its important to define and execute a feedback loop to improve the way they do software development. A team that thinks meeting up for process improvement is not worth their time, is either not trusting its own members or just believes they have no control in influencing a process for themselves. In either case, if you are a team member of this kind of a team; your life is set. Its only difficult to be part of a high performance team; not a low performing one.

Lighter side apart, I believe the summary is this:

Some very basic laws that I learned due course:
* Respect your team members and build a team first and then worry about building your product.
* Evolve your product, slow but steady.
* Don't keep your testers far away. Having a central or a different testing team means there is no testing team.
* Don't try to influence your team too early. Win their trust before suggesting process changes.
* If you do not have time, find someone else to drive a release.
* If you believe teaching your team a good discipline of working (as in a process) is not worth it, you will pay for it any ways.
* More than doing everything right, learn to do the right things first.
* Don't fear losing your job today; fear about getting a job tomorrow.
* Know that your are engineering and not inventing a product. Engineering must be professional (predictable, efficient, repeatable and long-standing) and not innovative.
* Engineering best practices come from years of hard work and painful observation. If you think the authors are idiots and if someone had told you that theory should not be practised, please think again. You are screwing up your own life unnecessarily.