Sorry for the delay..

Im sure you all wonder why I didn’t write anything about Agile 2010 yet. Ok let me explain.. About Agile 2010..I don’t know where to start and where to end it .. Sometimes I can think of writing a post about each lecture I attended to. Or something only about our session there...But at the same time its going to be lots of writing.. So for now.. let me write something.., I got to write something this week.. Otherwise it will never happen as the next quarter is really getting hectic.
We have 2 “Agile in Offshore” events planned in Stavanger and Oslo in September.. .. then I may miss presenting at PMI SAARC conference.. That’s overlapping with my Oslo visit.. then I will do P2P 2010 Cairo most probably in December.. So that’s more than enough for this year I suppose.. Yeah all these top of our day to day work on business development and projects.. So no need to explain how hectic the life is .. But I enjoy every bit of work we do.

PMICC Magazine - request for articles.

PMI CC wishes to announce that four ‘quarterly magazine’ are to be published from the chapter each year. The first publication, Q3 2010, is expected to be launched during the PM SAARC Conference that is being held in Colombo during September this year.

The scope of the magazine will be the delivery of content rich articles and real-life stories about Project management in all disciplines from the PM community to the PM community in Sri Lanka. While the initial efforts are targeted purely at widening our user base to encompass other industries, the goal is also, to provide PMP’s with opportunities for PDU accumulation and critically evaluating the projects they run and sharing it, if it can be shared, with a wider audience.

PMI CC requests all recommended articles to be submitted to the editor@pmicolombo.org.

What will KANBAN bring in to your offshore projects?

During last couple of years we have been talking a lot about agile as a whole and specifically about SCRUM, and how that help in offshore project environment to remove most the challenges introduced by the traditional waterfall environment.

While we were talking a lot about agile project concepts, engineering also has evolved a lot to support these concepts such as improved continuous integration and automated test process which eliminate most the problems of multiple team work integration and iterative releases, Cruise control's webpage which really help to get one good picture about all what's happening in multiple sites, New tools such as TFS, VS2010, and some opensource tools are also in high demand nowadays.

So obviously, We are on right track... agile is a way to go in off-shoring..the fact may hurt some of our offshore waterfall folks, but that's how it is.. one can argue that most the agile methods are good for collocated teams due to its concepts such as white board discussions, frequent meetups , open culture, transparency etc. .
After working with large offshore teams in India, Martin Fowler said "working offshore agile feel the pain much more than those using plan-driven approaches. But it's still less pain than the plan-driven methods themselves!" He said it best !

Agile is full of arguments......:-)You know that if you are a member of yahoo "Scrumdevelopment" group ;-). The latest arguments in agile world are mostly based on KANBAN.
If I explain simply, Kanban is a very lean approach to software project development. In SCRUM we said "we cut the waste". In Kanban we cut them big time. We see some agilists moving rapidly in to Kanban, but some are little conscious about the benefit it can bring in. Jeff Patton said in his blog "I'm seeing agile people behave as strangely about Kanban as traditional process folks behaved about Agile." Having said that, lets look at what Kanban will bring to all of us who are in the offshore project context. I will discuss few points here.

1. Scrum is all about time alerts – Kanban is all about event alerts.

In offshore/ distributed team context , the biggest challenge we have is to eliminate the isolation, get team members work closely with the remote teams, still have the onshore team commitment to meet up with the remote teams frequently even when they are distributed. SCRUM comes handy in this as it brings disciplines such as specific sprint planning meeting at the beginning of each sprint, daily scrum meetings (even via remote communication facilities) in every 24 hours, and retrospective after every sprint. So almost all are committed to participate these events.
But Kanban has more of a loosen up approach to it. Simply there is no time box approach, no sprint planning. They fix a limit for WIP stories. Kanban uses push and pull theory, when the WIP items becomes lesser they pull from the backlog and fill the stack.

