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.

With our involvement in the creation of transLucidonline, the simple website publishing system for small- to medium-sized companies, through our UK entity Pantha Software, we discovered a little the start-up scene in Sydney. And discovered that there were many more Web2.0 start-ups than we ever imagined, the term 'silicon beach' a very fitting term for this beautiful strip of land we live and work in.

Whereas in Silicon Valley it feels that the same errors as in the first web 1.0 bubble are repeated (buzz, buzz, buzzzzzwords galore, geeky-sounding company names, skyrocketing valuations, ...), the hype ever growing and insiders starting to worry that it's all a little bit of history repeating, i got the feeling from talking to some startups here that things seemed a little bit more grounded overall. Being far away from the Microsofts and Googles of this world and "alone" on a large island can be good when you are trying to build something of lasting value, where long-term goals can have higher priority than short-term return.

Just my 2 cents. Certainly, our office location is not the worst.

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.

With all these Web 2.0 start-ups (oh, we are one of them with transLucidonline i guess) all around it is not often to find one that is extra special.

Today I think that I found one of those gems that I am sure will not stay hidden very long. The Rubicon project is a service through which site owners can manage their advertising space. No, not only Google AdWords. About any ad/ partner network the world has to offer, currently about 300 (!) of them. And they automatically adjust which ads to show more often based on their individual performance. Coupled with a great dashboard over the ad space and earnings performance, this looks like a real killer app. Someones seems to have gotten it right.

I have immediately integrated it into our private website theandb.com and we are certainly - if these initial tests prove fruitful - going to use it for transLucidonline, the simple website publishing system, going forward. What a wonderfully painless way to manage your ad-inventory space.

Clearly, with buyouts and overvaluations now common place again in "the valley" we do have a bubble 2.0 going on. So my question is only: When will it burst?

An interesting article at the IHT entitled "Dot-com fever stirs sense of deja-vu" brought me to the postulation of this question.

It might of course be a good thing for us with our startup activities relating to the launch of transLucidonline. What a shame though that we already have actual paying customers. That might de-value us in the face of some VCs. :)

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.