Recently, my team shipped a product, working at Southworks, after hard work. There were interesting and intense days, and now, I want to write down some lessons learnt from that project, and from others works, during 2007 (and part of 2006).
Architecture decisions must be taken by only one person. This is a lesson that not all my coworkers share, but for me, it’s clear that too many hands on that decisions, could produce a suboptimal result. The member that decides on architecture must hear the other members opinions, actively asking them about problems to resolve, but the final cut on architecture must be made by only one person. I’m skeptic on emergent design, at least on some kind of projects that involves new challenges.
You must be aware of the status of the whole project. As a team member, you must not forget the full picture. It’s your responsability (and the responsability of each member) to keep an updated vision of the advance (or lack of advance) of each committed final deliverable, not only yours, but the other members too.
Don’t hesitate to rise a red flag. At any moment, if you feel that something is out of track, or if you see a potential problem, you must rise hands, and communicate clearly and firmly that problem to the rest of the team. If they were a problem, don’t forget call Houston.
Pursue visibility of what you are doing, and demand the same from the rest of the team.
Practice your communication skills. Give presentations about the advance of the project, lessons learnt, to your peers. This activity increase the team understanding of the project. If you understand something, you can explain it. This is a test of your grasp of the project ideas.
Write down vision and mission for the project from the very beginning. You can have an internal and external mission and vision, but your team must write down those items, and must have a clear understanding of them.
Minimize risk. You must resolve the riskiest part of the project, or be early aware of where risks could rise, and manage to minimize its dangereous influence. Write down proof of concept apps, or take time to spike on ways of doing things, but don’t hesitate to assign resources on those risk management activities.
Every deliverable must be important to you. If you are a coder, don’t forget documentation. If you are a writer, don’t miss the graphic appearance. The process should produce a whole product. You and your team are in charge of the full final result.
Don’t live with broken window. It’s a concept I learnt from “The pragmatic programmer” book. It means that you must not leave open little holes, incomplete work, hand-wired implementation. You must proud of the final product. Any quick hack must be avoided, as it usually spread its influence, as a rotten apple. More on the concept at:
Don’t live with broken window, a conversation with Andy Hunt and Dave Thomas
Get the right people in the team. A team must be composed of different personalities, with complementary skills. If they all were coders, nothing of sustained value could be produced.
Write down a glossary. This is a task that is frequently forgotten. If you don’t have a glossary, explaining the main concepts involved in the project, your team won’t grasp the key ideas and problems that compose the solution to build. The lack of glossary could lead to miscommunication and confusion, inside the team, and in its relation to customer and stakeholders.
Draw a conceptual map of the whole project, and discuss it with the team. Use an initial meeting to talk about the full model, vision of the project.
Write down a clear list of the final deliverables to produce. Specify a clear contract with the customer, setting his/her acceptance criteria of those deliverables.
Talk the customer language. This could be related to the glossary item. You must understand and use the customer language. You must frequently communicate with her/him, and take account of his/her necessities and problems to resolve.
I didn’t follow all these recommendation all the time, and then, I suffered the consequences of not adhere to this list.
I can think of a few more lessons learnt, but the above list is good enough for now.
Angel “Java” Lopez
http://www.ajlopez.com/en
I’m reading the book 