kanban folks argue..why having daily meetings..? just raise your hand when you feel you are not in sync with your team.. lets meet up.. Why do you have to meet up daily and talk about what you have done yesterday what you will do today like a prayer. ..?
But we know in offshore context, this is not going to workout.. it will lead team mates to think.. ok .. Im having this issue.. but I may ask it later.. who knows whether my onshore mate is busy right now.. may be he is at another meeting.. this guy will pass hours, days…. And there are lots of unspoken issues stack up with the offshore guy to ask the onshore guy when the time is right..
from onshore perspective.. again we are inviting the same old problem.. lets just send him an email..or this guy keeps waiting without asking questions…At last all these tiny issues will become a big issue to the project.
About the retrospective, now we know we need to have a retrospective by end of 10 day sprint or so. But with Kanban, its again an event based thing.. if you see that you had a serious issue when testing, call the team and have a retrospective, why you need to wait till end of 10 days to have it.. hmmm..
However, most Kanban practitioners accept that this doesn't work so well even with collocated teams.. So they are also moving towards having daily meetings to talk about the bottlenecks and what they do today in front of the Kanban story display. Not based on the sprint plan.

2. Comparatively larger user stories.

When it comes to offshore – onshore engagements, requirement understanding is more challenging.. smaller user stories make the requirements more clearer and easier to elaborate upfront. But in the same time, the larger stories also has its own benefits such as easier designing, planning and to keep the product backlog in shape. But I would advise the teams to go for smaller user stories simply because that eliminates many risks in requirements especially with the challenges in distant communication.

3. Do not estimate – or at least pretend you don't estimate :-)

How will it work? Yes it can work in the perfect world. you are going to run 100 m., you have no idea how long you will take to run.. but you will run as fast as you can. In scrum what happens is that .. you run for 10 min and see how long you could run with your maximum speed. It's a time box. Dont raise your eyes.. Projects without estimations happen in real world too. I have an example with one of our current projects at Exilesoft. The team work with this model with a very close work relationship with its onshore team in Norway. It works very well with the trust they have built with our team sitting in Sri Lanka for over an year now. But this needs very capable resources, so much trust on remote teams and lots of commitment from the customer to work with its distributed teams. Without that, this will result major issues and pain in business.

4. Burn-down charts – do we really need them?

Kanban practitioners argue about the velocity used in many other agile methods such as scrum. Velocity measured based on story points burn down rates and sprint deliveries can lead to some conflicting ideas among the stakeholders as well as within the members of the same team. So they say.. Concentrate on cycle time of a story. that's what matters.

How do they do that.. its simple. Its about noting down the entry time of the Story X, and done time of the Story X. this difference will show you the waiting and the production time of a story in the queue. What needs to be done is to reduce this cycle time as the team improves with the technology and skills by removing the bottlenecks.

What I see with burn-down charts is that burn down charts with some meaningful annotations has a real good advantage in remote team environments to communicate the progress of the current work sprint as well as overall as a product how we go with the development. It provides high degree of transparency.

Overall I see Kanban will work well with some of the current maintenance projects we have. Working on a unplanned backlog, limiting WIP number, monitoring cycle time and less focus on estimation will work well with these projects.

However, I see that Kanban together with some scrum and XP disciplines will also be a good combination. Its all about trying out these methods in offshore environment and seen the benefits, drawbacks and improving your offshore-agile practices.

No.. Im not saying that agile is the magic pill which will flush out all the problems in offshore software development. That's what Dave and I are going to discuss at Agile 2o1o on 12^th August (large scale and distributed agile. )
Our topic is simple and straight "Why you suck at off- shoring even with agile " see you guys there and lets have an interesting discussion.

Where you mostly go wrong with SCRUM

By seen over few years for teams practicing SCRUM in various projects, I’ve noticed few common mistakes some teams do. I thought to spend few minutes to make a quick post; because they may help you too.

