news in project management software

Recent progress in Teamwork development – towards 4.6

Well, first of all let me say that Teamwork 4.5 has been a great minor release; I have to call it “minor” as it has been and it is a free upgrade to all users of version 4 even if it was actually a “major” release according to the number of features it introduced.
The long list of functionalities has been highly appreciated by our users and thanks to them and their feedback we are now working to improve some of them.
Thanks to our forum through which we provide free support we are constantly in contact with our users and their problems in managing work giving us the possibility to help them and, at the same time, collect suggestions and bug notifications.
All this feedback is now “put at work”.
Some examples:

We are improving new editors in place (which replace the pop-up screens) in order to be visible also at lower resolutions.
We are improving the usability of the operator load and plan, trying to make them more intuitive.
The new release will have several performance improvements.

This new release is under development so you have time for suggestions or bugs notifications:
http://answers.twproject.com/
Stay tuned.

How do I begin project management?

In “Making things happen”, the author (Scott Berkun) states that he assumes that the reader is not stupid, is curious and pragmatic, does not like jargon or big theories, and does not take herself, software, or management too seriously. Well, we do the same in Teamwork.

Still, you may have no or little experience in managing team work. Whatever work you will be doing, you may have some requirements, and some dates. if your company has no notion of project / task / issues, you can start this way: list all the things you are doing in your organization. You could separate internal work / external work. In the list obtained, group dependant activities: each group can be called a project, and the people that should work on it are the assignees.

You may notice that when you are listing “thing that we are doing”, you may also include “things we should be doing”. Notice which of these are stated in the form of concrete actions, like “call X”, or “write Y”, and which are still to be transformed in actions. You should try to transform everything into actions, and get rid of the rest. And still among actions there are simple, brief ones, and others that group many others: you could model the simple ones as issues, and the ones comprising others as tasks (that is, projects which are child of other projects). This is a start of management.

Often we get asked by people evaluating Teamwork:

How do companies really use Teamwork?

In the new user guide you will now find several examples. Here are also some good books where to start learning about personal and project management.

Some reference books:

This book by Berkun is our main reference:

Making Things Happen
Mastering Project Management

By Scott Berkun, publisher O’Reilly Media, 2008

http://oreilly.com/catalog/9780596517717

From a personal productivity perspective:

Getting things done

By David Allen

http://www.amazon.com/Getting-Things-Done-Stress-Free-Productivity/dp/0142000280/ref=sr_1_1?ie=UTF8&s=books&qid=1273848829&sr=8-1

On the Agile/Scrum theme:

Agile Project Management with Scrum

By Ken Schwaber

http://www.amazon.com/Agile-Project-Management-Microsoft-Professional/dp/073561993X

Stories of work management

In Open Lab we’ve been developing Teamwork and consulting on project and work management software since 2003.

Every time we got in a company with our software, we had planned to show how the software worked, how to optimize its configuration, how to integrate it with existing software. But we actually did so in the last moment of our visit, if ever.

But when we got in we always ended up in meetings after meetings where the topic was not specifics of Teamwork, but questions of work management, and how to best “map and structure” these, so that project trees, sets of issues, workflows and so on could be used in a coherent matter.

And we’ve learned a lot about which mappings work, and which not.

This need for conceptual mappings is teaching something, that is, where is the real value for the customers, what users need.

We progressively realized that the value of software like Teamwork can be simply in the introduction of more structuring, more quality in work. This can be much more than actually using the software – taking it to the extreme, one could simply read this guide, reform practices in the company and forget about the software 😀

And more people and companies we met, more we appreciated the way we had structured Teamwork from the very beginning to be very, very flexible. A group of fashion designers, a company doing production, a team of software developers, an IT group, hardware engineers, event organizers, all these have different needs. And these groups may be in the same company, and different models need to co-exist.

Meeting diverse needs made Teamwork evolve so that it is an even more powerful mapping tool. Though it is extended, it still is an organically integrated tool.

Modeling company needs for organizing work always implies going beyond the scope of a single application: Teamwork is always used in an applicative context, and so its openness to external integrations is something that in our concrete experience has made a successful adoption possible.

In the user guide for version 4.5 you find also some of our experiences of “map and structure”, some gained by “boot camps” in companies, some by giving web support. You also find the definitions of some concepts related to work management that are not directly linked to software usage.

Some say that all companies need is a to-do list; this is for us just a symptom of scarce experience in what people do at work, of how complex are the needs of a productive company. We hope that the new guide can be of help in understanding which map best fits your organization.

Some of the stories titles:

