Posts Tagged ‘agile tools’

tinyPM 3.0 BETA Public Availability

Marcin Niebudek,

tinyPM agile collaboration tool just got new powers! We are happy to announce that a new 3.0 version is now available as free BETA.

tinyPM 3.0 BETA

BETA means that we did our best so that everything works fine, but there still may be some quirks. Also note that this is the first tinyPM 3.0 version and we are working hard to improve the feature set.

So what do I get?

First of all new tinyPM is a SaaS solution. Sign up in 1 minute and you’re ready to go. All BETA accounts get 5 users and 5 projects for free. And what’s more important those accounts will remain free also after the BETA period. This way we want to thank you for being our early adopters.

In the new version you will find all the well know and well received features from tinyPM v2.x, but done in a better way. To name a few improvements:

  • our UI just got a lot faster,
  • we’ve improved the usability of all features,
  • most content is editable inline now,
  • backlog management has never been easier,
  • you can do anything you need without leaving your taskboard,
  • we now support read-only users, so that your business and clients stay up to date at no additional cost,
  • and many more…

How do I start?

After logging in you will notice a First Steps box on the top of the page. The best way to start is to follow the steps mentioned there. But feel free to choose your own way or just look around. If something seems confusing to you LET US KNOW! tinyPM should be straightforward to you and we will make sure to keep it that way.

I’ve noticed that some features present in tinyPM 2.x are not there. Why?

Don’t worry. tinyPM 3.0 changed completely the technology stack (but this is a story for another post) so that we can do things the way they should be ;-) We will be introducing missing features shortly. If you think that any particular one should be delivered sooner than others, just LET US KNOW!

You can always post your ideas using Settings menu in the top-right corner of the screen. You will find there Have suggestions? options which posts your comments directly on our UserVoice forum for tinyPM 3.0. Make sure to use it often!

I already have my projects in tinyPM 2.x. What now?

You are all fine. We’re working on a migration path. When it’s ready you will be able to move to tinyPM 3.0 at no additional cost. All licenses from tinyPM 2.x will remain valid. We were always providing upgrades for free to all our users. Nothing changes here.

Have problem or questions?

Make sure to get connected with us through one of the following channels. This is the best way to stay up to date with what’s going on with tinyPM.

tinyPM’s mantra remains the same – tiny effort, perfect management, but we also add one more to it. You can always do better.
Still reading… Stop and check out http://beta.tinypm.com

What Criteria Do You Use When Choosing Agile Tool?

Marcin Niebudek,

This question has been asked today on LinkedIn Q&A. I wanted to post an answer there in the first moment, but then I though that those Q&A’s tend to fade out very quickly and maybe answer to that question deserves some more attention.

Different criteria in different contexts

Well, the question was asked from a perspective of a tools reviewer. This in fact makes it more interesting. Normally I would say just choose the criteria that match your team or organization needs. But here its different.

What one should do to review a few dozens of tools on the market? Is it possible having a “generic” reader/tool user in mind? Is there someone like “generic” tool user seeking for an advice in choosing the agile tool? Sure there isn’t.

There are many agile flavors. Even if we choose to call some of them “methods” which would suggest they consist of more strict rules to follow – they don’t. Teams or the whole organizations choose different practices to be applied. Even same practices or ideas are applied in different ways.

Tools usually will do better in some aspects and stay behind in others. This is natural effect of different influences and experience their creators have. So each of those organizations needs a different set of criteria.

So let’s turn things upside down

What if the reviewer tried something different and yet something we perfectly know (at least in agile world)? How about taking the tool under the review and finding a set of user personas that this tool is going to be best for? How about creating something similar to a persona but for the organization? Maybe some kind of imaginary company profile that the tool would fit the most.

What goals the tool will satisfy? Who may have such goals (in a software company for instance)?

Maybe it will be Jack the Geeky Developer who works in a 5 people team and have a remote Product Owner. Jack works on 3 projects at the same time (two of them are in the maintenance mode) and wants his current assignments and commitments to be easily accessible for him. He may be able to switch between them easily and the Tool X will do the best for him as it’s good in organizing the work in many projects.

