Recently I had the misfortune of overseeing a project that seemed it would be a big success-- but failed at the last minute. We had two talented developers, we accomplished all of our work just in the nick of time, and the work that was done looked very good.
Seems like a successful project no? The issue was that we didn't get paid for all the work we did. This made it unsuccessful from at least that point.
The root cause of the issue was my failure to "connect the dots". I told the customer we were adding another developer to the project in-order to get the work done in their time lines. I had warned them about that before hand as well. Since this was a Time & Material project this notification seemed sufficient to me. To me it was obvious, the customer disagreed.
When I used to write code, I always preferred to be explicit. That is, not rely on implicit casts or other operations. In this case, the increased cost was merely implicit in this case. Yes, they should have known, but I didn't mention it explicitly.
The lesson to learn out of all of this is that it is important to be explicit, and to connect the dots. This will leave no room for interpretation or mis-communication.
Tuesday, August 26, 2008
Friday, August 22, 2008
Agile Noir
For those of you familiar with Agile methodologies, you may find these humorous.
Agile Noir, a film adaptation, and their comic serial.
Agile Noir, a film adaptation, and their comic serial.
Wednesday, August 20, 2008
Agile Anti-Patterns - Part I
In this first of what I hope will be a series of posts about agile anti-patterns that I have either observed at Macadamian, or learned about when I attended the Agile 2008 conference during the first week of August. I am going to talk about the "Hierarchical Anti-Pattern". This is one of the most common anti-patterns I have seen, I have just never though about it before. This is something that I touched on briefly in my last post but am expanding here.
In the "Hierarchical Anti-Pattern" the lead in your team at your global centre does all the talking. In this anti-pattern the person with the most rank or seniority does the talking, not necessarily the person with the most knowledge. This is something that is very common cultures that are very hierarchical, and it is even more prevalent if you are using third party contractors as your offshore development or testing team.
The situation is worse with third party contractor teams as they are your customer! And you have a customer. That is a lot of levels of indirection! Since it is common that people don't want to pass bad news on (not us at Macadamian though right?!) they will be less forthcoming when their is bad news.
Of course we all know that we want the bad news as soon as possible so that we can react and hopefully address the issue.
You cannot allow this situation to develop on your distributed team, the lead in your offshore centre cannot cover for or protect someone on their teams. It will only breed resentment and hostility, and could obscure the true status of the project.
So what can you do?
One of the easiest ways to help prevent this anti-pattern by ensuring that everyone dials in from their desks for their daily scrums. This will help avoid the side conversations that are necessary for this particular anti-pattern.
You can also (and this one is hard and sort of goofy) have everyone stand at their desks while on the daily scrum call. This one is hard to enforce without web cameras but can also help prevent the side conversations via IM that are required for this anti-pattern. It also has a nice side benefit of preventing the team members from multi-tasking, or even reading /.!
During the actual scrum, you should be sure that everyone speaks for themselves, and that the person you ask the question of answers that question. Ask the question to who should be the subject matter expert, be polite but firm. This can also help expose team members that are coasting or not pulling their weight.
You should also work diligently to create the collaborative atmosphere where team members regardless of rank or seniority feel empowered to speak their minds, and voice their concerns. You can help foster this by asking the team what their thoughts are? What are their suggestions? What can they do to help? Don't isolate all the decision making power on shore.
It is very important to ask probing questions to get to the bottom of the status. Ask questions about the state of development, testing, how much effort is left, what if anything is blocking, how it will be implemented etc. This is related to your delegation technique, and is also extremely important when dealing with with anyone on your team regardless of where they work. Also keep in mind their seniority when validating their answers, sometimes juniors haven't thought their entire way through the problem, they can rely on their lead in these cases to help guide and mentor them.
Video conferences are good to help pick up the quiet guy sitting in the corner of the room. It will also help you see any confusion that might not be prevalent on just a voice call, and allows you to more easily build trust with them as you can see each other. Just don't let technology get in the way of the communication. Don't spend 20 minutes setting up for a 10 minute call. That is not efficient.
There are just a few easy ways to help prevent and correct this anti-pattern, does anyone else have other ideas?
In the "Hierarchical Anti-Pattern" the lead in your team at your global centre does all the talking. In this anti-pattern the person with the most rank or seniority does the talking, not necessarily the person with the most knowledge. This is something that is very common cultures that are very hierarchical, and it is even more prevalent if you are using third party contractors as your offshore development or testing team.
The situation is worse with third party contractor teams as they are your customer! And you have a customer. That is a lot of levels of indirection! Since it is common that people don't want to pass bad news on (not us at Macadamian though right?!) they will be less forthcoming when their is bad news.
Of course we all know that we want the bad news as soon as possible so that we can react and hopefully address the issue.
You cannot allow this situation to develop on your distributed team, the lead in your offshore centre cannot cover for or protect someone on their teams. It will only breed resentment and hostility, and could obscure the true status of the project.
So what can you do?
- Everyone dials in from their desks
- Everyone stands up during the call (you know, a stand up meeting)
- Everyone speaks for themselves
- Empower your team
- Ask probing questions
- Video conferences
One of the easiest ways to help prevent this anti-pattern by ensuring that everyone dials in from their desks for their daily scrums. This will help avoid the side conversations that are necessary for this particular anti-pattern.
You can also (and this one is hard and sort of goofy) have everyone stand at their desks while on the daily scrum call. This one is hard to enforce without web cameras but can also help prevent the side conversations via IM that are required for this anti-pattern. It also has a nice side benefit of preventing the team members from multi-tasking, or even reading /.!
During the actual scrum, you should be sure that everyone speaks for themselves, and that the person you ask the question of answers that question. Ask the question to who should be the subject matter expert, be polite but firm. This can also help expose team members that are coasting or not pulling their weight.
You should also work diligently to create the collaborative atmosphere where team members regardless of rank or seniority feel empowered to speak their minds, and voice their concerns. You can help foster this by asking the team what their thoughts are? What are their suggestions? What can they do to help? Don't isolate all the decision making power on shore.
It is very important to ask probing questions to get to the bottom of the status. Ask questions about the state of development, testing, how much effort is left, what if anything is blocking, how it will be implemented etc. This is related to your delegation technique, and is also extremely important when dealing with with anyone on your team regardless of where they work. Also keep in mind their seniority when validating their answers, sometimes juniors haven't thought their entire way through the problem, they can rely on their lead in these cases to help guide and mentor them.
Video conferences are good to help pick up the quiet guy sitting in the corner of the room. It will also help you see any confusion that might not be prevalent on just a voice call, and allows you to more easily build trust with them as you can see each other. Just don't let technology get in the way of the communication. Don't spend 20 minutes setting up for a 10 minute call. That is not efficient.
There are just a few easy ways to help prevent and correct this anti-pattern, does anyone else have other ideas?
Thursday, August 14, 2008
"OK" is not "OK"
We all know one of the most common causes of project failures in distributed development is poor communication. However, even with constant communication, wiki pages, Skype etc communication can still poor.
Actual language skills (word mastery and accent) and culture can still hamper smooth communication.
To help with the language skills, you can use a tool like Skype where you can talk and type. Sometimes accents and speed of talking can make it hard to understand, in this case you can fall back and use a combination of text and speech. Video conferencing or web cams can also help. Sometimes you see the confusion, but not hear it.
You should also avoid slang and pop culture references like the plague. This can be hard, after all it ingrained in our method of speech. I remember recently I used slang in a quick email I sent to someone with whom I have worked with for years. I said "she's down with that". Of course, I know it means she is happy to do that, he thought the opposite. :)
Culture is always the big elephant in the room. No one wants to address it for fear of being labeled a racist, bigot, or something. This is poppycock. It is vitally important to be aware of it so you know how to tailor your communications to help alleviate it.
For example, in English Canada when someone says OK it is often a short form for "yes I understand and will do it". This is not the same in India for example. Often, when someone on your team responds with "OK" from India it means that they heard it. They may not have understood it, and they may not have agreed to do it either.
You need to fall back on your delegation techniques. These techniques are useful for everyone regardless of where they live or work. After assigning a task or making a request, ensure the recipient understood by asking them questions about the task. You can ask them how long they think they will take, what strategy they will take to complete the task, confirm with them when it has to be done etc. The point of this is not to micro-manage, but to assess the level of understanding so you may act accordingly. Due to the timezone differences, misunderstandings can add a lot of time to your critical path.
Another common issue that is prevalent in some cultures is the deep seated hierarchy based on seniority. In agile teams, all the team members have to be empowered to take decisions, be able to ask questions to the team leader, the customer, or whomever. However, often what happens is that the senior person on the team fronts for the rest of the team. You can tell this is happening because you never hear from the rest of the team on conference calls.
You can help alleviate this by:
Actual language skills (word mastery and accent) and culture can still hamper smooth communication.
To help with the language skills, you can use a tool like Skype where you can talk and type. Sometimes accents and speed of talking can make it hard to understand, in this case you can fall back and use a combination of text and speech. Video conferencing or web cams can also help. Sometimes you see the confusion, but not hear it.
You should also avoid slang and pop culture references like the plague. This can be hard, after all it ingrained in our method of speech. I remember recently I used slang in a quick email I sent to someone with whom I have worked with for years. I said "she's down with that". Of course, I know it means she is happy to do that, he thought the opposite. :)
Culture is always the big elephant in the room. No one wants to address it for fear of being labeled a racist, bigot, or something. This is poppycock. It is vitally important to be aware of it so you know how to tailor your communications to help alleviate it.
For example, in English Canada when someone says OK it is often a short form for "yes I understand and will do it". This is not the same in India for example. Often, when someone on your team responds with "OK" from India it means that they heard it. They may not have understood it, and they may not have agreed to do it either.
You need to fall back on your delegation techniques. These techniques are useful for everyone regardless of where they live or work. After assigning a task or making a request, ensure the recipient understood by asking them questions about the task. You can ask them how long they think they will take, what strategy they will take to complete the task, confirm with them when it has to be done etc. The point of this is not to micro-manage, but to assess the level of understanding so you may act accordingly. Due to the timezone differences, misunderstandings can add a lot of time to your critical path.
Another common issue that is prevalent in some cultures is the deep seated hierarchy based on seniority. In agile teams, all the team members have to be empowered to take decisions, be able to ask questions to the team leader, the customer, or whomever. However, often what happens is that the senior person on the team fronts for the rest of the team. You can tell this is happening because you never hear from the rest of the team on conference calls.
You can help alleviate this by:
- having everyone dial in from their desks, this will help reduce the side conversations that are necessary in this arrangement;
- you must also emphasis that you want active feedback from the entire team, you will need to keep emphasizing this and working on it over the course of several months. You can help reinforce this by explicitly asking questions to the full team;
- video conferencing can also help for those group meetings, it will allow you to see the quiet ones and "pick" on them to contribute.
Friday, August 8, 2008
Agile 2008 - Part V
Today was the last day of the conference. The morning session I went to was titled "Beyond Agile! Product Innovation Debate: What and who drives innovation?"
It was an interesting and lively debate between the panelists and the audience. The attendance was low (likely due to it being Friday and people flying home) and this allowed a lot of audience participation.
I came up with many nuggets out of this session which will make an article itself, but I will mention the two key issues with innovation and agile that at least some of the panelists argued and I agreed with:
It was an interesting and lively debate between the panelists and the audience. The attendance was low (likely due to it being Friday and people flying home) and this allowed a lot of audience participation.
I came up with many nuggets out of this session which will make an article itself, but I will mention the two key issues with innovation and agile that at least some of the panelists argued and I agreed with:
- Agile can produce products that are consistently mediocre
- Agile relies too much on participatory design
Thursday, August 7, 2008
Agile 2008 - Part IV
Thursday was an interesting day. I attended seminars on Continuous Integration and some experience reports on the good and bad of offshore development.
The 100 days of CI was an experience report from a development manager at Microsoft in the Tools and Patterns division. Based on their experience, they learned that they had a 40% savings in time in fixing the broken builds over their old process.
The speaker also talked about the following best practices:
The 100 days of CI was an experience report from a development manager at Microsoft in the Tools and Patterns division. Based on their experience, they learned that they had a 40% savings in time in fixing the broken builds over their old process.
The speaker also talked about the following best practices:
- Over spec your CI machine, nothing worse then having down time due to insufficient disk space or resources;
- Add additional daily or nightly build times. After all, what is the nightly build here is not the nightly build in India;
- Capture the data, your CI machine allows you to capture lots of metrics, so do it;
- Warnings are errors. Integrate your static analysis tools into the build. Treat their warnings as errors;
- Don't check in then go home, you may have broken the build;
- You break the build, you fix it.
Wednesday, August 6, 2008
Agile 2008 - Part III
So today marks my third day at the conference, and I have been keep pretty busy meeting people and talking agile.
Today's discussions revolved around trouble shooting distributed agile, agile patterns, and success stories with distributed agile.
I also was able to discuss patterns with Keith Braithwaite the author of several papers on distributed XP. You can read the PDFs here and here.
The success stories about distributed agile was also pretty interesting. The first presentation was a joint presentation between a company and the co-inventor of scrum. They had some metrics up that showed how they were able to achieve the mythical "hyper-productive" team. A "hyper-productive" team is defined as a team that has achieved a state of ownership, collaboration, and commitment that allows them to be much more productive in creating value on a consistent basis.
Another interesting metric they had was their 0.5-1.0 defects per thousand lines of code! That is incredible. They defined defects as issues raised during acceptance. They were able to achieve this by creating an impressive suite of unit tests, and automated integration and acceptance tests while still keeping their velocity of over 15 function points per person per month.
One of the other presenters was a small company called Code71. They are a small boutique global IT solutions and services company. They are using a model that is very similar to ours. Their remote office is in Bangladesh.
It is interesting to realize that Macadamian was doing distributed agile way ahead of the curve. When we first started experimenting with this back in 2003, the prevailing school of thought was that this couldn't be done. It is a good thing we didn't realize this :)
Today's discussions revolved around trouble shooting distributed agile, agile patterns, and success stories with distributed agile.
I also was able to discuss patterns with Keith Braithwaite the author of several papers on distributed XP. You can read the PDFs here and here.
The success stories about distributed agile was also pretty interesting. The first presentation was a joint presentation between a company and the co-inventor of scrum. They had some metrics up that showed how they were able to achieve the mythical "hyper-productive" team. A "hyper-productive" team is defined as a team that has achieved a state of ownership, collaboration, and commitment that allows them to be much more productive in creating value on a consistent basis.
Another interesting metric they had was their 0.5-1.0 defects per thousand lines of code! That is incredible. They defined defects as issues raised during acceptance. They were able to achieve this by creating an impressive suite of unit tests, and automated integration and acceptance tests while still keeping their velocity of over 15 function points per person per month.
One of the other presenters was a small company called Code71. They are a small boutique global IT solutions and services company. They are using a model that is very similar to ours. Their remote office is in Bangladesh.
It is interesting to realize that Macadamian was doing distributed agile way ahead of the curve. When we first started experimenting with this back in 2003, the prevailing school of thought was that this couldn't be done. It is a good thing we didn't realize this :)
Tuesday, August 5, 2008
Agile 2008 - Part II
Well, I have survived day 1 of the conference. It is a pretty long day here with the presentations starting at 08:30 hrs and ending at 17:30 hours. Of course we get some breaks :)
In the interesting facts column, there are over 1548 attendees from 42 different countries. 42. I wonder if there is some significance to that? :) Also, 22% of all the attendees are from outside of North America. I would say the US makes up the largest segment of attendees. I have run into more Americans then Canadians so far.
In the seminars I have been in, I would have to say that Macadamian is very advanced in our distributed agileness. So far the majority of people I have talked to do distributed agile on shore, that being that they have teams in different parts of the country. Some do do distributed agile across multiple global centres.
Also, many of the patterns that Macadamian holds dear about how to do distributed global agile are being validated by the people I meet and the seminars I attend.
The one universal shortcoming I have identified so far is our lack of travel. At Macadamian we follow the Ambassador pattern. See I learned the name for what do here :) This pattern is where someone from one of the labs travel to another one of the labs to work there for a few weeks. Where we fall short is the frequency of this travel.
Ideally we should have an ambassador travel to one of the labs (or to our HQ) for the start of every significant project. This isn't something we are doing current. In this model, the travel time could be one or two weeks instead of our standard three weeks.
Basically, the premise of this model is to either pay the cost of the face to face time now, or later in the project with lost productivity, rework etc. I think it would be interesting to examine the possibility of this approach on some of our longer/bigger projects. The impact of this of course is to price this ambassador model into the total cost of the projects.
In the interesting facts column, there are over 1548 attendees from 42 different countries. 42. I wonder if there is some significance to that? :) Also, 22% of all the attendees are from outside of North America. I would say the US makes up the largest segment of attendees. I have run into more Americans then Canadians so far.
In the seminars I have been in, I would have to say that Macadamian is very advanced in our distributed agileness. So far the majority of people I have talked to do distributed agile on shore, that being that they have teams in different parts of the country. Some do do distributed agile across multiple global centres.
Also, many of the patterns that Macadamian holds dear about how to do distributed global agile are being validated by the people I meet and the seminars I attend.
The one universal shortcoming I have identified so far is our lack of travel. At Macadamian we follow the Ambassador pattern. See I learned the name for what do here :) This pattern is where someone from one of the labs travel to another one of the labs to work there for a few weeks. Where we fall short is the frequency of this travel.
Ideally we should have an ambassador travel to one of the labs (or to our HQ) for the start of every significant project. This isn't something we are doing current. In this model, the travel time could be one or two weeks instead of our standard three weeks.
Basically, the premise of this model is to either pay the cost of the face to face time now, or later in the project with lost productivity, rework etc. I think it would be interesting to examine the possibility of this approach on some of our longer/bigger projects. The impact of this of course is to price this ambassador model into the total cost of the projects.
Monday, August 4, 2008
Agile 2008 - Part I
I have flown into Toronto for the week. I am attending the Agile2008 conference. The conference looks pretty darn good. The main topics I am looking at attending are Distributed Agile and Leadership and Teams.
Shameless plug for Porter airlines, the flight was only an hour, but they served food and alcohol. Sweet!
The hotel seems good, but the rooms are quite small. As you can see from this photo, I practically had to stand in the hallway to get this shot.
Shameless plug for Porter airlines, the flight was only an hour, but they served food and alcohol. Sweet!
The hotel seems good, but the rooms are quite small. As you can see from this photo, I practically had to stand in the hallway to get this shot.
Subscribe to:
Posts (Atom)