1. Too quick in Product Backlog planning
Seen this problem over and over again. In some of the projects you need few rounds of PB pre planning, be ready with stories, wire frames, UI flows , sometimes even the domain models. But there are many times those Product owners and teams rush in to PB estimates without having what’s needed to have.

2. No common understanding about the meaning of “Story points”
What does the story points really mean to you and your team members? ask each member of your team individually and you will be surprised.

3. Talking vertical, Thinking horizontal
This is very common with people who fall from waterfall to agile. Define a sprint called 0 and do all design upfront?

4. No release plan
Where is your release plan to the customer? Do you do a release after 1 sprint? 2 sprints? How many scrum teams do upfront release planning I wonder…

5. Sprints in different time durations.
If you have 10 days sprints.. go for 10 days sprints.. I cant still understand when I hear teams telling last sprint we had for 10 days.. but this sprint we will do 30 days.. then how do you ever calculate the velocity of your team and predictions for future sprint burn rates? This is why I need a release plan separately.

6. Getting wires mixed up about what testing means in agile teams
Ive seen this situation.. can you ever think of a scrum team where developers stop work and wait till the tester test their software within the sprint..? if you have more testing time, the team should do testing instead waiting.

7. No feedback taken after the customer testing those iterative releases.
You keep on releasing.. But if there is no one in the other end, who will test your iterative working software releases and give you a feedback, then there is no meaning to the iterative releases.. because you are anyway not too sure whether you comply with your customer requirements or still developing your own fantasies.

8. Scrum master role
Google and learn..

9. Misreading the burn -down..
What does burn down really mean to you? Take a good look at it.. again ask the question from all your team members.

10. Not using the Engineering principles to align development with SCRUM
Engineering has evolved a long way to adapt to agile way of developing applications, many test tools, code quality tools, tools which helps continuous integrations and lots of wiki tools are out there. Do you take the real use of them?

PMI Colombo Chapter - May 2010 Event

Agile in Offshore- Oslo gathering (Meet-up)

It was on 20th April (Last week) at Scotsman pub, Oslo. I was so happy to be there. It was not a typical business people discussion.. It was all about meeting other agile practitioners who use agile in Outsource/Offshore context and sharing ideas, challenges in such context as an open space discussion ( Though there was no much space as the room got filled in no time). Hosting this meet-up group was a new experience to all of us at Exilesoft

The event started around 5 pm with more or less 25 participants who really experience agile way of working in their day to day offshore projects. The best of all is that there were onshore members dealing with their offshore teams in Romania, Spain, Russia, Ukraine, India and much other offshoring destinations. We were the only offshore company who was there specially to share our ideas from offshore perspectives with onshore practitioners. I think it helped onshore team members to rethink about the issues in a different angle.

Finn, the host of the group started the event by explaining the objective of “ Agile in Offshore” meet up group, and some insights to Exilesoft. I had to play more or less a facilitator/moderator role to keep the discussions going..To have a kick start, I used a real case study to explain why we moved to agile way of working in offshore projects by leaving heavy processes aside.. When finishing 2 slides.., here comes Pizza. It was kind a treat after a long workday as we all were hungry.. :-)


I started the discussions with few prioritized issues we face in offshore projects when using agile, the very first was the challenges when it comes to project initiation with an onshore customer who is not in to agile. In the same time if the onshore customer is in to agile and not the offshore team, how this conversion happens when you are not too sure that other foreign company, it's culture and management structure is ready for agile ..? I soon opened the discussions to the audience as I couldn’t wait anymore standing in front without grabbing a Pizza for myself.. ;-).

That was a cool debate.. When we felt we have discussed a point to an extend, in agreement we moved to the next point.. Likewise we discussed and debated about many concerns from onshore as well as from offshore perspective such as the challenges in highly integrated scrum models, Scrum master role in integrated teams, Isolated scrum team models, Product owner and use of Proxies , how effective is the use of offshore PO proxies, culture issues , language issues when it comes to casual communication, the extend of actual usage of the collaborative tools in such context etc.