The Tool will be also good for Alice – the Scrum Master of a few teams in her organization. Alice shares her time between those teams and needs to be up to date with each one instantly. Which would be satisfied by features A and B.

But Bob, who likes extensive reports full of charts and KPIs, may be disappointed with the Tool X which provides only basic data exports. There are more data hidden in the Tool’s API but Bob will not even care to dig into this. He has simply no time for that.

Is the the organization where Jack, Alice and Bob work similar to yours? Then this may be a good tool for you, but only when you are able to convince Bob that the information he will get is enough to run the company.

I’d love to see some reviews like this. I think it might do more good than assigning some points in various categories and publishing the overall score. This kind of criteria based evaluation can be done only internally where there is one organization and many tools.

But when you are on the other side and try to review the tool (of any kind), then no set of criteria will ever be relevant to a particular reader (or at least to just a few of them). On the other hand reader may see herself in one of the personas you will try to describe. If so, then maybe the tool is right for her. Otherwise she will know instantly that this is not her Bob and Alice.

How does that sound to you? Wouldn’t that help you more in choosing the tool (or at least choosing it for further evaluation)? Just an idea…

Advice on Starting With Agile

Marcin Niebudek,

Last week we got an e-mail from a user who found tinyPM and actually wanted to start using agile approach in his team. He asked for advice on where to start. I thought later on that I should actually post the advice here. So here it is…

There are tons of places that you can learn more about agile, but I think that there is this one perfect for starting quickly and getting the most ideas in one place. It’s a book by Henrik Kniberg called “Scrum and XP from the Trenches”:

http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

This short book will give you a perfect overview. In addition to that you should take a look at one unique blog about Visual Management:

http://www.xqa.com.ar/visualmanagement

And that brings me to an advice I need to give you at this point. I assume your team works in one place. So if you are starting with agile then read the book and build yourself a board like it’s described on Visual Management blog. Than try it out for a few weeks just by using cards, whiteboard and pens. Don’t touch any other tool unless you really need the project information stored in some electronic way.

The most important is for your team to feel the mechanics and the idea of these methods. They all depend a lot on direct communication and this is what your team needs to get used to in the first place. Then you can decide if you need a tool and this is a place where tinyPM will come very handy.

This is the shortest advice I can give. What advice can you give to a beginning agile adepts?

Vote for tinyPM

Marcin Niebudek,

Kelly Waters is running a pool on Recommended Agile Project Management Tool. We encourage you to take part in it and vote.

You will find the pool at:
http://www.agile-software-development.com/2009/09/agile-project-management-software.html

As we are doing all we can to provide you with the best and easiest to use agile tool on the planet, we’re always happy to hear from you. AND THAT INCLUDES ALSO COMMUNITY EDITION USERS :-) We’re open to any complaints you might have on every (even small) function you will find in tinPM.

So if you’re using tinePM, like it and want to support it in the pool then VOTE! We appreciate that!

It would be great to get a comprehensive poll of the marketplace and see what tools people recommend. So make sure your software of choice gets the votes it deserves (and hopefully tinyPM be the one you choose :-)!

Why a bug tracker is not a good tool for agile project management?

Marcin Niebudek,

Or yet another point of view on what to do with all those bugs in the backlog…

From time to time we observe a new discussion on whether we should put the bugs into our backlog or not. Opinions are diverse but I see one more aspect of that topic.

The idea behind the backlog is to have all items that we plan to ship for a product as some prioritized list. We leave the backlog in the hands of Product Owner and he decides what comes in and how important that thing is. the backlog forms the vision of what our product will be.

When asking ourselves about putting bugs/issues/tickets into backlog we usually look at it from the development team’s perspective. But lets take a look at what happens before product owner puts anything into the backlog.

