News in project management software

More Teamwork – Twitter integrations

Forthcoming Teamwork 4.3 will include among many new features, a richer Twitter integration, extending the existing worklog import/export functionality.

In the picture on the left you see how you can use the tag field to send any issue to Twitter, similarly to delicious. So not only worklog can be sent back and forth between Twitter and Teamwork, but you can send specific issues and worklogs actions to your Twitter account, and also send sticky notes in copy to Twitter, eventually as Twitter answers (“@user”).

In the case of issues, to send the description to Twitter just add “@twitter” in the tags field.

In the issues’ worklog action, put the “@twitter” at the end of the action.

When sending a sticky, you can “CC it to Twitter, as in the picture. Notice that the checkbox “send to Twitter” will appear only if you have enabled Twitter in your user options.

In case you are sending the sticky to a user with Twitter set in options, it will be sent to their attention.

Actually the worklog action trick works anywhere you are writing actions, not only from the issue list, as shown above.

Twproject webinars

Teamwork webinars now available — Twproject webinars now available

We have just activated the possibility of delivering webinars to customers to remotely supply instruction from our instructors. This is at a fraction of the cost of a bootcamp, and may be all you need. Details can be found here:

https://twproject.com/services/

Open Lab’s new blog

Open Lab, the software house producing Teamwork, has a new blog here: http://blog.open-lab.com, on the first post we explain the significative positive evolution that we are going through.

“Adding a wiki” to Teamwork

The meaning of “adding a Wiki”

The most voted request on our feedback service is “Integrate a wiki in the dashboards”:

I think that what actually users mean is “integrate Wiki functionalities in Teamwork”, but this is one of the requests that can be interpreted in several different ways: it probably implies a feature set, and some of such features make sense for the Teamwork context, and some may not.

Some example features:

Let any user have a portlet on her home page that is actually the home of a company Wiki
Let people edit any Teamwork page layout of in a Wiki way
Have for any object a history of changes on that object
Use Wiki syntax for any content
Pages are created by just creating links to them

A different, more radical interpretation could be “change completely the management philosophy and let there be no user rights and pages and contents be just contributed by users”. In fact there are even applications for issue management that actually are just a wiki. Well now, I think that it may be useful to try to clarify what is the usefulness of work management software. It must be something that makes you work better; it’s quick to insert the essential work data, and that done, it does a lot of work for you. Inserting work data in a Wiki just doesn’t give any specific support. A Wiki is meant as a tool to manage a documentation body contributed by several people; that is just not what work management is about; and using the wrong software for the just, will just increase confusion in your company, make people frustrated and make them waste more time. Wrong software, sorry.

Implementing a Wiki engine

This does not mean that the Wiki’s logic can’t inspire some really good ideas that can be included in any kind of software. This is the perspective that we’ve taken on the “Wiki integration” subject, and there are many subtle problems involved, like:

If you want to write contents with links to objects, it would be nice to have a RESTful API in Teamwork in order to write links simply
Should we use the TinyMCE editing which we started using in some places (and users are pushing for more), or switch to Wiki syntax in contents?
Up to today documents are typically linked in Teamwork, but contents lives outside (and this is generally a wise choice), but with this extension it should become really nice to write contents in Teamwork for specific projects

Given the deep integration of the Wiki features and Teamwork’s, we are building our own Wiki engine; its persistence is Hibernate based, and there is none available that does that, so this may become of general interest.

One of the considerations that convinced us to write it from scratch is that several Wiki applications functionalities are already available in Teamwork, often more refined than those built in Wikis. Like full text search, subscriptions and e-mail integrations and recent pages.

If you’d like to suggest some particular feature of the Wiki integration, you can post it on the feedback service (yes, we do check it out).

What you get with Teamwork and what you don’t

