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.

It is a commonly known fact by now that when a company is looking to create not only a simple, static-content website (for which transLucidonline blink, blink would of course be optimal) but wishes to re-use content, manage multiple sites with many editors, that an evaluation of open-source content-management-systems (CMS) is a very good option. I for one am actually of the personal opinion that for the vast majority of all cases it is *the* option to at least evaluate open- with closed-source CMS.

Lesser known is what to do when it comes to building a website that supports e-commerce transactions. There are now several viable options in the open-source world for companies to choose between for specialised e-commerce platforms. There seem to be so many in fact, that even I who is supposed to be an e-commerce "expert" hadn't heard about some of the new frontrunner's.

Following are three different platforms that i believe to hold the greatest potential in surviving the recent boost in e-commerce systems due to the large developer community and/or support from sponsoring companies supporting these open-source projects. I might add more detail to this "review" later on; for now, here we go.

1) OSCommerce; the princess of open-source e-commerce systems and probably the one that is best known with the largest developer community and a myriad of extensions. Good luck on picking your winner of the package to install and use, there are some packages that create a link with existing CMS such as Ubercart for Drupal

2) Magento which i was sent a link to by someone who had used it very successfully and who found the solution both architecturally very sound, easy to learn and enabling him to launch his site in a very short amount of time. They certainly have to still build a large following but there seems to be just an incredible drive from Varien, the company behind Magento which integrates really everything that you need to run a great e-commerce site in a nicely packaged form that will run out of the box.

3) OpenTaps (based on OFBiz) is astounding in terms of the feature scope it offers; this is clearly the choice for a company wanting to set up a full e-commerce operations, including ware-housing and customer-service. It is sponsored by the Apache Foundation, running under the "Apache Open For Business Project" based on Java technology. The feature list is simply too long to list, so check it out yourself. There is however a nice overview they provide on the opentaps site which i integrated below. Once again, this would be my choice to create the next Amazon.

Having worked at Amazon.de and Amazon.com for such a long time, i find it mind-boggling to see that there are now open-source platforms available that offer many of the same features and scalability that Amazon had 3-4 years ago. No need for a hundred developers, get yourself one or two and build your dream e-commerce site in under three months. It shows just how evolved the open-source landscape has become.

PS: While researching some of this entry, i found a wonderful review that a company called WebDistortion did on "9 kick ass open-source e-commerce platforms"; they provide a good overview of PHP solutions available.

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.

The CIO has a great article entitled "Taking A Systems View" on Intangible Management, written by Sue Bushell.

Some excerpts below but read it yourself; time well spent. I also encourage people to sign-up for the global cost to value taskforce as passive listeners or active participants if the topic of intangible management interests you.

"Talk about perverse consequences. BP sets out to slash 25 percent of its fixed costs and ends up killing 15 workers and injuring 180 others, in the worst industrial accident in the US in 15 years. Instead of counting its savings it finds itself having to sink $US1.6 billion into a legal defence fund, facing a congressional investigation and with some of its officers exposed to potential criminal sanctions."

"General Motors reviews the real impact of its IT cost-cutting initiatives, only to discover that all of its efforts have amounted to much ado about virtually nothing. CTO Tony Scott tells a CIO summit that not only had almost no money been saved, the effort had provoked perverse consequences that proved painfully expensive."

"Traditional business analysis, with its preoccupation with breaking everything down into its component parts and then studying the parts, is useful when dealing with machines," Parsons wrote in a 2000 paper called "Productivity Measurement in the Service Sector". "In the early days of the industrial age it was possibly convenient to adopt such an approach, but such thinking will mislead, often dangerously, when applied to today's complex conditions of existence."

"By December 11, 2007, he is confident the Global Cost to Value Taskforce (see "Going Global", page 48) will provide an agreed and tested method to let managers and executives quickly and easily financially estimate intangible benefits and value to create new ways to increase productivity, reduce costs and risks, and boost service, engagement, retention, profitability and shareholder value."

"One of the very interesting things is that productivity today is caused, from the Standards Institute perspective, by intangibles, and when we look at intangibles we're looking at activities to do with knowledge, collaboration and leverage," Standfield says. "So if we look at an organization and just basically say: 'Well, this particular organization has a certain number of staff; they're doing certain activities throughout the day, all of which can be broken up into those three different categories', basically we get a time fingerprint of the organization. Now from there what we do through the more than 40 international intangibles standards is to assess that fingerprint."

More to come on the taskforce and pilot-projects. As always, feel free to get in touch with us directly for discussions.