It was very nice that 3 other Exile colleagues Buddhima, Shiran and Adipa who were in Oslo also joined the event, they were good contributors to various practical issues we discussed on engineering , and source controlling in distributed environments.

Ofcourse the event was time boxed. :-) In 2 hours we had to end the event, Still we received lots of comments from some of the participants who waited little longer. It was a great experience and there were many requests to continue this group. Currently there are 61 members there, so that now we put our thoughts together on how to progress with the group with some new ideas for the upcoming events.

Do you like plain Vanilla SCRUM or Flavored :) ??

This cartoon by Mike Vidoz made me write this post. ( Im a fan of his SCRUM toons :)-But I wish if he has new cartoons coming up more often ;-) ) And if you want to know which SCRUM I like, I like strawberry toping SCRUM. :) yummieee..

Plain Vanilla SCRUM is the SCRUM we all learned.. Simple, Nice, appetizing.. and I loved it more than anything I have ever learned about project management due to its simplicity and the way of getting away from Micro Management and Command and control management which sucks in my words. I think that’s why most skilled people got really attracted to SCRUM.
However when we put it in to practice, we learned a lot. SCRUM as it is … Is it enough? No I don’t think so. Mainly because SCRUM is only a PM framework , still even with some missing pieces , It address the fact that how teams should work in order to deliver results more effectively by cutting many unwanted stuff on the way. But when you do it in practice, you need to think about agile project initiation, Risk handing (SCRUM reduces project risks to a greater degree..but it’s hard to believe that SCRUM itself reduces all the risks involved in a project), transparency to higher management who is responsible at last to the customer and specially about addressing the engineering principles needed to be taken from XP or from any other agile method.
Recently I saw a good blog post written by Jesse Frewel in his blog about complains on initial version of SCRUM and the modifications which have happened. I see may people in the industry add many features to SCRUM after they start practicing it for a while.

I read another awesome article by Martin Fowler and he wrote about “Semantic Diffusion” happening to agile, He has a bliki and not a wiki .. You can find it here.. http://martinfowler.com/bliki/SemanticDiffusion.html Its worth reading.. !

Only thing what you got to be careful is, no matter whatever the customization you do or add new things to SCRUM framework , you got to understand that the key is not losing the agile concepts. If your new flavors added to Plain Vanilla SCRUM kills the agile concepts, then it will not deliver the expected value of practicing SCRUM. So be careful when you add things over it .. Make sure it gives you the right flavor :)

Help me : Bugs per 1000 line of code .. Agile dev aproach vs Traditional development aproach ??

I have come across some papers for same projects done based on traditional approach and Agile approach, which proves that Agile approaches have delivered significant better results. Some are from Starlabs SCRUM papers.

Im in the process of customising an Agile framework and curious about following.

Have you come across in any comparisons that the bugs per lines of code based on traditional software development vs agile development especially when test focused and test driven approaches are used. ?
Yeah I understand the complexity of the comparison based on iterative deliveries, but what Im looking at is the accumulated picture over the iterative deliveries throughout the project compared to the test results of the same project which is done with traditional approaches.
What I need to know is whether there is a significant difference in test results as we see many points that it should be..
Appreciate your help on this ..!

PS. thank you so much Buddhima sending me this
http://video.google.com/videoplay?docid=-3054974855576235846&hl=en#

Its great. Thats About google techtalks - Agile testing.. I enjoy that so much..!

Offshore Project management - Interview with Dave Prior

Click to play

Do we blame SCRUM for that too :).?