Some project management applications provide minimal functionality: just a Gantt drawer. Some, more groupware oriented, provide a vast spectrum, including e-mail and chatting. While developing Teamwork, we made several choices about what to include and what not. The choice for Teamwork has been guided by this simple princliple: include only what will not sharply conflict with acquired user habits, and will have a rich integration with the rest of the system.

Examples of what we did include:

– “boards”
– sticky notes
– to-dos
– a calendar

All these have a natural integration with project management, bringing together personal and team management. So we put them together in a unique, integrated solution; you don’t have to get three separated products from us to get this functionality.

Examples of what we didn’t include:

– e-mail client
– chat services
– file management

The three integrations above are probably used by most in standard ways, and happily too: you are not going to change those user habits with the new project management software; so the work we have and are doing is to integrate with the existing applications, as smoothly as possible.

Notice also that probably most users already have a calendar application, and others that may overlap with what we provided built-in, and for that we are working so hard in extending seamless integrability (most previous posts talk about this in fact).

Current and future developments

Wikipedia logo

This is for the actual situation; but usage of the web is evolving all the time, and more integrations are now needed: in Teamwork we always assumed that the contents and documents related to projects and work which would not be articulated in tasks, issues and to-dos would be handled by other document management software, and then somehow connected to projects (say for example with file storages). But with wiki and blogs, content is more and more inserted directly online, and we should support this also inside Teamwork. One can currently do this by simply creating custom portlets connected to a Wiki service. But as with most of our solutions, we would like something organically integrated with the rest of Teamwork functionality; for example, content editing would naturally blend with exposure of Teamwork objects to REST and similar services, and in-place customizations of pages. So this is one of the (non trivial) directions we are now exploring.

If there is an organic integration that we are missing, just post it on our feedback service!

The quoted products, services and images may be registered
trademarks of their producers.
Images that require attribution are linked to their source.

Integrating Teamwork calendar with the iPhone

In theory, being Teamwork integrated with the iCal format, it has always been possible to sync it with the iPhone, just like with Outlook and Google calendars. But as often happens, things turn out to be more complex, in particular if one wants to get a not only working, but also a comfortable solution. So we added generation of “.ics” urls, and now on the beta of the forthcoming (next week) release, our internal iPhone fanatics have syched calendars with our internal Teamwork application, which of course is also exposed on the web, so that one can sync both on wireless intranet access and on the web.

So check out next week release, it will be a free upgrade as usual for all Teamwork 4 users; the online users will get it without any kind of effort 🙂

Thanks to Federico Soldani, a new Teamwork employee, and some of our customers, for pushing for such integration.

Setting up a Teamwork calendar in an iPhone

The quoted products may be registered trademarks of their producers.

Third party integrations speeding up

There is a increasing trend in getting more and more contributions from third parties to Teamwork – which is great news for us! Just received a Polish translations, will soon release a Teamwork plug-in for Thunderbird, and there are at least two software houses that will use Teamwork as a module in a more extended application suite. We are building a dedicated section on the web site for contributors, you can get previews on Pietro’s twitter stream here 🙂

Simplistic cost/benefit evaluations of organizational tools adoption

SDY1

I’ve recently received yet another request of a cost-benefit analysis given by the adoption of Teamwork, in general, of project and groupware management software. Not always in those exact terms, but we do periodically receive such requests. One may rephrase the question as “what is the exact economical gain given by adopting Teamwork”?

Very superficially, this looks like a clear question, which requires an exact answer. Let’s take a closer look.

What does it mean “adopting Teamwork”? If one takes even a cursory look at Teamwork user guide, one should quickly realize that for a tool that can integrate at so many different levels with IT infrastructure, this may mean all sorts of different things: one may be handling just high level projects, sharing them on the web, or one may have integrated it from intranet authentication and certification forms, following every little action in the company.

One may be using the exchange function with Subversion, Google calendars and Twitter, so even the boundaries between what is done in the company by Teamwork and what is done by other applications is blurred. So “adopting Teamwork” has different meanings for each adoption process.