How do I begin project management?
Managing with lists vs. managing with trees
Overcoming opposition
A critical moment: change
Migrations
Public projects
A design & production company
To Gantt or not to Gantt
Social tools for work management
iPhones for all
A distributed research group
Agile methods
Working by “pomodoros”
Kanban like management
Simplistic cost/benefit evaluations of organizational tools adoption
Worklog validation
Deep IT integration
Work management and games
How Teamwork is made with Teamwork
Teamwork and multilinguism
Business processes
Help desks
Company structure
Different Teamworks, same data bucket
Teamwork and your company’s worth

A critical moment: choosing or changing a project management tool

Healthy companies, groups which are self-critical tend to periodically reorganize themselves. It is an opportunity to improve both productivity and quality of work. In these moments, software surveys are done to select new software for project and more in general work management. It is in these phases that sometimes Teamwork is chosen. In the choice what most matters is how the software can “unobtrusively” map to the new organizational practices, and Teamwork in this can be great, because of its flexibility, scope, and the wide fit to the IT infrastructure. All this is explained in detail in the user guide.

Now it frequently happens that some software houses (which are about 8% of the companies that use Teamwork) like Teamwork so much that they consider distributing Teamwork themselves to customers, and contact us for that; we always say “fine”, but none has been very successful, and this is quite easily explained: if you have say 20 companies to which you provide software services, what is the chance that that very company will want to buy Teamwork?

About 2% of the companies that visit Teamwork site get to try it; and about 2% of those that try it get to buy it. And consider that all those companies are already in the critical situation of choosing a PM tool. So calling a company at random, what are the chances that they will be searching right then a PM tool? Slim, very slim. And the chances that Teamwork will fit them? 2% of 2%. So how many companies will you have to contact in order to have a good chance of making one sale? Many. Too many.

All this because in this scenario we are not using the power if internet of being found, instead of contacting known ones. If someone wants to offer software like Teamwork to customers, the best idea is to get a good presence on the web, maybe in a localized / specialized part, so that companies in search of PM solutions can get competent help. Just my two cents.

Teamwork is made with these books

A blog post on the books in Open Lab: http://pietro.open-lab.com/2010/03/01/some-books-helpful-for-product-development-and-marketing/

Download Teamwork ready and running in a VMware

Not all companies have Java expert IT admins. And even if they have, most companies don’t have time to spend in installing evaluation software. Well, a simple solution is to use online demos. But in the case of Teamwork, this can mean limiting the evaluation, as many IT-integration tasks cannot be carried through using the online demo, and also all the administrative tasks are disabled in the demo case.

In order to simplify evaluation and deployment, we have prepared a complete Vmware image – for both 64bit and 32bit servers – which you can download and use as Teamwork server. It runs a Debian operating system with Apache Tomcat and includes a pre-configured PostgreSQL instance.

In order to use Teamwork, you just have to launch the VM and point the browsers to it – no config needed. The only configuration step we suggest to do as soon as your image is running is inserting the free 30 days demo license.

The VM’s download and instructions page is here.

Twproject philosophy: a short story

There were once two brothers and a sister, and they were managers at three companies.

The first brother was called Micro Manager, and he picked the most complex and integrated management tools, which were entrenched in the technical staff IDEs and into all their network activity, so that not a single line of code could be written without it being carefully logged. Not an hour could pass without justifying time spent; not a file could be opened without explaining why. Not a project could be created without designing a 100 leafed Gantt. And after a week everybody hated the system, and then they hated Micro Manager, and everybody was unhappy.

The second brother was called Over Simplify, and he didn’t want any kind of management apart from to-do lists. And everybody just had to-do lists, and for the first week everybody was happy. Then many started having long to-do lists, and some started worshipping them, and instead of working, they were compiling longer and longer personal to-do list. And every list was different from any other, and nobody knew what, when, how, and why, and everything was in a mess. And then they hated Over Simplify, and everybody was unhappy.

Their sister was called Reasonable Modesty, and she had minimal goals, had always clear that what matters is how people work and interact, and that software is always secondary, and should be flexible, not do too much, and not get in the way. She started evaluating Twproject.

Doing better than the usual project management software?

How can we improve Teamwork, and more in general, how can we help people and teams manage their work better and better?

Teamwork today is a stable, well known and widely used application – its sales getting better every month. We are always improving it and searching for new ways to make it better. The feedback given by users through the feedback service and the answers Q&A gives us a lot of ideas.

