Bottomline: It'll take a couple of months until we'll be settled again. As soon as that is the case, I'revive this blog.

Till then, hang in there!

Me and my team went through a lot of instability for slightly over a year. No one got fired or something like that but as the company grows and demands shift, employees move between teams. Due to that I was without a permanent team for a while and just recently got back onto stable ground.

While being on the long road back to stability I realized many different aspects and nuances - some obvious, some not so - that come only with a stable team. I've come out of this with the resolution to prevent any further change to my team if by any means possible.

Estimations are possible

Without a team that doesn't know the technical environment, the project or product it is supposed to develop and last not least a team that doesn't know itself, forget forecasts or estimations. They'll be off.

Knowledge is one thing, experience is a whole different story. Our training phase for example takes three full months. After that new team members have seen more than 50% of the software components we use and understand a little less than that. How much experience with the whole shebang do they have? I'd say around 25%. So even after completing the training there's still a lot to learn.

So if your team doesn't know what's in it's toolbox, how can they possibly give you the right forecast in your product backlog estimation sessions?

Let's keep technical complications aside for a moment: Does your team have it's own jargon? I haven't met a team that doesn't. While that jargon might confuse outsiders, it helps the team to understand each other correctly. But jargon takes time to develop. With an ever-changing team, there'll be misunderstandings within and between you and the team with a direct effect on the quality of estimations.

Quality will skyrocket

In a way the difference between a stable and an unstable team is like getting the job done and getting the job done right. Remember that toolbox I mentioned above? Usually there is more than one way to get a job done with any given toolbox. Most of those ways work, but very few will be good. "Good" here implies maintainable, efficient, scalable, understandable and a few other things.

I've had a lot of review meetings with a user story being done but being done crudely. Here's the thing: I can't blame the team if they've been in that specific constellation for no more than a couple of weeks. If at all I can blame myself for not giving better support.

Who or what is to blame is beside the point: The solution is a stable team that has had time to get to know each other, you as their manager and equally important the frameworks in their toolbox. Take it for granted: No one actually wants to deliver sub-standard software. No one wants to have tasks fail in the review meeting.

Improved skills

In agile, a team is self-organized and self-sufficient in a way that it will be able to get any job done it was formed to do. Rarely you'll be lucky enough to form a team that already fills all roles from the start. In my case, developing an inhouse product, there is no way I'll find someone from outside the office who has even seen the code they'll be working with.

So naturally some skills need to be developed in the team, some others need to be improved. That takes time. Changing the team before the gaps are filled causes confusion.

On the other hand if the team changes after the gaps are filled, you start from scratch. Your new reshuffled team will have new gaps.

Either way you and your team both lose.

Work satisfaction

Growing together as a team and succeeding sprint by sprint is a very satisfying experience.

I'm not talking about any kind of measure here. Sure, the ever rising average velocity per sprint is nice. But actually I'm convinced the emotional aspects that happen when interacting with each other are much more satisfying. I've had very successful review and retrospective meetings only with team members that "got" one another. And hey, what better is there to go home on a Friday evening after a review meeting that didn't find any defects and only minor improvements?