But there is an even bigger conceptual mistake that is lingering here, given by the first part of the question, “exact economical gain”: i.e. that taking steps in improving quality of work, by implementing software aided organizational procedures, is a purely economical gain that can be accounted for say is a year after the reorganization. Anybody that has experience in reorganization and working on quality of work and communication knows that consequences cannot be evaluated so simplistically, though they can be great, and span an entire work life.

This said, the benefit that one will have basically depends on the plan and determination of the leader that is introducing innovation, by her/his culture, open mindedness and experience in the field and in human relationship, and the respect that she gets from the team; and we believe that in some cases (not all), Teamwork can be of help for such individuals, more structured help than just a to-do list shared online. But don’t ask us to fool you with numbers thrown at random; you should probably be very suspicious of vendors that promise X% “gains in efficiency” by doing this or that. Our customer list is partly public, the best way is to ask them, and everybody will give a different answer. Just my two cents.

Pietro Polsinelli

Notes on usability, game mechanics, and Teamwork’s evolution

Introduction

The work documented in this post was ignited by receiving the first video tests from usertesting.com and other sources (by the way, Usertesting supplied valuable feedback for a very cheap price), and about at the same time watching a video where Amy Jo Kim from Shufflebrain does a great and inspiring presentation showing how some game mechanics are used by successful social software.

Motivation

Teamwork 4 was realized after studying several texts on usability, and even inventing new techniques, see for example

Smarter search and recent object functionality

Managing with lists vs. managing with trees

But our internal speculations lacked the ideas that may come from an independent fresh look; we received a lot of positive feedback from new users of Teamwork 4, but the problem is that those that do not understand your software, don’t usually give you feedback. So we submitted Teamwork 4.1 to several testers that were first-time users. Then, looking at the testers’ video, these were full of surprises, and quite… painful to watch! Poor users!

Putting together feedback of the testers and the idea of the prime importance of positive feedback from the software, in particular in early usage phases, we designed a new release of Teamwork which we hope should be friendlier for both the first starter and the daily user. Here we document some of the differences. I hope that being this a concrete example of usability evolution, it can be of some interest for those who are working on web application usability in general.

The criteria which we used for evolution of the interface have been inspired also by Amy Jo Kim’s work from Shufflebrain who in this presentation shows how some game mechanics are used by successful social software, and this may inspire in general who is designing any kind of application:

Putting the Fun in Functional: Applying Game Mechanics to Functional Software

This is filled with interesting ideas and observations; to me what results more interesting is not so much the extrapolation of the specifics of game mechanics, but looking at ways to involve with feedback the user in its first steps in your application, and then guide the evolution of it. It is clear from the speech and Q&A part of the video that she has a wide usage and behavior culture which is only partly expressed there.

Limits of game techniques

Looking at human beings as reacting to behavioral stimuli is taking an extremely partial view, which has little explanational mileage, but not zero.

It is true that games tap in primal response patterns; but that is also their limit, at least for games that use proximal metaphors (body movements) and not reasoning, collecting, quantifying. Collecting and quantifying means inserting strings and numbers; something at which Mario Bros. like interfaces are vary very bad at; like using the iPhone keyboard for a lot of data input. But collecting and quantifying is what is most important for a huge number of applications, and where the proximal metaphors simply won’t help.

In playing games, often the player is happy to use “low level” skills; in planning work, not so much. That is also why simple stimulus – response – reinforce metaphors can be effective in gaming, advertising, but not elsewhere; we are not (fortunately) always that stupid. It is surely false that the most powerful way to manipulate human behavior is to do a variable response schedule: a good argument to a responsive crowd can do better than any behavioral proximal stimulus. But that would take us far, on the failures of behaviorism (this is old stuff from the 50’s). Still, when the users of any software are in their first steps, the response patterns of the application matter a lot.

