- 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 😀
Some context: Scrum ( http://en.wikipedia.org/wiki/Scrum_(development) ) is a methodology for software development (but not only) belonging to the agile family ( http://agilemanifesto.org ), which is a set of methodologies which was a direct response to the dominant project management paradigm, waterfall, borrows many principles from lean manufacturing and was formalized when 17 pioneers of the agile methodology in 2001 issued the Agile Manifesto. If you know even a little about Teamwork’s approach, and take even a cursory look at the agile principles, you’ll feel a family resemblance.
Scrum is not just about software development: see A real-life application of Scrum outside IT http://www.scrumalliance.org/resource_download/548 .
An interesting story on how Scrum cannot be applied in so many contexts, and the Kanban alternative:
http://blog.crisp.se/henrikkniberg/2009/04/03/1238795520000.html
It is said that Agile’s success is rooted in its ability to embrace change and thrive on it; now, again that is a reason why your tool should be extremely open and flexible, supporting real time information recording and change in work structure.