Being able to trust your team (or your manager, if you're part of the team) is pretty darn cool. For the management it's quite simply a relief. For the team it's good to know that you can always go back for clarifications and that "bad" news are usually not a problem between the team and the management.

But here it is again, trust needs time to grow.

Next time you have a meeting with your team, pay attention to the atmosphere. Is someone cracking a joke? If so, I bet it's one of the more seasoned team members whose trust you've already earned.

Productivity rises

Back to the toolbox. The more familiar the team is with the frameworks of their work but also with the strengths and weaknesses of their fellow comrades, the more productive the whole unit becomes. Less time is spent talking, discussing, researching, coaching, debugging, R&D'ing etc.

Also, people will pick the right tasks for them. Usually tasks they like, in areas of the software they're familiar with. They can't make that decision if everything is new to them because they've just joined your team.

It's a little bit like driving a car or riding a bike: Once you stop to think about your hands and feet it all goes much much smoother. But then change from a manual shift to automatic in case of a car or from right foot gear to left foot when on a bike and you're in for trouble. You'll probably still reach your goal but you're just bound to have a few screw-ups on the way.

Closing thoughts

Like I said above in my case training takes no less than three month, and that is for people with 3-5 years of domain experience. After that I estimate another 1.5-2 month until new members have gained familiarity of some sort.

So in my case the team needs at least 5 months to mold. How is it for you? I bet if you're honest and realistic it won't be much less.

This implies that changing the team only twice a year will immediately prevent you from ever reaching full potential for any meaningful amount of time.

Whether you see it from a work-satisfaction point of view, from a ROI perspective or you have a longevity standpoint. Changing your team is a killer.

What are your experiences?

Enough of me, how about you? Did you experience something similar? Or do you have other experiences? Did I miss an important factor? Let me know, write a comment!

I've isolated a couple of reasons why I believe shorter sprints result in higher quality and higher velocity that I want to share:

First, we had a release cycle of roughly two to three months. Having three week sprints simply gives you very little "wiggle room". There too few sprints for any mayor course correction! Mind you, no change permitted within a sprint! With only three to four sprints in a release there is hardly any chance to start with a rough idea at first and custom-fit it during the release by refactoring those parts that did not work. With shorter sprints you simply have more reviews and hence, more feedback loops.

Second, specifying and planning enough work for a three week sprint properly is hard. There's an unnerving similarity to a requirement specification that is carved in stone back from the not-so-agile days. See my first point on this as well. With shorter sprints your planing is more flexible. You can navigate better with less "requirement visibility" in short sprints.

Third, with a team that was technically well experienced but new to Scrum the planning meeting seemed to take forever. Routinely we would sit in the conference room for three hours or more only to leave the planning session mentally exhausted. As a result the productivity for the rest of the day suffered a lot. The same is true for the review meeting by the way. I have yet to meet a developer who loves meetings. Short sprints help to keep them short.

Fourth, I experienced a small waterfall process happening within each sprint. For two weeks or so the team would *cough* "finish" *cough* all tasks and then spend the third week testing, bugfixing and writing documentation. Last time I checked that is not the idea behind Scrum. With short sprints I could prevent the in-sprint waterfall. There simply is more pressure (the good kind) to get a task DONE the first time and not require a distinct testing phase in each sprint.

Fifth, you and your team will get more practice to do good and efficient planning, rewiew and retrospective meetings when the sprints are shorter - you simply have more of them. This extends to quality in general - with more feedback from the Product Owner and stake holders, the team will get a much clearer view on where additional improvements are required. Because of this I experienced an increase in quality very quickly after shortening the sprint length.

The sixth reason for shorter sprints is a better break-up of tasks. Since the goal of a sprint is potentially shippable software increments larger tasks have to be broken up into much smaller chunks in oder to have "something" shippable after a short sprint. In my experience, this has two advantages: A better and more in-depth discussion about requirements in the early phases of the release on one hand and better estimations on the other. It's the age old divide and conquer paradigm: A small chunk of of work is better understood and hence implemented with higher quality and closer to the requirements with a better initial estimation than a larger one. Note that of course nothing stops you from doing a good break-up even when you have long sprints. But in short sprints, you're forced to do it.

Six compelling reasons why shorter sprints might be better than longer ones. Better? yes. Easier? Probably not, at least not at first. Currently one week sprints are the limit for us. We need to increase our amount of automation (Unit testing, frontent testing, continuous integration) in the project in order to reduce the sprint size even further.

That aside, I'm not sure whether or not a sprint length of let's say three days makes sense. It will break the weekly rythm and from what I see, people like a steady rythm. Imagine having planning meetings on Monday for sprint one, then on Thursday for sprint 2, Tuesday for sprint 3, Friday for sprint four and so on. Usually the organization around your team will breathe in a weekly rythm - board meetings, cross project knowledge shares and all other meetings tend to be in a weekly, bi-weekly or monthly pattern. With your team having a sprint length that is not a multiple of a week, I see them having to skip those other meetings quite often. To make it short: I don't see it work.

The ideal sprint length for you depends on many things, including the complexity of your software and non-technical requirements that you'd usually find in your Definition Of Done. Maybe two weeks is a really short timeframe in your situation. Maybe a week seems awefully long. I'd suggest to start with a sprint length that is challenging, but not scary. That way I was too cautious to start with three week sprints. Once things run ok, or if you keep encountering one or several of the situations I described above, ask the team whether or not they want to shorten the sprint by one week. Look at the results for maybe tree sprints and see if it worked.

You can keep doing this, shortening and lengthening the sprints by one week increments until you find your own sweet spot.

Have you found your sweet spot already? How long is it? Did you encounter other reasons why a shorter sprint length seems to be better than longer ones or maybe a reason against short sprints? Let me and all other readers know! Leave your opinion in the comments!

Next in my discussion on how to do offshoring successfully is independence. You have to make sure the development team in the offshore location can work as independently as possible.

Like the earlier articles it is equally important to deal with the subject of independence in the planning phase of a project, but also each and every day of its lifetime.

Large enough backlog

It may seem obvious but a good start into independence is to make sure that there is enough work. Specifically, ensure there is enough work even when a few of the tasks require clarification or face issues that can't be resolved without the support from another office. Examples are an external system not being accessible due to firewall issues, a synchronization that failed, etc.

You don't want your developers to be idle as soon as a minor glitch is encountered. As we learned in the first part of this series waiting for a clarification can easily take the better part of a working day if you are working across time zones.

Naturally in the end of your sprint (if you do Scrum), your iteration or when you reach your next milestone all the tasks that are assigned have to be completed. The reality will be that you need to take into account the effort for clarifications and keep that in mind when you plan your sprints / iterations / milestones. So this is not a matter of being lax. It is a matter of being realistic.

Encourage your team to adopt an agile way of thinking. Encourage them to stay productive by switching to another task if another one is blocked.

Assign whole modules, split vertically

Aside from ensuring enough work you can increase the productivity by assigning independent modules. In order to do that you have to understand the difference between a horizontal and a vertical split and know the implications.

Each application probably contains backend code, business logic and database access code, certainly a GUI of some sort and maybe external interfaces.

A vertical split would be to assign the implementation of one whole feature of the application to one office - including the GUI, the business logic and everything else related to that feature - and another feature to another office.

A horizontal split would be to assign the GUI implementation to one office and the implementation of the backend to another office.

Note: Let's say you split horizontally. Any change in the business logic (done in office one) might break the GUI (done in office two). Now office two doesn't know if their GUI is breaking because of a change in the business logic that office one didn't inform about yet or because of a bug. Communication is required. Communication that takes time.

To complicate the matter further, office two can't fix the issue in the business logic even if it is clear as day that it is a bug because they are not responsible for the code! They might not even have sufficient permissions to that module in the revision control system!

It is important that each such module can be fully implemented and tested independently. So take the effort and divide your project vertically. You may think it is not possible but usually it is. Maybe it will take some effort but that effort will pay off soon.

Small support-work is possible but less efficient

Resist the temptation to do all the 'serious' work in the main office while assigning only service tasks or bugfixes to the offshore location.

This approach might lead to the unfortunate situation that the offshore office doesn't have a holistic view on your application or product. If the global picture is missing you risk a lot of harm by developers fixing a bug in module A but breaking modules B, C and D in the process because they didn't know those were related.

Remember: Your offshore team knows a lot less about what happened in the workshops with the client than you do. They were not there. They only know what you told them.

You might think that the developers in the main office are 'better' or otherwise more experienced than those offshore. My advice is to fly offshore for at least a month and spend a lot of time analyzing the situation from their side. Chances are that you discover impediments that you didn't see from the main office or that didn't seem that dramatic. Work on those first.

Removing these impediments will be easier and less expensive than to have your 'better' staff in the main office support the offshore staff continuously. You might even risk to disgruntle your main office staff if these impediments remain unattended.

Your view?

The aspects I discusses in this article certainly are only the top of the iceberg that threatens to sink your ship. Let me and my dear readers know what other obstacles and issues you encountered in terms of working independently and how you solved them. I'm happy for every single comment.

Hope you find them as useful as I do.

If you're irritated about what pen & paper Scrum is refer to the original article.

I give you some measures to keep the project on track and inform you about early warning signs.

If you missed the initial articles which handled the added complexities of time(zone) management, or the second one talking about the role of the coordinator, I recommend you click one of the the links and start there.

Preparation

You will want to make the project as well prepared, clear and free of uncertainties as possible. Yes, you always try to do that even when you're not offshoring. Here you have to try even harder.

The communication overhead in a co-located project is incredibly high to begin with. A week more spent on clarifications will save you a lot of trouble, time and hence, money.

Just remember: Your offshoring partner did not sit in those workshops with your customer. They are not on the phone with the customer. You know a lot more than your partner from offshore. It will be impossible to give them all the info you have but make sure you try real hard. Have a formal kickoff meeting (with physical presence!) and a workshop or two in the beginning.

Start face to face

It is a very good idea to bring your project manager, consultant and coordinator to the co-location for a couple of weeks during the start of a new project. A reasonable time frame is six weeks for a multi months project.

Make sure your management / consulting team arrives at the co-location a few days prior to kickoff to have enough time to settle down, get rid of jet lag and initial health issues due to change of climate, hygiene and food.

Plan time for the teams (main office and co-location) to get to know each other on a personal level. Go out at least once before kickoff. Dinner, bowling, cart racing... almost anything goes.

Setup checklist

Of course, there also should be enough time to set up the working environment prior to kickoff. Verify and re-verify everything. This includes but is not limited to

• the required documents are on location, in the correct language and up to date
• development environment is functional
• a revision control system such as Subversion is set up, accounts are configured, known and working
• a bug tracking system is set up, accounts are configured, known and working
• a deployment system is available and visible from all locations
• a mailing list is generally a good idea
• for long term projects setting up a wiki makes perfect sense
• hand out lists of phone numbers with every person on the project being on the list
• do the same for the instant messenger of your choice
• make sure the offshore team sits together to facilitate mouth-to-mouth communication
• a few webcams are great to keep the team(s) connected and personally involved

Focus

In an ideal world the project manager and consultant of a project are assigned to it to one hundred percent and do not have any obligations outside of that. If you can achieve that, perfect. In fact, you should try real hard to achieve that if you start a new project at a co-location.

A not-so-ideal world results in project manager and consultant being involved with more than one project. This is the common scenario. During the start phase of a new project in an offshore location this imposes a great risk. The return flight is booked and changing it brings a lot of complications, so time is incredibly precious. Make sure your manager / consultant pair has no other obligations during the time they spend offshore with their team.

Here's a simple trick to ensure no one intervenes while you as a manager or consultant are in the offshore office: Be on vacation. At least officially. Do whatever is required as per your company's process to be on leave. Assign a vacation replacement. Inform your (other) customers. Make it very clear to the colleagues of the other teams that you will not be available except for disaster recovery. Stick to it.

Structure your communication

Even with small teams it is quite easy to end up with a communicational mess. I mean a situation where everyone is using instant messaging, mail, the bug tracking system and the phone simultaneously. The results: Information becomes redundantly stored in multiple communication channels. Only a part of the team is informed. Efficiency goes down.

Spend some time in the beginning of the project to craft a communication diagram. Develop the diagram together with your team to make them involved in it. The diagram has to have two design objectives: First and formost it has to streamline and unify communication. Second, it makes communication transparent.

Maybe it makes sense to assign a 'communication lead' from within the offshore team. That'd be the person that centralizes all statuses, issues and clarifications and takes the initiative to resolve them with the main office. If you're doing Scrum, that'd be your offshore ScrumMaster. The benefits are several. One, there is one person offshore who has the global picture. Two, the other offshore members can continue working (on other tasks) while issues are resolved. Three, for the management / consulting / coordination team in the main office the communication becomes much more efficient and less redundant.

The second start - remote

So now your project head has spent a couple of weeks at the co-location and the project started well. The communication is clear and efficient. Things run generally very smooth when your manager / consultant pair take flight and leave for the main office.

Be prepared for an immediate slump of efficiency.

It's easy to wrongly assume that things will continue to run as smoothly as they did initially, when face-to-face communication was the norm. Reality is that they probably won't.

Be on the lookout for a general reduction in communication. There is no save assumption that this would be ok. Instead, communication should go up, both in frequency and duration. If it doesn't, find out why as soon as possible and remove the impediment.

Do not believe that a team member who does not communicate is productive. Maybe he is, but chances are that he is stuck.

Mind those time zones. Ensure that any clarifications, issues and problems in the offshore project are resolved before you involve yourself in local projects.

Summary

The list of topics to cover under 'preparation' is endless. Largely it involves communication. Be aware of the fact that you will not be able to fully know what is going on at the other location and have tools and measures in place to compensate for that.

I'm sure I didn't cover every aspect. If you're stuck at a certain point or you've encountered different issues than the ones I discuss above, use the comments to inform me and my readers! For a more personal discussion feel free to get in touch with me through the contact form.

Here I will discuss the role of the coordinator and what its responsibilities are (and are not). What to look for in the person filling the role but also how to enable this person to do a good job.

Pick a good coordinator

Fact is, you need a dedicated coordinator with great social skills, management capabilities and thorough technical expertise to make offshoring a success.

There will be clarifications. There will be complications and missing pieces of information that no one did foresee. For all of these you'll need a solution as soon as possible in order to keep productivity high. Mind those time zones!

This is why you really want to assign one of your best employees to the position of coordinator.

Enable your coordinator to be successful

First, he has to be willing to do the coordination, he must believe in the whole endeavour and be willing to travel to the co-location every other month. If he doesn't believe in it and in him making it happen, you risk creating a self fulfilling prophecy and the project might fail. Also, coordination done purely from a distance is futile, so the will to travel is mandatory.

Second, you have to reassign all of his previous responsibilities to other people. The initial months of setting up will require all his efforts. It needs time for the offshoring "engine" to run in - during that time you will want the full attention of your coordinator on the endeavor. When the projects start to run smoothly he'll probably be able to take back a few of his earlier duties, but to expect that he will be able to do so from the start is an illusion.

Third, he will need to have the power to make decisions on his own.

Avoid to make him the responsible puppet. Give him power.

Chose the lesser pain

Yes, assigning one of your top employees to the coordinator and freeing him of all other duties is expensive and potentially complicated. You'll probably need to hire new staff. Other seasoned members of your staff may have to take the burden of extra work for quite a while. Customers might get slightly irritated when you remove your coordinator from their project.

It will hurt. A bit. For a short period of time.

Assigning a lesser qualified employee to the offshoring endeavor would hurt you much more. So will giving an excellent employee not enough time or power to do his job well.

Projects would be delayed or - god forbid - fail because the coordinator doesn't see the gaps or is not empowered to close them. Customers might get really unhappy and may pick another contractor. Your employees may burn out. A general negative image of the offshoring partners and developers may form among your own staff.

That'd hurt much more, much longer.

Coordinator without active project involvement

I argue that the coordinator should not be part of any specific project team. His major job is to keep the projects running smoothly and to identify areas that need improvement. He needs to have the birds eye view on all projects. Experience tells me that you miss the global scope quite fast if you are actively involved.

Note that it is irrelevant whether the coordinator is responsible for one or for five projects. Active personal involvement will make him lose his global scope.

Responsibilities

He needs to watch the teams spirit. Does communication between the locations happen frequently and soon enough? Are people happy or hesitant to use the phone? Does each side of the team see the other side as an equal partner? Do people know each other personally - at least a bit -  across the locations? If communication is good the battle is almost won.

He needs to aim for clarity. Are all tasks and work items understood and without doubts? Does the offshore team know who to contact? Do they know what will happen next week and how the project status is in general?

He needs to ensure efficiency! If hardware or software are inadequate or the working environment as a whole is not suitable this constitutes a bottleneck that needs to be removed. Are people working smart? Do they know how to use the tools they have efficiently?

Offshoring is hard. There are many mistakes to make, some obvious (in hindsight), some not so. Do not expect an immediate success. If you have the strength to sit through the initial months, it can be a good solution to compete, grow and react flexibly to changing environments.

Being largely involved in offshoring and on-site coordination myself, I'll present you with some of the success factors that proved to be most critical in my own environment.

This is the first article in the series, make sure you come back in a couple of days for more on the topic!

Mind those time zones

Working across timezones becomes an issue really fast. In my case, I deal with a rather small time difference of 3.5 hours in summer and 4.5 in winter (daylight savings...). The good news is that we actually have the luxury of sharing office time in both locations. This improves the overall condition tremendously. But let's take a closer look:

Timezone difference between Germany and India

The above graphic visualizes the typical office hours. Red cells mean "no way, no one will be in the office", gray cells indicate "people are slowly coming in" and white cells assume general availability. Lunch time (typically starting at 1pm in India and 12am in Germany) is also marked gray.

So even with only 4.5 hours of time difference you have only around 4 hours of office time left where you can be sure the other part is also present. Sounds obvious at first but let's discuss what this means with a few scenarios.

Pitfalls and how to avoid them

If you're in Germany and you find a mail asking for clarification in your inbox, you'd better reply before you leave for lunch or else it might already be too late for India to react.

On the other hand, if one piece of information is missing for you in India, you'd better write that request before you leave in the evening - Germany has almost four hours left to analyze and reply. Let's play this through: If Germany doesn't respond to that mail before they leave in the evening India will spend at least 5 hours the next day without that information. That's a lot of potential and money wasted.

Any conference calls must be scheduled during German morning, otherwise your Indian staff will work late and that will affect efficiency in the end.

Those are just a few examples of daily activities that need more consciousness in terms of time management. You get the idea.

So what's the solution? Awareness of course. But that is easier said than done. One thing that will help is to adopt a practice from the military: Think and communicate in Zulu time. In essence Zulu time is Greenwich, UTC+0. No matter where you are in the world, if you communicate meetings in Zulu time, everyone will know what you mean and will know immediately if that's ok for them or not. It takes a few days to get used to the concept that your office hours are 3am - 12:30am UTC if you're in India, but after that it works like a charm.

By the way: You can set a second timezone in your Outlook calendar.

Other experiences and solutions?

What is your experience with working across time zones? Did you encounter other issues not covered in my post above? How did you solve them? I'd be happy to read your comment!

For detailed discussions or requests feel free to contact me personally.

Make sure you also read the second article in this series about the on-site coordinator and how to enable him.

What is ownCloud?

I'll let Frank answer that himself:

You can use it to store your files in your personal cloud storage and access it from all your devices. It will also support versioning, backuping, sharing, syncing and other server based functionalities which are useful additions to KDE applications.

ownCloud is the central exchange point for my data and a companion for different KDE powered devices using the AGPL license.

So there you go. Your own online storage with connectivity to virtually all your gadgets. The benefits are obvious: You don't give your data away as it will still be on your own hardware. That alone is a big improvement over most other online storage systems. I hope my favorite mobile office applications, namely the Files, QuickOffice and iThoughts applications for the iPhone will support ownCloud once it has reached a certain stage.

Help a good idea to grow!

In this article I will present my current tool set of choice for the iPhone.

Word processor and spreadsheets

Quickoffice (iTunes) is pretty much what is claims to be. You get a Word editor and a spreadsheet application. Both natively work with Microsoft Office formats (old and new) and that is all I need.

The user interface for both applications is easy to learn and while the lack of keyboard and mouse does slow you down when editing spreadsheets, the app makes good use of gestures and multiple-tap events.

What I found to be missing however is the possibility to set headlines and other formats. Note that they are displayed and preserved correctly. You simply can't add new ones. The usual text decorations like bold, italic and the like work smoothly though.

You can up and download documents through a WebDAV interface. The MobileMe iDisk online storage is also supported but that isn't for me - I value the privacy of my data.

Strangely there doesn't seem to be a straight forward way to copy a file. You have to open the original, make a subtle change and 'save as...'.

Overall Quickoffice let's me get my work done and does it in a rather effective manner, for an ok price.

Aside from the 'pure' office functionalities Quickoffice supports a number of other file formats including images and .pdf, for which it provides readers/viewers. While rounding things up nicely, these readers lack some of the oomph that the Files app provides, see below.

Mind mapping

I can't exist without mindmaps. To me they are the organizing and structuring tool of choice. On the computer I use Freemind, because it is open source and it's many keyboard shortcuts make creating and editing a mindmap really fast.

There are many mindmapping tools for the iPhone but I believe iThoughts (iTunes) is a clear winner here. It supports virtually all major mindmapping formats and makes clever use of drag and drop on the iPhone. Nodes can be individually styled and highlighted with icons - important for me for additional grouping and priorisation.

Once again, files can be up and downloaded through a WebDAV Interface or through an online storage service, in this case box.net.

Same as above, mobile storage doesn't work for me and I believe it shouldn't be an option for any business use. Your data simply isn't save.

Generic file storage

The Files application (iTunes) is a WebDAV accessible storage medium on your iPhone. Think of it as a WiFi stick.

You can set up a quota how much space on the device Files can take up and security is provided through an access password.

Note: It can savely be assumed that the content of the storage remains unencrypted, the password most likely serves only as access prevention.

What I like about Files is that it supports reader functionality for most common formats, including .pdf, office formats and an image viewer much like the Photo application from Apple.

Offline bookmarks

Instapaper.com provides you with a simple service: You can bookmark websites to read them later, categorize them, tag them, you name it.

What makes Instapaper stick out of their competition is the good integration. Granted, a browser bookmarklet is nothing special anymore, neither is an iPhone app. Make the iPhone app (iTunes) communicate with one of the most frequently used Twitter clients (Twitteriffic) and make that communication both ways and you have created a huge amount of added usability right there. This is what Instapaper did. Tweet your latest finds right from the Instapaper app. Push articles from the people you follow into your Instapaper list without changing the app.

This is what I do - each morning during breakfast I add all potentially interesting links from Twitter to Instapaper, update the archive in the Instapaper app and I'm ready to go, able to read those articles whenever I want and indepepdent of network availability.

Summary

With Quickoffice, iThoughts and Files, there are three applications that bring their own storage logic and their own WebDAV interface.

It would be great if Quickoffice and iThoughts could team up with the guys from OliveToast (creators of the Files app) to utilize their storage for easier maintenance.

A very similar cooperation is already in place between Amidio and Intua, both creators of top notch music creation and sequencing applications for the iPhone. You can record a sample in one app, i.e. Hexatone or Noise.io, then fire up Beatmaker and load that sample through a common storage to sequence it with other samples. Recently that was simplyfied even further: Now you can copy-paste samples between the apps using the iPhone copy-paste logic.

Doing this for the office apps would greatly increase productivity.