On the Business of software discussion group I’ve recently seen a discussion on a tool for visually collecting bookmarks. The developers chose to develop a desktop client before developing a browser plugin (!); this to me is a clear mistake in adoption path strategy, which does not consider the critical point of lowering the adoption path as much as possible for such a secondary tool. Seeing collecting bookmarks as a “game played in the browser”, makes it immediately that the separate client idea is disastrous!

My point of this section is just that the gaming metaphors can help, but in limited forms and cases.

Examples

The task given to the testers was this:

enroll to demo
create a project
assign yourself to it
create a resource
assign it to the project
create a child task
create some issues
register some worklog
search for a task
create a to-do

Going through this, they met some difficulties, which we tried to overcome, and we document all this in this PDF:

TeamworkUsabilityExamples

(1.5 MB – lots of screen shots).

Some ideas in the PDF can be generalized; additional “behavioral reinforcement” tricks which we put in place:

Whatever first tests the user does, he makes a % increment
the “user score” (which was already there) has been structured in “badges” (which in our case are balloons of different color)
operators are associated to a “color”: so say sticky notes coming from them are immediately distinguishable

N.B. The changes to which we refer are not released yet (May 13th, 2009); the demo and the downloadable version are those before changes, the new release (Teamwork 4.2) will be available in a couple of weeks.

Additional references

The World’s Largest MMORPG: You’re Playing it Right Now

Teamwork weekly news: in Russian, in French and friendlier

We are currently intensely working on release 4.2, which will be a free upgrade as usual. Some of the new features that will be included are

translation in French
in Russian (!, thank you Kostantine),
maybe also Chinese,
a new start page,
a new feedback messaging system,
an empowered meeting management.

In the meantime we also refined our Tomcat configurations on our hosting farm, to make it even faster.

Teamwork webcast #3

Teamwork webcast #3 In this webcast Silvia Chelazzi and Pietro Polsinelli take a look at the requests in the feedback service, which was launched together with Teamwork version 4. Completed, declined and open requests are examined. Also the connection between feature requests and Teamwork development is discussed, with a reference to this blog post.

We’d be happy to get feedback to our feedback on the feedback.

See the webcast on Vimeo here.

Suggestions for topics that the webcasts should cover are welcome: use (of course 🙂 ) the feedback service.

See all webcasts introductions here.

Twproject, MySQL and UTF-8

Teamwork is MySQL partner.

This is a technical post about tand its databases.

Many Twproject customers use MySQL as database for their data; Twproject as web application supports UTF-8, which means that you can insert data in practically any language; but of course to save such data you need support along the “entire trip”, so your database must support UTF-8 data too. Now unfortunately MySQL default encoding is not UTF-8, but we found a way to work around that, which will be released with version 4.2: the Hibernate schema script generator will create UTF-8 encoding tables, as UTF-8 is supported also at table level (supported by MySQL 5), so it will work in all cases.

This is done by simply extending the Hibernate MySQL5InnoDBDialect with

@Override
public String getTableTypeString() {
return ” ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE utf8_general_ci”;
}

as suggested here.

Remember to use MySQL 5 with referential integrity on and to end you JDBC url with “?useUnicode=true&characterEncoding=UTF-8”!

This is particularly important for our future Chinese customers, now that a Chinese translation is forthcoming.

The future of Teamwork

Well, first of all, does Teamwork have a future at all? Well, version 4 has now been out for almost 3 months, and it is been an outstanding commercial success, with a growth of about 400% with respect to the same 2008 period; in countries like Germany and Turkey our growth is really impressive, and in not exactly the best economic times. Aside from sales, it is the users and reviewers reaction that has changed drastically with the release of 4, they like not only the power of the application, they like the usability and user interface. So our great effort in this direction was not wasted 🙂 : we always got positive feedback about the power of Teamwork, but rarely about usability. The feedback service and the Teamwork error reporting are working great, and thanks for all the feedback received!

