Throughout the last two years, starting with the development of the simple website publishing system transLucidonline, Pantha has built up a unique project management framework for agile outsourced development.

Since then, we have had the pleasure of supporting a range of clients from Europe and Australia (start-ups to large corporate), providing them with agile outsourcing teams that have launched and maintained many online applications with great success.

We have shared some of our stories in several blog entries here. One on 'agile software development for teams' and how this can be applied to start-ups and companies of all sizes.

At some point we wondered why it still seemed difficult to explain the benefits of agile development and its potential to change how outsourcing at this point in time is done. What if we could demonstrate it placidly somehow to new potential clients? What if it could be made much easier to engage with people interested in what Pantha offers and show how fast concrete outcomes could be delivered given a mini project? Almost like going to a car dealer and asking him for a test drive?

Which is exactly what we will do, starting now of course.

Following an overview of Pantha's agile outsourcing services. Interested parties can register their interest for a test drive of agile outsourcing here.

I recently came across an interesting article written a few years ago, still, illustrating perfectly the benefits of an agile approach to outsourcing as we practice and advocate so actively at Pantha Corporation:

Everything You Know About Offshore Outsourcing is Wrong

As you can read, one of the largest European bank (ABN Amro) found satisfaction with this model a while ago. This corporation undertook a major strategic change a few years later, fully embracing outsourcing and restructuring accordingly. They also ended up working with multiple suppliers rather than one large one.

Several aspects spoke about in the article syncs amazingly with our experience at Pantha and lessons learned found their way into our framework documentation. Here are some snippets matching the Pantha way:

Agile methodology works best for fast paced application development:

"... the bank [ABN AMRO] 's North American technical architecture group deliberately sought out offshore providers who were not focused on the traditional development processes."

Iteration period needs to be defined on a case by case basis, depending on the context. Success can only be found if the entire project team (client, offshore supplier and Pantha) conforms to our framework:

"We use iterative development in two-week intervals. While one iteration is underway, we start on the next one,"

"It turns out that just because you use short iterations it doesn't mean you have no process."

The client's in-house liaison needs to be dedicated and have authority:

"You must have a local liaison, no question," said Matthias Autrata, senior vice president of IT Architecture. "This person participates in one- or two-day design sessions during which 'stories' are written that describe the user interaction with the system."

"Of course, the local liaison also has to acclimate to our culture," said Autrata. "Often they must learn to be more aggressive, to go and get what they need."

Requirements made of user stories including technical solutions, are to be signed-off on the client side:

"Another [lesson learned] was that the ABN AMRO team had to get its own requirements agreed to before communicating with the liaison; working through conflicting or inconsistent needs real-time was not efficient "

etc.

The article also strikes the importance of understanding the culture (both on the supplier's and on the client's sides) which we have put focus on from the beginning and worked through with our long-term-relationship offshore partner in India.

Here below a slide that summarizes our solution to some common issues in an offshore setup:

Across several blog posts, we have covered agile development for teams as well as agile development outsourcing for startups. It should not be a big surprise to anyone therefore, that we have been forwarding our experience in outsourced agile development to a growing list of clients.

What we offer are dedicated agile developer teams where the development is completely managed through us. Welcome to your outsourced project office.

We can do the writing of the user-stories (core story, wireframes and acceptance tests), the project management of the development (iteration planning, daily update meetings, status tracking & reporting) as well as the initial acceptance testing. What we find is that every project is different and we adjust our agile development outsourcing framework to these requirements. The existence of a concise framework allows us to quite rapidly set-up operations for new clients and ensures that learning's can be leveraged across our clients.

At the heart of all project management stands communication. We use a range of tools to support communication across distances. These are in no particular order Skype, conference-call rooms, project intranet and a fantastic collaboration/ white-boarding e-room. We've played with the idea of sending Mac Mini's out to clients that have a permanent team-size of >=5 to allow smooth video-conferencing via iChat (as opposed to the poor quality in Skype) but have yet to act on this thought.