We as a team perceive the backlog as the only source of the job to be done, but for Product Owner the backlog is the endpoint of the whole process of gathering ideas, requirements, issues from a lot of different sources. At the beginning of a new product development those sources might be:

  • real users needs,
  • client ideas and requirements,
  • team’s own ideas about the product

As the development goes further bugs arise and at that point they are usually addressed during iterations. When our product is finally released and starts it’s own life then the Product Owner may (should?) use all sets of new sources to fill his backlog items list:

  • feedback from the market (by e-mial, phone, through company’s help desk),
  • bugs reported through the bug tracker directly or indirectly by users,
  • sites that manage new ideas (like UserVoice or GetSatisfaction)

All those sources start producing new items that Product Owner is dealing with every day. They may be:

  • relevant to the product vision or not,
  • duplicates of other ideas that we already know from other sources,
  • a part of some bigger requirement that will later on form a user story

Bugs, especially if we adopt the culture of avoiding them instead of waiting for their arrival, are only a small part of the list that Product Owner should think of when forming his backlog. Also each of the sources that Product Owner deals with have their own life cycles.

Bugs in particular might be:

  • confirmed and fixed,
  • rejected,
  • postponed,
  • merged with items from other sources to form stories.

Most companies adopting agile methods usually already use some bug tracking systems and have some flows for dealing with issues that are put in those systems.

When they start working the agile way, the first thought is to start putting user stories into the same bug tracker or convert their bug tacking system into agile management system by mapping user stories to tickets. Other think that now, as they’re becoming “agile”, they should stop using their bug tracker and find some “agile tool”. But after all they start thinking about where to put all those bugs and the only place they find is their new backlog.

I think that either way of thinking comes from the wrong assumptions that bugs can be treated as stories or handled the same way as new features development. Instead of that we should put our Product Owner, a “man of vision”, between the list of bugs (bug tracker) and the backlog.

If the Scrum Master or any other similar role (we’re not talking only about SCRUM) is the wall protecting the team and the process during the iteration, then the Product owner should become a wall protecting the product vision and the backlog. Does it mean that no bug will slip into the backlog? No… some of them will as they need to be addressed individually. But many of them will never reach the backlog in the original form.

I like the idealog concept that Mark Mansour described at:
http://stateofflux.com/2009/04/10/is-the-product-backlog-an-idealog

I think bugs should become at first a part of such list (idealog) next to the items from other sources connecting Product Owner with the real world. And only after becoming a part of such buffer they should pass through the first gate and become backlog items. Going from this point to the rich universe of tools you will start with idealog and the backlog (even if the tools to manage them are your white boards or some Spreadsheets). When it becomes insufficient you will end up with both: bug tracker and some agile management tool, as well as with all other tools that might help you gather the feedback about your product.

They all play a different role when we take a look at the product management part of the process.

Watch out! Agile tools sellers are shooting at you!

Marcin Niebudek,

From time to time someone asks for the recommendation of an agile tool. Lately I read the Twitter message from one of those persons saying:

“Crazy how after asking what scrum tool I should use I got bombarded by a bunch of product sellers. They figured out the power of twitter.”

I admit, I was one of those “bombarding” guys :-) as I’ve sent a reply recommending our own tool. But it’s not the tool what matters now, but the question “Is it a spam when the creator of a tool sends the recommendation for it?”.

If we create software, especially for the agile part of the market, we believe in agile principles (I’m sure I’m talking not only for myself). Even more, I can’t imagine an agile software company want it’s product to be the third best product on the market. NO, I believe we all want it to be the FIRST one. We use those tools, not only produce them (you do use your own tools right? ;-)

Why (if so) do you believe that such recommendation can be dishonest, mean or have any other hidden bad intentions?

BTW. Never ask “which tool should I use”, but “which tool should I consider”. Evaluate… but first identify you real needs, starting with cards and whiteboard… maybe you don’t need anything else. And if you want to take a look at the agile tools, then take a look at:

http://www.userstories.com/products

After that you will really need a recommendation, right? :D