Scrum Is a project Management Framework. That’s why it doesn’t talk about any technical disciplines or engineering principles. Look at other widely used methodologies for project management such as PMBOK, PRINCE2 or even KANBAN; they don’t talk about any engineering principles either,
But Ive not heard anyone blaming PMBOK because it doesn’t talk about technical practice in software. May be its so clear that PMBOK is meant to use for project management across industries.
But how about scrum then?. I think compared to PMBOK and some other PM methodologies; SCRUM is very less prescriptive and highly adaptive. Due to this simplicity there were so much of confusion in the industry from day one about SCRUM especially from the people who misunderstood RUP as a Project Management process and people who used XP over time with its own technical guidelines.
Just like PMBOK doesn’t tell you not to do automate testing or not to do Pair programming, or domain model design, SCRUM doesn’t stop you doing any of these things. Especially if you are in iterative shippable product increments, using automated testing makes the whole testing tasks more effective.
So it’s quite clear that you need to adapt to your engineering best practices when you use scrum just like when you use PMBOK. But the difference here is that if your engineering principles which you try to adopt to, kill the agile values, you will be having a label of SCRUM but you will never get the real value of SCRUM.
So its important to adopt with simply, “doing everything every time” by revisiting your high level design diagrams etc at every sprint planning. Especially when it comes to larger number of small teams working on same product, you really need to get your act together on how you adopt with proper engineering principles and ownership of them but still doing it “Agile”.
Another mostly misunderstood area is documentation. It’s because Scrum says to be focused on software delivery. If we develop software, our delivery is software, not any other artifacts. Those artifacts should help building software but not a focused delivery under normal circumstances.
But if you have read Mike Cohn’s user stories applied book (really good book), you can find the answer to your problem. If the CEO thinks you need to provide such documentation to protect your IP value of the product, then you can add the main user as the CEO and write the complete user story on what sort of documentation he wants and what is the expectation out of it . so you have tasks in your sprint related to the documentation user story.. Its all about doing what is wanted and not wasting..
The bottom line is that no method is god given or no method is evil. So its all about using your experience and common sence to make something which works in your context.

Risk Management – where it fits in Scrum?

This is about Risk. There are visible and invisible risks in any software project and those risks may appear any time during the project life. PMBOK has a separate knowledge area on risk management. YES it’s that important!
So ..Then why most the SCRUM practitioners are so silent about risk management ( Ok we Agilists think the word “management” is evil ;-) So I will use the word “risk handling”). I think risk handling is one of the most unspoken areas in agile processes.

To me, handling risks of projects and bringing it to visibility of the stakeholders is very important.. Yes..early as much as possible…. If I have 7 Scrum projects happening at this time at Exilesoft, being the Project Director, how do I get this visibility of the risks of all the projects? One challenge of running many scrum projects in my context is that most the time the project knowledge lies within the teams and the POs..But still there can be areas which higher management needs active involvement to avoid various risks and mitigate them. So visibility of this information is still important to the project organization of the company.

I was thinking a way to bring the risks handling in to practice in scrum projects more effectively.. But still not hurting the agile principles and concepts.

I just went back to my pre-Agile age to see how we handled project risks. In the planning stage, we had a risks plan, initially, we used to foresee many risks as much as possible, we had a fairly complicated template defined by the PMO, the project manager mainly listed all the risks (of course it was PMs responsibility) and then he discussed with the team and other stakeholders ( I suppose I did ;-) ) and assigned a figure for the impact and probability. Then we calculated the severity based on the calculation impact * probability. Thereafter we assigned a risk owner to each risk, and the response options, either we are to mitigate it, if mitigate the mitigation plan, Risk deferral, or agreed to transfer risks or accept or avoid.
After doing all these, we were so happy that we had a nice risk plan for the project, sent to all the stakeholders and then some times we forgot about those risks plans when project was too hectic towards deadlines.. or sometimes being PMs we had unique effort on risks controlling and monitoring process. However it was always the Project manager’s baby and if he didn’t foresee the risks of the project, his job was at a risk. :)

Ok.. Now I have a different situation. How do I do this risk handling in Scrum projects? Who takes the responsibility of such risks handling of scrum projects? How do I get this visibility of all the risks happening in my company projects easily?