We strive to provide the ultimate in transparency and as much information as possible as to the current status and delivery dates. And working in short iteration cycles of about 3-4 weeks, depending on the client, with tools (currently XPlanner, although we might start using TargetProcess) to monitor the progress of a project provides us with a wealth of information. Every day, a core group of people receives a daily update status mail that lists progress on the different stories we would be working on. Every other week, we issue a bi-weekly report and at the end of every iteration we issue a report on what was completed and moved to the next iteration.

It can be challenging to attempt agile development across distances and throughout the last year we have had many good learning experiences. Not everyone has a unit-testing framework for example so continuous testing and starting with tests is not an option (although we will propose implementing a framework at no cost as it will help us increase our overall throughput and raise code quality). Not having the customer with you means that acceptance testing feedback can be difficult to collect (we now do 'live' testing sessions using our e-rooms screen sharing and note-taking facilities). Knocking on doors to get quick feedback on interaction designs will not be possible (so we always start with a wireframe exercise, now using Axure to create very realistic demo's of the user-interface).

All in all though we know that the outcome using our agile development outsourcing framework guarantees our clients greater flexibility in their planning, increased ability to provide us with feedback that will actually be integrated, a better sense of the different project status and a higher overall output than compared with outsourced development teams operating "the old" way.

Soon we will provide some examples of how we perform our iteration planning sessions, keep clients on top of things and collaborate with them and our outsourcing team on project requirements and execution. We are considering providing a "test-drive" to a selected few interested parties tempted to try our agile development outsourcing services as well, more on that coming up.

As a company that provides consulting and outsourcing services to medium-sized and corporate companies, we have to strike a balance between being on the cutting edge and not loosing the focus at the same time to translate new tools & methodologies into concrete benefits for our clients.

For quite a while now - as early as 2006 in fact - we have been posting on collaboration tools and how they can enhance interaction for distributed as well as local teams, including the possibilities of 3D virtual worlds such asSecondLife or Croquet.

At the same time, we have used many tools ourselves most of which we discarded as being not user-friendly, slow or not fitting to our requirements. Being in the same situation as other product development companies of having to co-ordinate people across three, sometimes four time-zones, we needed an application with a broad range of tools, the swiss army-knife of collaboration tools.

We were actually featured last year October in the Australian Financial Review and could only agree (yep, there was some shoulder tapping) that Theandb was "an example of globalisation at work and how the use of technology can compete with much larger companies". Some more quotes that i could not put any better:

"We could not have successfully moved the business to Australia and kept some of our longstanding, former clients without this technology," Ponthus says.

Theandb relies on the facility to consult with businesses across Europe and Australasia, helping them develop online strategies and implement web projects.

Theandb's work involves regular meetings to ensure everyone involved knows the stage a project has reached and what their responsibilities are."

The best thing about using this system is that there's no disagreement at the end of a meeting about what everyone needs to do for follow-up and what was said during the meeting because the project manager writes the notes directly into a whiteboard that everyone sees," Schliebitz says."

Back at that time we were using Marratech which was unfortunately bought up by Google.

Only last week we finally - after months of research and trying out way too many different web1.0 and 2.0 applications - we found the perfect replacement, an application that is even better than Marratech was and it goes by the name Elluminate. We will post more on this wonderful tool soon.

We have seen vast improvements in communication and the ability to collaborate with our clients since starting to have Elluminate. We can finally be literally on the same page again, share our desktops, write up meeting notes which everyone can read and comment on while the meeting is taking place, use the excellent whiteboarding features, paste in screenshots and doodle around on them; simply put it is like working together in the same office, only far more efficient because you can actually fully concentrate on what is at hand.

We are quite aware that using such tools gives us an advantage over other suppliers in the development outsourcing market and will continue to elaborate on our outsourcing framework and general set-up as we learn with our clients. We will post more on the framework we use and why we believe it to be unique shortly.

The following entry is about our experience in launching transLucidonline, THE simple website publishing system, through our UK entity Pantha Software.

We believed there to be a lot of value in working agile for web-development projects even before we started working on transLucidonline. But then, call it an initial lack of experience in managing a product launch ourselves, we commenced development of the portal site using a waterfall methodology. "Of course", the project did not go well. We specified something that we asked the outsourcing company to develop for a fixed price, they delivered what they believed we had meant and it turned out to be of low quality (in terms of code/ architecture) and not exactly what we had in mind. From there on, it was a back and forth that resulted in more and more "change requests" which in return increased the budget over what had been allocated before to the portal site.

Long story made short: We switched companies, started working agile with them as well as an expert (on Zope & Plone , which we use for the portal site) from day1 on and have since then always been happy with the progress made.

This was also due to the excellent people we were now working with and some of the things inherent in agile development which can be broken down into:

* Planning
We set out with a planning of the major features necessary for transLucidonline. This created the basis for our 'product backlog' which was/ is a prioritised list of features we want to develop.

* Defining the individual features
We worked down our list of features in an iterative fashion with new functionality to be tested on a regular basis. The stories were well defined but did not have the depths (=lots of work) that a "standard" business specification would have. Which meant we talked with our development team on what we had in mind.

* Technical reflection on the requirements
From these discussions, the developers reflected on our business requirements by writing up the technical tasks they believed needed to be undertaken to complete the required functionality.

* Prototyping
Once we had found agreement, the development would commence. Sometimes we were able to see prototypes early on to test and give further feedback on. Most often, the individual features could be completed in 1-2 weeks development time which we felt did not require initial prototypes.

* Testing
Once it came to testing, we would use the user-acceptance tests (UATs) as previously defined in the user stories describing the required functionality. Based on the testing, development would either continue or be "officially" defined as completed.

Overall, thanks also to our unit-testing framework, we have been able to complete quite a long list of features with very minimum up-front investment. Furthermore, this way of working allowed us to continue to run our consulting business while at the same time spending time on product development internally. There was a constant flow, rather than spikes of code to be specified, developed and tested with XPlanner providing us with an accurate, up-to-date view on what progress had been made on a daily basis.

We are never going to go back to the waterfall ways of development and i would recommend any other startup-director to do the same.

For some time now I have been wanting to share some of our own experiences with the different agile development methodologies we have used during the past few years. This post will be about the realities "on the ground", unfiltered and hopefully be another piece in the puzzle to make agile methodologies become further accepted in the corporate business world.

We have worked with different agile development methodologies in the past. We've never been religious about implementing everything these frameworks recommend but rather chose what we felt really worked. We started to work with ExtremeProgramming (XP) in Seattle in 2001 at Amazon.com . I had the honour to manage the web-development technologies platform team there, which had just started using XP shortly before I arrived in the States. More recently we added parts of Scrum to our mix and have been applying it since the beginning of 2007.

I get surprised time and again that not many people seem to be aware of the concept of agile software development. Even worse, when people have heard about it they don't seem to have had very good experiences. There seems to be suppliers out there who use it to sell their services without really knowing what agile development entails. When a new client believes that we are no different, it can be very frustrating.

Let's do a reality check. Based on my personal experience, the application of agile methodologies delivers results much more consistent with the customer’s expectations than waterfall methodologies. All while increasing overall quality and lowering the likelihood of breaking stuff when introducing changes and additions to existing functionality. There is no doubt that projects with agile teams don't always succeed. But what is the percentage and overall customer satisfaction of agile-driven projects? And how does it compare with standard waterfall methodology?

I strongly feel that when it comes to building web and software applications, the only way to allow a company to increase innovation, but not downtime and bugs, is to become agile. This will mean a change in internal company culture. Implementing agile teams is much more a change management project than anything else. All of a sudden, business owners and software developers have to meet and talk. Instead of (often not so useful) business and technical specification documents that can become longer than a standard-length novel, internal customers have to slice and dice up their big ideas into many little, more digestible pieces, which will in turn be prioritised against all other internal and external demands by their software development team.

After an initial phase-in time for the business analysts that now have to create compelling and easy to understand so-called user-stories that are only "reminders for conversations" with other people within the company, the prioritisation and waiting in line until a project is started can be difficult to get used to. Although, when compared with the world before, there are no more false "Yes I understand what you want", "Yes, I read your specification document" or "Yes, we'll get it done next week, promise". Instead, the software development team should have become much more customer-centric and service-orientated. True, they may not promise to get it done immediately, but the more they learn how much they can get done in a certain duration of time (agile really helps development teams in tracking their time and estimations) the happier they will be to give deadlines for project deliveries. And those deadlines will stand the test much better I am sure than deadlines before the "dawn of agile".

With time, the internal customers of the software development team will understand that they actually get what they wanted in the first place. More and better communication will lead to a teaming-up of the technical and business teams. There will be no side-picking any longer but an understanding that both "sides" need to work together to create the best results.

All of this may sound a bit utopian to the ears of someone not accustomed to working with real agile teams. I recall very vividly an experience not so long ago with an outsourcing company that we had hired to do some product-development. Stupidly, we sent them specification documents. Didn't meet with them on a daily, sometimes not even weekly, basis by Skype. Had heated exchanges by e-mail on what we "actually meant to say“ in a certain paragraph of our specification document. And ended up receiving results far below our expectations. Why did we not do what we preach to our clients when consulting with them? Well, I guess any organisation needs to learn. We did!
Now contrast this with a new day, a new team and an agile development framework. Daily meetings to catch up on what was done the previous day, what will be done the following day and any blockers they have encountered that we might need to get out of their way (processes, tools, etc). We are getting what we want, are able to test and code-review what they build. And most importantly, everyone just seems darn happy to work with everyone else. So maybe not so utopian after all. I swear to never go back to the twilight zone of waterfall project-management.

Last but not least: A senior level buy-in - as is true with any other larger change management project in any organisation - is absolutely mandatory for the overall health of the transformation from pre-historic to 21st century development methodologies. There is no way that a team manager all by himself will be able to push through all he needs and make everyone happy at the same time without an approval from the highest ranks within the organisation. If such a buy-in exists though, there is no doubt in my mind that overall happiness and productivity will increase as a direct result from the change in software development practice.

As we've worked with and are in touch with several outsourcing companies, this weeks article by Norhternlight had me interested.

There's no denying it that it can be a painful process to outsource a whole department for example though people have always stressed the long-term cost benefits. This story takes a twist in that instead of underlying the savings it stresses the improved time-to-market. Knowing how fast teams can be assembled in countries such as Vietnam or India with highly skilled people I can only agree. In fact, for our product transLucid we are looking at using an outsourcing supplier to continue its development because 1) lower costs and 2) the availability of skilled workers.

Here's the article. I hope that I am not infringing on any copyrights of Northernlight here. I can only recommend to try out their business research solution. Personally, I unsubscribed for different reasons (mostly due to a lack of a need for market research material) but somehow stayed on their mailinglist.

-----------------------------------------------------
General Motors' recent decision to outsource roughly $15 billion worth of IT contracts over the next several years may seem to be just one of many such transactions going on in the outsourcing arena; and it is. But more than being just another example of the current state of the market, it is an indicator of the new direction it may be taking. One interesting thing about GM's move to outsource is the rationale behind it; it wasn't only money. For various reasons, saving money through outsourcing is not the easy win it used to be; this is ok with many companies as they now look to outsourcers to fulfill different needs. According to GM Chief Information Officer Ralph Szygenda, GM's outsourcing move, "Lets GM focus on innovation rather than spending a lot of time on managing its suppliers." GM is not the only company to realize that initial savings may not be the best primary driver when considering outsourcing.

read more...

Big.biz still keen to export jobs | The Register

A survey about offshoring: the trend gains some terrain in Europe