Breaking the build is highly prejudicial to the productivity of a development team. Since it’s pretty easy to avoid it by ensuring that the code compiles locally against the latest version and doing continuous integration, it is often taken as an act of rudeness.  The person responsible for the act must therefore be punished.

Photo courtesy of seeb’s Photo Stream

The punishment often consists of making the guilty party wear a specific hat (we use a Sombrero) or any other very visible humiliating clothes, until they solve the problem themself.  In addition to this, some teams may want to signal breaking builds with a specific sound played on speaker (we used a darth vader or homer simpson voice).  Some teams get even more creative as you can see in this video.

I found the whole thing very funny and I always promoted it in every team I worked in to reinforce team spirit.  That is until I met a couple of people who were really reluctant to join in and did not want to publicise their actions.  Even when I broke the build on purpose to wear the hat, it did not change how they felt about it.  One of them was from a different country where such humiliation could not be taken to this degree (as we can, I hope).

I think this kind of game is one of the many things we see online and we want to replicate without thinking, but it is not always a good idea. While it can be a very good team building feature, it can also contribute to making some team members very uncomfortable.

If you really want to do it as the manager/team leader, ask every one in the team individually. Asking in front of others will prevent you from getting honest feedback.  In fact, it’s usually better not to implement such a rule in your team unless it’s really something everybody wants.

As a consultant, I worked in various domains such as utility, telecom, aeronautics, finances, insurance, etc and I’ve faced the problem of not knowing very much about the domain I was entering.  With time, I discovered a very simple method that works: being actively curious.

• Request a one to one introductory meeting with your supervisor with the purpose of getting them to explain the business domain (the big picture). It should not last more than 4 hours (or you will get bored and your supervisor exhausted).  Prepare your questions in advance.  Take notes.
• Ask the supervisor for a field visit. When I worked in the telecom industry, I asked to visit the router and transmission rooms as well as the NOC (Network Operations Center). It helped the team building the software to understand the purpose instead of blindly writing code. We knew why our stuff was useful and more importantly, who will be using it, and how.
• Have frequent lunches with suits.  More frequently, I would say, than with fellow programmers. They love to talk about their stuff and if you listen carefully, you will learn lots of amazing things.  Be prepared to share some amazing stuff with them too or they will soon find you very boring.
• When you have the chance, visit the departments. Ex: when I had to work with a marketing manager of a big finance institution, I asked how our applications helped them and what was her routine.  By actively listening to her, I was able to find out new stuff to automate and make her work life easier. I suggest you make a physical visit rather than a phone call.  This means you can see her doing the thing and more importantly, using your application!  What is obvious for you may not be so obvious to the rest of the world.
• Buy books on the domain and watch youtube videos. Read your domain’s information websites as well. Give priority to higher level literature. Books that are too technical could be boring or impossible to understand in the beginning. What you need is general concepts to fuel conversations and learn more.
• Talk about it to your friends & family often. Talking about your stuff will help you integrate the huge amount of information you must learn. Prepare an elevator pitch and be prepared to give details. Don’t hesitate to write it down so it is easy to remember.
• Read all the news your company publishes. Including annual reports. In fact, the first thing to do when you are hired by a new company, is consult their website and publications.
• When you don’t understand something, don’t hesitate to ask the guy in the company (email preferred) that can answer your question. The worse thing that could happen is being told that (s)he has no time for that.

Remember this: the developer that knows the domain very well is no longer just a simple developer.  You are a little more than that.  And so is your market value.

Here a “light” Agile Software Development checklist that I have used for many years to introduce Agile in organization. I usually introduce few items per week.

Product Management

• A product Backlog, estimated and prioritized by a “Product Owner” is used
• A “Release Plan” exists and is known by the team
• A “Company Strategy” exists and is known by the team
• Features are divided into “User Stories”
• The “User Stories” are estimated by the whole team using “Planning Poker”

Workflow

• The development work is divided into iterations or timeboxed “Sprints” or “Iterations”
• A “kanban” or “Information Radiator” is used
• The tasks are not assigned, the team organizes itself
• The “Velocity” of the team is known
• No outsider can interfere directly with the team during an iteration
• “Daily Meetings” take place and do not last more than 10 minutes
• A “Sprint Review” is organized and the output recorded
• A demonstration is held at the end of each iteration
• The problems are tracked and by the “Scrum Master” and/or management
• A proper Retrospective is held
• A “Burndown” graph is updated daily
• The “Code Reviews” are systematically organized

Development Tools & Rules

• A source controller is in place
• A continuous integration build server is used and testing (unit & guidelines) takes place at each commit
• The packaging of the product is fully automated
• A (simple) bug management tool is used
• Each bug is reproduced in a single test and then corrected
• 80% of the code is covered by automated testing
• A “Solution Log” in WIKI form is used
• The “Coding Guidelines” are defined and understood by all
• A maximum of 40 work hours per week!

Please note that any numbers above can be adjusted to your reality.