I don’t want each team scrum masters to create risks plans and get them updated and email to me, to my CEO and other stakeholders every time. Because I know it will never get the attention which it’s needed and there will be lots of “I wish this stuff is deleted” areas in those reports. Further, that will add lots unproductive stuff in to working software focused production which we may not want to have. Top of that how can the scrum master be responsible to foresee all the risks which may happen in the project.. he is just a human being.. shouldn’t there be a collective effort and responsibility ?

So how do we do this better? I thought of this solution.. Im going to tryout and see whether this will really help us. I think so ..

In scrum, we need the ideas of whole team and we need them to think , work together and have the same commitment and ownership. So why not those all getting involved in handling and reporting risks to each other in more visible way? Not only them identifying and reporting the risks, they need to be actively involved in responding to these risks too. Let’s make it an effective process.

Remember the sprint dashboards with sticky notes..That makes your sprint tasks and progress visible to everyone. Even to an outsider who just walks in to your development room.

I thought of giving each team 3 colors of sticky notes sets Red, Amber and Green. Each project team gets a small white board on the wall. Whenever a team member see something as a risk in his project, he needs to write it in either Red ( he thinks that’s serious and need some immediate attention) or Amber ( Not that serious) or any positive risks in Green ( not compulsory) and he paste it on the risk board under the New risks column. They can be technology risks, requirement risks, risks with commitments, or anything…) this risks board will have 4 columns

So I’m sure one problem is already solved.. When I walk in to the development area, I can see the risks notes in all projects and we can see definitely the red ones needed attention. So its important for me to have some discussions with teams about these red notes or amber notes.
How do we use them?
I think each sticky note can have a space in the bottom left corner for the impact and the right corner for the probability. The team can rate the impact and the probability of each sticky note.

In each sprint planning meeting, its needed to take these foreseen risks to discussion with the product owner, prioritize them, if they need any mitigation plans to add them as product backlog items, prioritize them based on severity, taken in to sprints and address them.

Ex: One of the developers (Tom) seen a risk. He thinks using control X may affect the end product performance and users will not agree to use that product feature.
According to Tom, it’s a serious risk so he will not wait for few days to inform this risk to the team, because with time he knows that he may forget this with his other priorities. Therefore, he will write this risk in a Red color sticky note , paste it on the risk board under new risks and he will get going with his committed work.
Next day after the daily scrum the team and the scrum master notice there is a new sticky note on the board, they will rate the sticky note for impact and probability.
In the next sprint planning meeting , they meet the product owner , so ideal time for them to discuss about these newly seen risks with him as he has the total ownership of the product.
Product owner agrees that this is a serious risk and he will have a new backlog item about the performance of the product feature, he prioritize it in highest priority as it may affect the other areas too in the product. So the team will address it in the immediate sprint and implement some caching mechanism to mitigate the performance risk.

This is only one example. Likewise there will be risks which they will have to discuss with the product owner, their own management or even only with the team .
When they are working on certain risks notes they can move them to the in progress column and when mitigated they can move them to the responded column. If the team and the PO decide accept them and not to do anything about that or ignore them completely due to lesser impact, they can move the notes to the 4th column.

In this way I can see lots of benefits which will bring to all of us;

1. Visibility and awareness of project risks seen in all our projects in much simpler way
2. No documentations and complicated templates which will save our time
3. All the team members will share the responsibility of Risk handling process
4. Risks items will be discussed and addressed with no delays and without any missing items.

Seasons Greetings from Projectized !!

I wish a Happy and prosperous 2010 to all my readers and advertising sponsors. Thank you so much for your support during 2009. In 2010, I wish to have more knowledge sharing, Interesting discussions and more than anything else to link up with you more closely... no matter who you are or which part of the world you are from…

Offshore project management and use of Agile. – Part 2 – Tiers of Outsourcing

The part 1 of this article has already received industry attention than I have expected. I’ve seen it has been referred in some discussions, forums and even in twitter and FB many times. Now it has been published in ICPM where it meant to be.

This is the 2nd article of the series. In this article I’m going to discuss the tiers of outsourcing.


