Archive for April, 2009|Monthly archive page
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 in our player here, on Vimeo here.
Suggestions for topics that the webcasts should cover are welcome: use (of course
) the feedback service, with requests as this one.
See all webcasts introductions here.
Teamwork, MySQL and UTF-8

Teamwork is MySQL partner.
This is a technical post about Teamwork and its databases.
Many Teamwork customers use MySQL as database for their data; Teamwork 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

Teamwork staff with JBoss gadgets.
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. Post your ideas on the feedback service!
Teamwork release 4.1.9022
Just two bug fixes: on issue save on SQL Server, and for the plan by resource page. Download it here; the installer will upgrade your web application; the database schema is unchanged.
Teamwork release 4.1.9021

New business process wizard.
This is our weekly patch, which includes some new features and bug fixes. Download it here; the installer will upgrade your web application; the database schema is unchanged. Thank you to all users and plugin developers for the great feedback.
Features
- the process creation wizard is more friendly, and there is better date handling in business processes instances
- sticky notes can now be “pushed” on top
- issue editable list: now the task and resource when clicked get the line to be editable
Minor:
- each user access increases score
- all root pages go in history
- faster time counter portlet
- path to object includes currently edited task
- operator load is filterable by active task status
- technical: Teamwork startups by web xml now using ServletContextListener
Bugs
- Google calendar – single events handled correctly
- IE7 close all sticky fixed
- Portuguese missing some labels
- new assignments from tree or from “add myself” now get the cost set from the resource
- worklog day recomputes difference from total on update
- link to area management active even if not admin
- fixed display of meeting in recent views
- fixed a security bug in filtering: project -> more-> nextmilestone

- While going to a Teamwork Boot Camp in Geneve…
How (not) to evaluate project management software
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 Teamwork, 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!
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
Teamwork release 4.1.8848

Operator load can be filtered by active tasks.
This is our weekly patch, just one feature and some little bug fixes. Download it here; the installer will upgrade your web application; the database schema is unchanged.
Features
- Operator load is filterable by active task status.
Bugs
- Fixed upgrade procedure to 4.1
- Fixed display of meeting in recent views
- Fixed a security bug in filtering: projects -> more-> nextmilestone
- Cleaned web app from various useless extensions, so compiling from source is easier
- Export to Google calendar now compiles
- Fix on ownership on issues
Installing Teamwork via console

A Debian console.
This is a post for Linux-console lovers.
We have done a big effort to obtain a reliable and friendly graphical installer; but still we received several requests for detailed instructions for hand installations in a non graphical environment, as this is often where Teamwork gets installed when out of the evaluation phase. So we provide here complete instructions, taken from the installation guide.
Complete installation by hand
We assume that you have Java’s JDK 5 or 6 already installed, and also a Tomcat running. If you don’t, download and install those first.
We are also assuming that you are not deploying as an unpacked war, as the web app needs to write in its folders, so if you want to use a war, you must use a “unpacked” war.
1. Download and extract the archive version of Teamwork here (zip, gz, or rpm)
2. Take the folder Teamwork, it contains the folders and files shown in the picture.

This is the web app you need to install (you may remove .install4j).
3. Copy the web application inside your Tomcat webapps, in a folder with the name you please, say “teamwork”. You must ensure that it is using JDK 5 or 6.
4. In WEB-INF/config.properties you must write the JDBC connection data and other configurations, an example config for MySQL:

5. In WEB-INF you must also create a file lic.properties file in which you paste the evaluation license, for example
# BEGIN TW4 ACTIVATION KEY – COPY FROM HERE ON
custCode=SAMPLE
expires=04/05/2009
licenses=10
enterprise=no
license=823CUM1C7F5FD29F55D3211448746KZ36235A1425E80452
# END ACTIVATION KEY – END COPY
The license can be generated any time here, by clicking on “Generate a free evaluation key”.
6. This done, you may launch the web app; if you did the deploy operations while Tomcat was running, you may need to restart the web app. If the JDBC configuration is correct (this is most frequent mistake), the application will start, create the tables and insert sample data; you may now browse to the web app and you’ll be asked for login.
7. DEBUG If the web application “started too soon”, and say the insertion of sample data failed, open
Commons/settings/global.properties
remove the lines
SETUP_DB_UPDATE_DONE=yes
SETUP_NOTIFIED_ADMIN_WIZARDS=yes
And restart the web app.
8. Remember to set the repository, file storage, indexing etc . paths in the admin pages.
If you are deploying under JBoss, take care of the Hibernate (including Annotations and Search) version you are using, Teamwork provides its own, and it must be the same.
Teamwork 4.1.8786
A small patch release fixing enabling LDAP authentication; also some improvements in printing tasks, closing time counters and removed French as translation is not complete yet. Download it here.
Leave a Comment