Having the money to support more and more development opens great possibilities, and we’ll keep the policy of transparency of our plans, so you’ll just have to read our blogs and twitter streams to know exactly what we are doing and intend to do. It’s also a good feeling knowing that Java is not going to “die” any time soon, now that Oracle and Sun are merging. Good vibes come also from the NGO which we are helping with free licenses, and Teamwork is used as teaching tool in really a lot of universities.
Other nice effects of the release of version 4 are that we have a number of software houses working on plugins on the sources, and this adds to the already unique spectrum of IT and applications integrations.

Now the usability considerations do not yet apply to all sections of Teamwork 4: like the business process module can now be proficiently used only by power users, that are not scared by hand editing of XML files, but yet that too is used in quite a number of cases.

So of course in Teamwork’s future you will see a lot of work done on both usability and features. The version currently in production is 4.2, and we also have some plans for future versions.

Usability

A very practical and convenient way to test usability is to use the usertesting.com service; from this feedback we collected a lot of suggestions, which are currently being developed and will be released progressively, most already in 4.2. Some things which we thought were now easy to use, actually are not, and mostly for the first time user; we improved from version 3, but still the beginning part has some obstacles which could be removed.

We also got some good suggestions by watching Amy Jo Kim from Shufflebrain work on positive feedback to the users, see Putting the Fun in Functional: Applying Game Mechanics to Functional Software; we plan a future blog post with more details. We just became aware that the fact that version 4 gives more “positive feedback” to users is probably an important factor of its success. Already 4.2 will be more reactive, we hope even more fun.

Features

The main features in production for version 4.2:

usability and feedback, better start pages
issues extended with tags (which should give a partial answer to this request)
French translation
meetings will support separate minute per discussion point, and will be generally improved
Subversion support will be updated to latest versions
Microsoft Project import/export will be done using the MSPDI format, hence more Project 2003/2007 compatibility

We also have a project for future versions, which is not in production yet, but plans are being proposed. Some ideas concern wiki rendering/editing of all pages, and a web service API.

Project management software evaluation, do it right!

Long list Evaluating Project Management software is a delicate matter, as it potentially involves changing deeply rooted companies’ habits; in general, this holds for all work management software. Being the subjects of such scrutiny, we experience that most companies fortunately take the right way right from the start, which is, trying the software, inserting in it some real project and people data, and seeing whether it works. In the case of Twporject, this can be done quickly, and there is both a demo online and an easily installable version, and considerable support readily available online to all.

But unfortunately not all companies take this “hands on” approach: some take the path of putting together list of requirements, and instead of testing the software against those, ask the software producers “whether their software meets these requirements”.

Now imagine that this was the way you chose to buy a house: you went to the seller, with a list of features, and you never go to actually see the house. You buy it because the seller tells you that the house fills your requirements. Nobody would do anything so foolish, no?

Putting together requirements and testing the software against them is actually a good idea, if handled properly: testing will at times show that the requirements are contradictory, or need refinement, and that the software models problems actually better than how imagined in the requirements. This is not surprising, as widely used software includes a lot of experience in management, often more than the users have. So the initial requirements should be only a first indication, and not something that is the main criteria for the final choice, which should be led by the usability and coverage or real problems offered by the software at hand.

Unfortunately there are producers of PM software and consultants that encourage users along the foolish path: they give formal answers to formal requirements, do demos themselves instead of letting the customers do that, make phone calls to facilitate over-priced sales, and all the usual bad practices.

Well, we don’t do that. We concentrate all our energies in developing a better product, and in producing publicly accessible documentation; we want customers to have software that really works and is usable, not just to close formal deals.

One can make software that satisfies long lists of requirements, but is totally unusable, will be hated by users, and will lead to user rejection, and hence to a huge waste of company’s money and people time. We really hope never to take that path.

Silvia Chelazzi - Pietro Polsinelli

Oh no, not another Scrum tool!

: Image from Flickr – attributed following link.