But people’s way of work change evolve all the time. With software we should try to foresee changes, and in the case of structuring work, be compatible with new ways of working. Now, project and work management is a field where there is a lot of competing software, and new solutions are created quite often. So in the last weeks I checked competitors for new ideas and evolution that would cover the recent trends in ways of working, like for example having the browser as the “operating system” where more and more applications operate, and so in many organizations a considerable amount of activity is on applications in the browser. Yes, of course Teamwork is web based, but one can do much more than that today. New ways of working need new ideas, sometimes radically new ones. Is anyone proposing different models, or reacting to new working ways?

Well, to my surprise, no. The same mistakes are simply repeated, again and again, like trying to “trap” user communication flows and other user usages in the project / work management software; development is done under wrong beliefs like “using e-mail is wrong, and users should be ‘educated’ to centralized communication systems”. Such tasks are destined to fail: it is simply assumed that users will happily and daily spend a considerable and growing amount of time on your specialized project / work management application because of their stakanovistic dedication to organization, which is the opposite of what is happening: people use more and more different, specialized applications for their tasks, and dislike and refuse single, centralized “monster apps” which attempt to replace all others.

In my review of “solutions” I’ve even seen a specific content manager connected to a popular issue tracking system that offers users a blogging platform. Now, how likely is that? How happy will employees be of being forced to blog in that corner of the bizarre issue tracking software instead of using their preferred blogging platform? This kind of ideas just don’t make sense: you have to improve work management without directly impacting software usage, and without trying to replace high quality specialized solutions with centralized (low quality) ones.

We have learned a minimalistic, relational approach and deposited it in Teamwork years ago. Now what about going beyond that? Well, no concept evolution is happening in direct competitors.

So in my search, I ended looking at personal productivity software, after seeing this nice presentation by Scott Hanselman, and there indeed there are some original ideas; consider for example Evernote ©.

The high level of interactivity, openness to devices and compatibility with user habits of this application is striking. The aim of Evernote seems not as much managing work, as simply collecting notes for personal usage. But there is a lot of stuff to look and learn. And many users will start work management from a personal perspective, and then will try to propose it as a shared approach: I believe this is a path that currently lacks appropriate tool support. There is a divide between project / work management tools and personal productivity ones that should not be there. On one side project / work management tools still pursue the centralized application option, on the other the sharing features of personal productivity tools are weak.

So we decided to open an experimental platform where to try and test different approaches to managing work, in particular starting from the personal / to-do point of view. In the meantime, Teamwork will keep evolving and improving, eventually getting new features and improvements from this experimental platform. We will blog about our experiments here in the coming months. If you any suggestion to make, post it on the feedback service: thanks!

P.S. Teamwork release 4.4 should be out in a couple of weeks (a free upgrade to all users of version 4), and will introduce the notion of “public” project – keep in touch.

Open Lab and Teamwork are not associated with Evernote in any form.

Everybody contributes!

One of the features appreciated by Teamwork users in contrast with other web applications for project management is that it is not exclusively oriented to technical users. For example, about 8% of Teamwork customers are software houses, and several of them migrated from bug-tracking oriented software to Teamwork, simply by realizing that there is more to software development than just bug tracking.

In order to facilitate usage and group contributions, a trick to enable issue add for everyone in the project area, even if not assigned to projects, is to simply extend the “operational” role, created by default by setup, with the “task read” and “issue create” permissions. 😉

This was suggested by Roberto and closes a feature request.

Note: the logo on the left is the logo of our “error serving and collecting” new online service which will go in public beta soon: bugsvoice.com.

New multi Gantt support

Forthcoming Teamwork 4.3 release will support a way of “managing a graphical Gantt-type overview of all projects”, actually, more than this: simply any filter on the project list can be seen in a Gantt-like way, and also printed. The need for this new implementation was suggested on our feedback service and got many votes from our users.

Until now the powerful search filter, which lets you compose complex search criteria, gives as result a simple list of tasks. From 4.3 Teamwork will layout the results also in Gantt graphical style. In the picture below you see an example of it.

ScreenShot029 — Gantt view for Teamwork task’s list

In the example above I’ve searched all the active tasks opened after the first of June and with a progress over 50%. Simply picking the “view as Gantt” button I’ve changed the view modality in order to compare the filtered tasks in time.

This cross-project comparison in a unified view is practically impossible (in Microsoft Projects, insert as subprojects etc.) in file-based project management, it is easily accessible in Teamwork instead.

The result of the search will be shown in temporal interval which goes from the minimum start date to the maximum end date, in order to cover all the tasks filtered and to get a global timeline view. Also progress andmilestones are shown. Moreover this page includes the possibility to move in time and to change scale.

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.

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.

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

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 😀

Category: news