Oh, not again… How many times do I have to go through a basic process of application release and acceptance? Yet, here it comes again. Lack of understanding of software testing basics, misunderstanding of the roles severity and priority, bizarre views of the acceptance process. It seems like déjà vu all over again ;) And so far I’ve seen it with it with every small offshore s/w development shop that uses waterfall or similar type of process. So with no more ado let me just state these ABCs of the application release and acceptance…
To accept or not to accept the software should not be a philosophical question. As a matter of fact it should be as subjective as reasonably possible. To stop feelings and egos getting in our way we need to start with setting up a process of release and acceptance. For example, something as simple as that:
Release & Acceptance Process
- Offshore team delivers the software change package (SCP) to my secure FTP site. The SCP must include properly named and versioned build, configuration files, metadata, resources, and release notes.
- My release team takes the SCP and installs it on User Acceptance Testing environment. If installation is successful release team notifies offshore team. Project Manager and QA/UAT team. If install fails the release team notifies offshore team and Project Manager.
- QA/UAT team performs testing according to test plan / strategy that is based on the nature of changes included in SCP. If the system passes Acceptance Criteria QA/UAT team notifies offshore team, PM, Release Team, and Product Manager and clears the SCP to be promoted to staging/production. If the system fails to passe Acceptance Criteria QA/UAT team notifies offshore team, PM, and requests a replacement SCP.
I just got off the phone with David, an old friend of mine and a VP of engineering for a stealth startup in Boston. His team is doing very well, and who knows, we all may hear about him and his company pretty soon. Needless to say, after half an hour discussion of his great idea and the business model we dove into technical aspects. My friend’s technology stack selection is of no surprise – RoR, MySQL and DynamoDB running on AWS. His SDLC is also far from innovative – SCRUM. What I found rather unusual for this stage of the game was a heavy utilization of offshore that he described as one of strategic decisions he made early on. Over 80% of his engineering workforce is based in Argentina, and given the fact that he’s never been outside of this country, it was somewhat a surprise. David rates his experience of using offshore as “one of the smartest moves I’ve done”. We let the time be the judge of that, but in meanwhile a few observations –
David’s motivation for using offshore was very common – bootstrapping the company with current local salaries is close to impossible, finding local talent is not easy and far too time-consuming, especially, getting agile web development skills. So offshore seemed like a sensible path to take. Near-shore preference came from his “control freak” nature. “I just want to see them on the Skype, want to be able to check, ask, re-focus in real time. Time zone differences is not for me.” Having gone through a lot of “bad” and very little “good” experience with offshore he used a small advisory firm to find partner and manage the offshore relationship. But that was not the key to success. “What makes us successful in using offshore are the 5 Cs -
- Clarity – know exactly what the goal / objective is, what result/outcome you expect – in a great level of details.
- Conviction – be absolutely sure that you can achieve your goal / objective – research, analyze, what-if to death, and then cut off alternatives and move forward.
- Commitment – be prepared to put the effort required to achieve your goal / objective; the problems will happen, don’t let them deter you from the path you’ve chosen.
- Consistency – execute with persistence, keep your eyes on the ball; do not drop best practices, even though they seem at times to be nothing but unnecessary overhead.
- Collaboration – make sure that every aspect of your activities has been properly communicated to every member of your team, discussed and accepted by them.
I asked David whether it’s possible that he just got lucky with his partner, but he did not support that idea – luck has no place here since it begins with L :D
The most common emotion associated with introduction of outsourcing in organization, running offshore engagements, and even terminating relationship with an outsourcing vendor is fear. At least that is what I’ve observed over the years. Fear comes in many shapes and forms – anxiety, worry, distress, alarm, panic, paranoia and so on. We worry about so many things – deadlines, turnover, communication failures, key contributors… the list goes on and on.
We worry about many things, and most of them never happen. As a matter of fact, experience shows that 99% of things that we worry about to do not happen, and when things do happen events come at us so fast that we have no time to worry. Yet we continue to live in paranoia thoroughly convinced that outsourcing world is out to get us. Continue reading
A good friend of mine, Alexey, is an “offshore manager” for a mid-sized technology company with offshore offices in Ukraine. After reading my last post he decided to sent me his daily routine. I put “offshore manager” here in quotes since it’s my friend’s role, not the title. Anyway, in his case ODC is wholly owned by his company, and he has a full time job of overseeing development and QA activities performed by the offshore team.
Interestingly enough, Alexey is not an engineer, but for all intents and purposes is a project manager, very good one. His team in Ukraine is over 60 people and is responsible for product that generates at least 50% of his company revenue. Alexey’s offshore team is doing exceptionally well and is considered one of the key ingredients of the company’s success.
I think in a large degree offshore team success is due to Alexey’s work, leadership and unyielding dedication to quality. And now without further ado let me present slightly edited Alexey’s daily routine –
- 15 min Categorize (not read) emails received
- 90 min Participate in up to 3 daily SCRUMs (high risk projects)
- 30 min After SCRUMs I usually have 1 or 2 one-on-one meetings with my team members scheduled at this time. My goal is to follow up with each tech / QA lead at least once a week, with every other member of the team – every other month. Most often via Skype. Meetings are scheduled in advance as recurring appointments.
Last night I met with Chris, an old friend of mine who manages relationships with a large group of software developers and QA engineers located in Campinas, Brazil. He’s been working with this team for over a year after being brought in for a short term contract – an offshore “rescue” operation. The relationship between his client and offshore provider was going nowhere quick. Milestones missed, quality of deliverables deteriorating, blame shifting and finger pointing proliferated. The relationship was clearly falling apart and management frustration reached a point where they no longer were prepared to deal with the vendor.
Apparently the history of the offshore relationship for Chris’s client was rather consistent – find a new vendor, go through 3-6 honeymoon period, then things start braking here and there, the company attempts to improve situation by assigning one of the employees, s/he attempts to salvage the situation, but after a some period of temporary improvements things go from bad to worse and the search for a replacement vendor is initiated… and the cycle repeats. By the time Chris came on board his client was on fourth vendor, this time a small company from Brazil.
The problem was “100% with the vendor” – “lack of understanding of the company’s objectives, poor English and overall communication skills, high turnover, mañana attitude, etc., etc.” – at least that what was what the client told Chris.
If you are a novice blogger, an affiliate, or plan to make a killing by placing Google ads on your site you may believe that SEO will bring you tons of money. It may, but unless you watch every step and invest a great deal of efforts in building the traffic, it won’t.
A couple months ago I started a mid-sized SEO project. I guess by now, after going through a few dozens of SEO engagements I should not be too worried, yet I was. The SEO world has changed a great deal since my last project. Also this time I needed to start from scratch – new site, new for me, very competitive market, and as usual very small budget, both in terms of money and my availability. So, eLance / oDesk here we come.
As it’s typical for SEO engagements I started getting responses to my project almost instantly after I submitted it. 20 or so proposals came in the first hour, about same in next 24 hours, and about a dozen afterwards. Most of the proposals came from India with cost ranging between $5 and $15 an hour. Pretty much all proposals I got were boilerplate documents some of which were slightly modified to acknowledge my name and the project. For follow up I picked about 10 companies with near perfect rating and high number of hours billed in the last year.