When you initiate an outsourced project as the outsourcee, or when making the decision to outsource a project as the outsourcer it’s very important to understand which tier of outsourcing you are in to. This will give you some intelligence in advance about these extra issues you may face in outsourced projects compared to collocated projects. I can think of many dimensions of outsourcing when I define the tiers..
But following categorization based on geography – distance and time zones simply help me to understand many common positive and negative risks of such projects in each context.





'Outsourcing is outsourcing' either you outsource the project to your next door software company or to a company in the other side of the globe. Because in either case you need to manage external contracts, requirements, risks, security and knowledge transferring. However as I have shown in this diagram, the challenges in outsource project management increases when we move up in the tires mainly due to the communication issues and secondly due to cultural issues which I will be discussing in some of the future articles.

First, lets look at the bottom tier. The main advantage of outsourcing to a company with less travel distance is that it could facilitate more of face to face discussions whenever required. This will cut off a big portion of distant communication risks. The other point is that having same language speaking people working for you may provide you the luxury of using your native language in business discussions. Mostly the business and personal cultures will not have much difference with both the company professionals who work together for the projects and that will result much quicker relationship building among project teams. However this tier of outsourcing mostly delivers only the benefits described in the 1st and 2nd points which I discussed in the 1st part of this article.

Nearsourcing , the 2nd tier of outsourcing is more commonly seen among Western and Eastern Europe countries. Countries such as Poland, the Czech Republic, Slovakia and Hungary are stabilizing as software outsourcing destinations for Western Europe markets. As I see the software businesses attracts near sourcing mainly due to reducing the risks of cultural difficulties, legalization issues for onsite work and contractual/ financial terms. Further they benefit with minimized time zone differences. But if someone think Nearsorcing is the solution to avoid all the critical risk factors of outsourcing, it’s a big myth. Sometimes I see Nearsourcing bring more communication problems to the table.
Imagine a company in Norway outsource a project to a development company in Greece. I don’t see many Norwegions fluent in Greek or Many Greeks speak Norwegion. Neither parties don’t use English as their main business language. So these two teams trying to use English as a common language for communication can deliver more risks in Nearsouring than a Norwegion team communicate with a team in South East Asia where English is the main business language to do day to day work.
Nearsorcing seems very attractive for some of the industries such as manufacturing. If you look at the cost factor, Nearsorcing can bring you cost saving specially when it comes to manufacturing simply due to less transportation costs of goods. Hefty ocean fuel surcharges are involved when transportation happens from China to USA compared to Nearsorcing operation from Mexico to USA.
However based on available options in the global outsourcing market its still an argument to decide how much benefit Nearsorucing can bring in to software business which is totally different from manufacturing especially with relatively high labor costs of software professionals of Eastern Europe countries compared to most the SEA countries.

The third tier is what I’m experiencing right now with our current business at Exilesoft development in Sri Lanka and customers located in Norway. The same experience I have had for many years with some companies located in Australia, UK, Germany, Greece and New Zealand. Teams falling to this tier may face almost all the challenges in outsource business but still there is overlapping business hours within the same day where distributed teams can use for collaboration.
By looking at most the SEA software engagements with western countries, its proven that If well managed and well modeled, this tier delivers most the benefits of outsourcing business for the outsourcer as well as the outsourcee due to many reasons. The only difference in the top most tier compared to this tier is that, distributed teams in outsourcing business who are falling to the top most tier has no overlapping business time for collaboration. This increases risk of communication and becomes quite difficult to practice some of the agile methods which need closer and casual communication for projects specially the “Daily scrum” in scrum teams. There are alternatives we may use in such context (But not the Scrum mail :) period!!!) which we will be discussing in the future.

I have used Waterfall and Agile management concepts on such outsourcing projects in almost all these tiers. Compared to all the frameworks and models I have used, I find agile management concepts help to reduce the risks of outsourcing software projects drastically if used wisely.

