I am an independent consultant, helping companies of different sizes and in different stages towards organization-wide adoption of agile.
In my experience, while success in agile transformation leans heavily upon changing the mindsets, the organization, the ways of working, and even the ways of doing business, the tools used for backlog management can make or break the case.
In other words, once the organization and the mindsets are poised for change, not having to struggle with tools is of paramount importance.
I'm currently looking at both commercial and open source agile management tools, in order to figure out what would be simple, yet powerful enough to meet the needs I perceive my clients are having. I'm hoping that by learning the ins and outs of a selected, good-enough tool and then suggesting it to my clients when the need arises, I could make my practice more effective.
Based on my experience in consulting and coaching software organizations, both agile and otherwise, I have formulated a set of needs that a good agile tool should meet. To me, the most important requirement is the flexibility of the tool to model the entire set of activities that take up time from the people. Because non-project activities can take up to 50% of the time of the development people, I see "plain vanilla agile project management" with a product, release and iteration backlog as only a subset of what a good tool must be able to handle.
While features such as attachments, version control integration, access rights and so on can be useful, not having all the activities represented in the tool (to a suitable accuracy, of course) makes real change harder.
I'm hoping - as you probably know Jira+Greenhopper inside out - you could help me get a quick start in understanding how your solution might meet the needs of my clients.
The tools that I've, based on some Googling, chosen for the 'first wave' of my evaluation are VersionOne, Rally, Jira+Greenhopper, Agilefant (open source) and IceScrum (open source / freemium). You can in the near future find this same post - or at least, a similar one - on their community forums.
The attached picture (see the end of this post) sums up my evaluation framework; the three first (simpler!) cases are also further explained below; while there are not too many people in these organizations, they in my opinion sum up nicely the practical challenges involved. I'll be elaborating the rest of the cases later on, if I need to - this post is already quite long as it is :-)
All of the organizations explained here are based on my former or current clients. Also, in all of these cases, traditional physical wallboard solutions were ruled out for different reasons. For example, in the first, single-person Freelance Expert case, there are multiple 'offices' from which the expert worked from, while in the other cases, at least some of the workers in the organization were seldom all co-located due to various reasons.
You might of course comment that these cases are not "pure agile". But, this is what I see is the reality is more or less like, even in the most "agile" of the organizations I've worked with, and a good tool should be able to first accommodate to reality, then help change it.
The Freelance Expert (1 person)
The 'Freelance expert' is dealing with the activity types of 'Product development', 'Tech adm', 'Customer support', 'Consulting, 'Sales & biz adm' and 'General adm'. While 'Consulting' in this case is mostly conducted as projects that adhere to a basic scrum framework, 'Product development' is a continuous activity, with single stories being pulled from a long product backlog, and releases happening constantly whenever something valuable gets done.
'Tech adm', 'Customer support', 'Sales & biz adm' and 'General adm' are all continuous activities, which means that project-like start and end dates having little meaning. In these activities, new stories and tasks pop up on an as-needed basis, with certain stories and/or tasks recurring periodically.
From all of these project and non-project activities, the Freelance Expert must evaluate which stories and tasks are the most important to attend to "right now", and which can be left for later. In an optimal case, the tool would have a single view which aggregates all the Stories and Tasks from all ongoing activities, the workload they implicate, and leave the Freelance Expert the final choice of what tasks to tackle first.
How would you suggest the Freelance Expert to model his work in Jira+Greenhopper?
The Micro Organization (3 people)
The three-person micro organization consists of two technical people, and the founder/CEO. The technical duo takes care of product development (with the founder/CEO being the product owner), which is conducted as two-week sprints, each ending in a minor public release. The stories are pulled from the backlog of a major release, which is due quarterly, and in addition to to this release backlog, the product owner is constantly fleshing out the next upcoming release in a separate release backlog. Thus, the product backlog contains all the the feature ideas (etc.) that are not yet seen as important to be included in either the currently ongoing or the up-next release.
Consulting is done as projects, with some consulting projects consisting of iterations of a length agreed upon with the customer, while other consulting projects do not have iterations. All consulting projects are performed by a single responsible person.
Both the Tech duo as well as the founder/CEO take care of customer support. While there are multiple customers, customer support entails a single backlog of stories, prioritized by the founder/CEO.
Except for these, all the other activities (Tech adm, General adm as well as Sales) are, similar to the above described single-person Freelance Expert, "continuous activities", with stories and tasks popping up every now and then, as well as periodically.
How would you suggest the Micro Organization to model their activities in Jira+Greenhopper?
The Very Small Organization (7 people)
In the seven-person very small organization there are two "teams": the five-person Tech team, and the two-person Business duo. Tech adm, General adm are done as in the Micro Organization case.
Sales & business administration consist of both a 'continuous activity' (like before), as well as projects, with each project entailing a preparation of a response of a call to offer. While these are relatively straightforward with no iterations needed, they are labour-intensive, with each response taking about a man-week to prepare. Some offers are responded to by Both of the members of the business duo, while others are not.
One member of the Business duo is technically capable (as well as the original programmer of the product), and as a Scrum-like product owner for Product development - which is handled similarly to the Micro Organization case described above. The other, more senior and extremely-well networked member of the business duo does not follow the progress of product development so closely (and many of the iteration-level user stories have little meaning to him), he needs, in order to perform sales effectively (which he otherwise is very good at!), to stay aware of the progress of the bigger features the iteration-level stories contribute to.
Like in the previous cases, consulting is conducted as projects. However, this time each consulting project is performed by one of the members of the business duo, as well as from one to three members of the Tech team, depending on the size and importance of the consulting project in question. As a general rule, consulting projects 'override' product development in terms of importance, and often consulting projects cause the need of new features to be developed.
Some of these new features are conducted as part of the consulting project, while others are inserted into the backlog of the ongoing or up-next release, depending on the urgency and the willingness of the particular customer to pay for the feature's development.
How would you suggest the Very Small Organization to model their activities in Jira+Greenhopper?
OK, so that's it for now. Like said, I'll elaborate the more complex cases illustrated in the attached picture once if needed!
Eagerly waiting for any advice you might have,
OK, I admit that was perhaps a bit of an epic question to answer.
Let me simplify things; suppose I have
- two teams A and B
- four projects (say, 1 2 3 and 4), concerning different products or business areas
- A and B work together on 1
- A works on 2
- B and two team members from A work on 3
- one member from B and two members from A work on 4
...how can this be modeled in Jira+Greenhopper? And if so, is there an aggregated view of what stories & tasks each team member has to take care of?
Yeah, not fully agile on all aspects, but this is what real life is often like.
Dennis: Spam, instabanned.
That was an interesting question though ! But no answer apparently...