Teamwork 3.1 (which we are using internally and will demo at JAOO) will come our ready for SCRUM:




The custom SCRUM home





The SCRUM sprint wizard











The SCRUM team











A burn-down chart








To see the chart, on any task editor go to Edit -> Issue Charts.

Here we are at "Project Challenge 2006" in Olympia (London). We had 300 contacts and made over 50 demos in two days, more then we had done in a year!

People liked our stand, "paperwork" (our graphical material) and in particular our orange shoes; we'll see whether they liked the app...

When a few weeks ago I requested on Teamwork's mailing list and on the forum for some feedback, I had no idea whether I would get any answer. Actually, the first day I got only one answer, which ran more or less “We don’t use it and we are happy about it”. So I wondered whether it was a good idea. But after a few days, feedback started coming in, ranging between fans saying that it is perfect as it is, to constructive criticism. And it keeps coming and coming. Thanks!
You know why it took a few days to start? Because the feedback we get is highly structured: people are sending us detailed excel charts with features, issues, and comparisons, discussed in group meetings. Users of structured software have refined interactions :-)

Among all this feedback, my dear friend Massimo Iacolare, a new born micro-ISV entrepreneur (when is your website coming up Massimo?), pointed to me to these links:

http://www.shmula.com/158/focus-on-the-customer
http://37signals.com/svn/archives2/instore_good_or_athome_good.php

where it is briefly stated the need of "simple" and very specialized software, and that features look good in stores but not when using the apps.

Well, what I can say is that Teamwork is surely good at home; for the good at the store, we’re working on it: we’re "Crossing the chasm"" (for a contextual perspective see the beautiful "Eric Sink on the Business of Software").

Its good at home because first of all the model is good. Differences in interface reflect also differences in articulation of the underlying model; and my claim is that our competitors (in particular those reviewed in the previous posts) have simplistic models. On the 37signals post I found this brutal comment:

Sebhelyesfarku 06 Sep 06
I like feature packed products. I’m not retarded like average consumers.

Well, this is sort of funny, but I am not saying this. A user evaluating work management software can easily confuse the fact that we have to render a complex model, with feature bloating. The fact that Teamwork’s interface is more complex then that of some of its supposed competitors is not due to feature bloat, but to the articulation of the concepts involved. Actually, our powerful interfaces are a sign of health.

Let’s consider security problems for even a medium-small company, say with a hundred employees. I bet that no one can find a single example of such a company where everyone can see all the information floating in the company in the IT structure. But more: there will always be local exceptions to a simple role-based security model, because there will always turn up a particular project that has its own security

Teamwork 2 had a role based security model, further refined by “areas”, which were a way of completely separating say departments, in which the roles could be distributed. There could be users having different roles in different areas. But, as in all fundamentally role-based models, once you had a role, you would have it in the entire area; so once you could read a task in say production, you cold read all tasks in production. So users complained again and again that they wanted a more fine grained security, as fine grained as a single task. And notice that this has to scale with respect to the numbers of projects, users and roles, for example when you do a search, so you have to express this in HQL (or equivalently, in SQL) in order to performant instead of navigating the objects, and you have to comply to the security model, which is non trivial. But for version 3, by leveraging Roberto’s intuition of giving a role weight to assignments, we got all we had with version 2, plus fine grained security; and teams and structured work for free, too.

All competitors I’ve seen so far don’t even reach Teamwork 2’s security model. And any (Team) work management application that doesn’t solve the case of exceptions, simply cannot work. Full stop.

So you must have a complex model, covering 100% of cases. What distinguishes a good model from a bad one is how it covers limit cases. Assuming that your model covers all above, and more, then we can talk about the interface ergonomics; but applications with a wrong model, will not fit the real world, however pretty their interface may be.

Also the reasoning of some competitors for separating applications is leaky. How could you have distinct applications for security and work management? And users are supposed to jump from one application to the other? Not very user friendly.

Interfaces for such applications cannot be simple; but they can be comfortable. And in Teamwork we have and are working hard on this (a page dedicated to “comfort” features of Teamwork 3 will appear soon on the web site). From release 3.0.0 to 3.0.6 the interface has been improved in hundreds of places, but the model in unchanged.
We are working today on showing how to use Teamwork to support SCRUM methodology; even if we studied SCRUM last week, we are almost done implementing it and the model is fully compatible with it.

Sorry for the long post, but I hope our ideas are clearer now. Pietro

What are we preparing for Teamwork future?

First of all we have collected about 200 feature request and bugs since the release of 3.0.0, of which with the 3.0.1-3.0.6 releases we fixed almost all bugs (more then 50) and added several features.

There should be another 3.0.X release with more fixes and a SCRUM module coming soon, together with a documentation video.