In the 3rd part of this article we will have a closer look at dealing with culture differences in the project management falling to 3rd and 4th tiers of outsourcing and in the 4th part onward we will have a detailed discussion on other common difficulties and risks we face in outsourcing compared to collocated development while discussing how Agile can be used in each case to reduce the risks by taking Scrum as an example.

Kanban , Scrum, waterfall.. XP ?????. Nope… its time to have fun !!!!

Exilesoft Celebrates another successful year.. !!! We have been scrumming a lot this year !! :-) and now its time to have fun!!

PMI Colombo Chapter Event - November.

Offshore project management and use of Agile. – Part 1

Its again Winter in North.. So we are busy here at Exilesoft, Sri Lanka with most the customers who visit us. That's one nice thing in offshore business, as much as we enjoy travelling Europe, it seems our customers have found a second home to come when the winter starts in their countries. This is an ideal time we get to work together again as collocated teams. For them its quite exiting to work with us as well as to extend their business trip for one week or so to have little relax time in this exotic Island, explore the culture and have a better understanding and stronger bonding between the customer and development teams. Altogether it’s an awesome experience for both the parties. I too enjoy such visits of our customers a lot.

In the same time, being in software offshore business is not easy. Unless you have the right relationship between the outsourcer and outsourcee, the offshore business can become really painful to both the parties.Software development itself is quite challenging even in collocated development environment. When it comes to offshore software development, we are adding some more complexities to it, simple reason is that an offshore development team faces the same complexities which an in-house team faces + much more . So the Project management in this environment by balancing this distant relationship is quite a challenging endeavor.

This series of articles which Im writing to ICPM, will be focused on the challenges in such offshore business and how we use Scrum (One of the Agile methods) at my current organization to overcome these mostly seen challenges in Offshore business. I hear you.. It’s a trade off. When we overcome some of the main issues., there will be other issues which we may face.. Its understood. Its all about how to overcome the most serious issues in such environment and deliver the right value to the customer without scraping the organization’s bottom line.

To manage these offshore/outsourced projects with distributed teams successfully, We first need to understand why Organizations outsource their software projects. By working twelve years in this industry I have seen the same reasons with most my customers who decided on outsourcing their projects to us irrespective of the size of their projects.

1. Skilled Resources
In Some of the countries , its quite hard to recruit skilled resources compared to others. May be its all about the availability of such skilled resources, the market competition as well as the difficulty of hiring such experienced resources only for one or two projects (Shorter time period).

2. Business Focus.
Even if they have these resources available to hire, if the organization’s main focus is not the IT business, it may not be always wiser to hire such resources and expand the IT departments which is not their primary business focus. As an example, a company in travel industry needs to be focused on travel business instead being focused on expanding its software development. So in this context, outsourcing its software development to an organization which focuses on software business can be a wiser move.

3. Protecting the Intellectual Capital
If an organization develop one of its core software products which will give them their competitive edge in the market, the last thing this organization may need is to have its developers who worked on this product to join its competitors with all the knowledge about the business. Some times when an organization hire people from the same country or state, there is quite a risk factor that the developers who work for this product may join their competitors when the assignment is over. But outsourcing this product to a country far away which doesn’t have such closer relationship with the other organizations in the same market may reduce the risk factor.

4. Cost
Most the organizations carry their cost benefit analysis before outsourcing its software projects to other companies. Its quite important that the cost difference to be a visible factor. However there is hidden costs in software outsourcing which I will discuss in a latter article under this series.

5. Round the clock / Extended hours of production
As an Example, if there are 2 distributed teams in an Organization in Norway and Sri Lanka, and if both team work their 8 working hours, the total production time expands to 12 hours as Norway is 4 hours behind Sri Lanka. This helps in some of the product development and software support work.

Its important that as the outsourcee we understand the key factors which enable the outsourcing business of the customer and deliver the expectations throughout development.

In the next part of the article, I will discuss the tiers of such software outsourcing and how the challenges increases in each tier. >>