When we came back to Teamwork version 4 after reviewing some literature on agile methods, and in particular re-considering the Scrum perspective, it became progressively clearer that mapping Scrum ideas to this or that functionality of a software is inevitably a simplification and maybe even a betrayal of the agile philosophy: as these methodologies concern the way you approach problems, and have great variations in detail when it comes to each particular case; see

Agile Project Management with Scrum by Ken Schwaber, Microsoft Press

which is filled of examples.

From this perspective, the main point is not and should not be the management software you are using. We’ll get back to this in the final considerations.

We’re assuming here familiarity with concepts from agile methodologies and Scrum. Also the examples are tuned to software development, but the line, if valid, is valid in general.

Mapping examples

If one does decide to use a management software to manage agile procedures, one should be careful not to take simplistic decisions.

Consider for example backlog: collecting a backlog is the most basic step; how do you collect the backlog? It may be say a shared Google document; so from the PM software point of view, your backlog is a non structured document that the software does not manage. It may be a set of separate entities, say issues? It may be made of tasks with detailed descriptions and work estimations; and so on.

In many examples of teaching Scrum we see cards sticking on boards, and some software just use that idea for the user interface. People seem simply to be missing the fact that a development project may simply have like 800 “cards”. How the heck am I gonna stick those on a board??? It can’t work. You need something more flexible and powerful than a concrete or digital board.

Stand-up meetings: why is backlogging the subject of management-by-software and meetings aren’t? This is a typical and mistaken hacker’s perspective, because some people focus their management more on their agenda than on their to-do list, if they have such a thing. And you will have projects with both kinds of people (and many more).

Why recording the activity on the assigned tasks has to be done by scaling down hours on the selected items of the backlog? Wouldn’t it be more practical if say one could record activity in the Subversion commits? Or in your Twitter feed? Here too, you need an open ended tool, which collects data from many sources in different ways.

An example: let’s see a sample project and assignment structure: suppose you have a customer, a lead developer, and a set of developers, D1, D2, D3; you want to collect the backlog, and basically your main aim is to let the developers work in quiet conditions and with a stable set of requirements for a month. Well to model that in Teamwork is no big deal, you can support this procedure in several ways; for example you may have a root project ROOT, on which everybody is assigned as “reader”, and lead developer as project manager; you have a child BACKLOG, where the customer is assigned as “worker”, so she can contribute inserting backlog; the backlog is inserted as issues on this BACKLOG task.
You then create a new ROOT’ child task called FIRST SPRINT, move the subset of issues which constitute its effort to it, and assign D1, D2 and D3 as “workers”, so they can edit and close the issues, but nobody externally will change the set of issues. That’s it.
On this structure, Teamwork gives you many, many, many tools to go on, work comfortably, connect this project with others differently structured; it may even be a child of a completely different structured project. You may structure the BACKLOG task itself as a tree; you may have several sprints going in parallel; you may have after the spring a workflow of approval, and again here Teamwork supports you with task as processes. More examples could be made.

Final considerations

A most important consideration is that particular methodologies, say Scrum, help solving some class of problems, but will never cover the totality of the working activity of a company, not even the totality of projects of a company. Actually, the original Scrum texts are written in full consciousness of this limitation.
So it would be extremely non-agile to have specific software to follow the “agile” projects, and another one for the “others”. And even the “agile” projects will have so many variations, that they will fit in the agile metaphors at different levels, and hardly fit in a single “Scrum software model”.

So in the end we realized that the mapping between the methodology and the software (or paper) requires great flexibility; agility is in the methodology, not in the software. If you want to use a software, it should be flexible enough to let you map projects, tasks, issues to people and customers, in infinitely many different ways, but so that all data from the different projects and methodologies ends up in the same place.
So no, Teamwork is not yet another Scrum tool, it is a management tool that can help also those that decided to use Scrum for some projects, if they don’t prefer to use paper cards 😀