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
WOW, so much stuff here, an excellent blog, I like it. Thanks guys, and wish you good luck!!
Comment by alex j. flex — December 28, 2007 @ 1:19 pm
I wonder what are your observations on the role of the customer in your agile project? Providing requirements, agreeing the concept map and glossary are somewhat obvious; but what else?
Comment by Arvindra Sehmi — January 10, 2008 @ 9:26 pm
Interesting question, Arvindra…
Well, the customer, in an agile process, like Scrum, is a key part of the process. For example, during the iteration, the team must focus on adding value TO customer, not doing what they want, or what is easier, but what is real value to the customer. The iteration review then, is as a test on that focus.
Understanding the customer, talk his/her language, is part of the team responsabilities.
Some methodologies interacts with the customer during the process. Scrum has a bias to interact using a product owner, and in milestones like iteration review.
Then, one of the roles of customer is to provide enought feedback to detect any misleading work DURING the process. He/she can propose new directions of work, if he/she detects some problem during the process.
In case of a fuzzy project, the team produces deliverables that show a more clear vision of the final product, and the customer can then suggests new priorities or new key features.
Remembering agile manifesto: Customer collaboration over contract negotiation (but this could be the topic of another post….;-)
Comment by ajlopez — January 11, 2008 @ 4:23 pm