For the next major release, considering also users feedback, for the moment we plan:

- MS Exchange server integration
- file server native security integration
- MS project import/export
- services (like rooms) allocation in time with graphical interface
- PDF versions of all print pages
- expansion of the CMS part, with also RSS feeds of news
- text file contacts import
- more paper documentation

Hopes for release are in first quarter, 2007.

I've taken a look at www.teamworklive. com. Little to say here: seems more a tool to set up a community, than anything related to managing work. Its crammed with Ajax, everything moves, reloads… JUST KEEP STILL for a second!
And the object model below? Seems rough, un-engineered stuff: no trees…

Developing like this is a bit like following fashion; but ergonomics has nothing to do with fashion. Like now so many new web applications, they feature big fonts; a few years ago fashion was small fonts. Fonts used in forms should be monospaced, and in display they should be small enough to be readable and transmit as much information as possible on the page. Web applications should be useful in work, not paged like a fashion magazine.

For a dive into nonsense, such applications have RSS subscriptions everywhere: how can a secured, profiled application supply data as RSS, with no authentication? Teamwork will provide company news as RSS; but to provide a task content as RSS seems bizarre.

Pietro

Teamwork’s competitors
By reviewing Teamwork’s competitors, the only one that seems currently relevant is Basecamp (BC), www.basecamphq. com. It seems relevant to me because it starts with a seemingly similar philosophy:

“Projects don't fail from a lack of charts, graphs, or reports, they fail from a lack of communication and collaboration. Basecamp makes it simple to communicate and collaborate on projects”
(from BC’s home page)

We see that we target the same market; we cover a distinct segmentation (BC is for personal – or at most 2,3 people use, Teamwork is for companies), but we will compete anyway. Teamwork covers a much wider set of features; but let’s forget this and compare the two on what they seemingly share.

Testing
After login (“enter” does not move you in the password field, as you would expect), you get in and you see that the interface is inspired by paper layouts. The object model is a simple (simplistic?) view of projects, where there are no subprojects.

The notion of subtask is absent, because it is meant to be dealt with by the "milestone" notion. But milestones are related only linearly, in time; no parallel tasks are possible; how can this model reality?

Don’t even think of doing a filter on search; actually, we couldn’t find almost anything by searching.

Your to-do list can be multiple; it’s funny, because the environment is de-structured, so the simplest features are over-structured.

A typical layout is this:

How could this layout scale? There don't seem to be a search for persons. Companies cannot be organized; there are no departments. Its like moving across a book, where all information is always all printed. But it becomes quickly an A2-sized book, and hence cumbersome to use.

Everything is built having in mind a limited set of data. Well, even a microscopic company like Open Lab has in few years created over a thousand tasks and subtasks, 3000 issues and so on. It is unthinkable to manage this kind of data in the BC interface. Generally I feel like there is a dimension missing. Like Lewis Carroll's flatland, moving around in BC is a problem; in Teamwork there are always the tools to get everywhere else fast.

The subscriptions tab is right in the middle of your management links; but it refers to BC subscriptions! Actually, advertising is everywhere, and is a bother.

In BC, ease of use is got by having software that does little, not by trying to make a powerful program easy to learn. Let’s put something clear: there is nothing wrong in having to learn how to use an application. Do you recall the first time you tried to use Excel? Well, it took some time. Things should be simplified, but not beyond the nature of the problem at hand. By over simplifying the matter at hand, you get an over simplified interface, but that’s not exactly a bright solution. This reminds me the evolution of TV media, where its target gets lower and lower, actively reducing the intelligence of users (I got rid of my TV long ago).

Actually, the fact that it runs in ASP is presented as a feature, but it is a necessity, given the current poor integration capacities of Ruby. We, on Java and Hibernate, have maximized our IT integration capacity.

Minor things
- graphs are not clickable
- accented characters are not sent properly by mail (lack Unicode or UTF-8 support).
- like Teamwork, but even if it is a much simplified environment, and runs on the supplier server, is not exempt from exceptions:

- It is natural for several users to post different posts on a board at the same time; here it is impossible

(and take care as usual to not get into an advertisement page).

Conclusion
They have buzz on their side, which pushes them on even without quality; we have only quality to help us. We’ll see who wins.

Pietro

We are working intensely in these days to get ready for the London Expo for September 19.

This is one of the plans for the stand. We even have a Maya 3D structure for it! Info on the expo at http://www.projchallenge.com.

Among the attempts to set up a "expo" promotion campaign, I contacted in August the EOS team, which organizes




JAOO, one of the world's most important developers conferences.




The guys of EOS have been incredibly helpful, in particular Mai, and they've become.. Teamwork's users!

We will participate to JAOO as exhibitors. See the details of JAOO at http://www.jaoo.dk.