“Being Agile” is like “being in love”. No guarantee that it means the same thing to any two teams.
Seen on Twitter from “jasongorman”
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 Twproject’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 .
Kanban: On Wikipedia:
http://en.wikipedia.org/wiki/Kanban
Compared with Scrum:
http://www.infoq.com/minibooks/kanban-scrum-minibook
“Kanban uses a visual control mechanism to track work as it flows through the various stages of the value stream. Typically, a whiteboard with sticky notes, or an electronic card wall system, is used”
When we came back to Twproject 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.
In our experience success and productivity in work are linked to how you deal with two sides of work management:
- Modeling carefully the complexities of your work environment – and here obviously Twproject serves you beautifully
- Bringing this complexity to something easy, light and quickly manageable and updatable by the single user.
Most of the ideas surrounding “agile” management and “getting things done” revolve around this process.
Mapping examples
Figure 3 Burn down chart with Twproject
If one does decide to use 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 ToDos? It may be made of projects 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. Only in some cases a board can be used – and now Twproject has the Kanban board to do just that – see 4.5 Bulk management, 4.6 Organize – Kanban – Planner.
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 projects 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 Twproject 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 Todos on this BACKLOG project.
You then create a new ROOT’ child phase called FIRST SPRINT, move the subset of Todos which constitute its effort to it, and assign D1, D2 and D3 as “workers”, so they can edit and close the Todos , but nobody externally will change the set of Todos . That’s it.
On this structure, Twproject 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 projects 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 Twproject supports you with projects as processes. More examples could be made.
Final considerations on Agile
You can watch the video tutorial, or follow the instructions below:
Figure 4 Kanban-like Todos management
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, phases, ToDos 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, Twproject is not yet another Scrum tool, it is a management tool that can help also those that decided to use Scrum for some projects. In particular we have several tools that will help tracking statistics directly in the project details page
Mouse over the stats to get more info.
You access the burn down graph by selecting “burn-down graph” in the black sidebar:
The graph generated is useful if estimation and worklogs are being inserted during the projects life.
Notice that there are two scales, on the left and the right of the graph, one for the work hours, one for the open Todos .Burn down graph is not supported in Internet Explorer – for this functionality use anotherbrowser. And on the lower part of the page, we get several pie charts representing the current state of Todos and how it was at project start.
Read more about Twproject And Scrum here