Blog of Rob Galanakis (@robgalanakis)

Hansoft is horrible

I’ve used Hansoft for 5 years across 2 jobs. Over that time, I’ve had more arguments about Hansoft than I wish to remember. In this post, I’m going to present a dialogue between Socrates, a software development, and Phonion, a Project Manager (Producer, Product Owner, Product Manager, whatever) about use of Hansoft. I’m not going to introduce Hansoft because it isn’t worth learning about it if you aren’t already subjected to it.

My purpose is to reduce the number of people using Hansoft, and thus reduce total suffering in the world. This post is for two types of people:

  1. Project managers who use Hansoft and force their studio to use Hansoft. I’m guessing most people in this category don’t hate Hansoft (though I don’t think there exists a solitary human being who likes Hansoft), but they defend and proliferate its use.
  2. Developers who use Hansoft. Everyone in this category hates Hansoft. Send this post to someone from category #1 so you can stop using Hansoft.

The scene here is not hard to imagine- Phonion sidles up to Socrates, right as Socrates has put his head down to start working.

Hello Socrates. I noticed you have not been burning down your hours in Hansoft.

Correct, I did not. My team hates using Hansoft so we’ve been tracking our sprint work on a physical wall instead. Why is it important that I burn down my hours in Hansoft?

It’s important that we know the status of your teams sprint and whether you are tracking to complete it or not.

Why? If my team is not tracking to complete its sprint, there is nothing you can do. You cannot call in more sources in the middle of the sprint. You cannot cancel the sprint. We cannot move stories out of or into the sprint. You can do literally nothing with the sprint burndown information during the sprint. We have the information in front of us and it works much better than having it in Hansoft, which we never go into.

OK, whatever. But we need your team’s stories and tasks in Hansoft so we can see what’s done and not done and how the release is burning down.

What does putting these things into Hansoft and then updating them every sprint tell you about the release?

It tells us whether all the stories needed to complete the release are going to be done in time.

Does it? If points were burning down perfectly, it means every team is getting everything done. You do not need Hansoft to tell you that. If things are not getting done, a high-level release burndown does not give you any information. You still need a way of knowing what did and did not get done, you need to reprioritize, you need to figure out how to get things done reliably. The only way to work with this information effectively is face-to-face communication- you are not going to reprioritize stories without talking to the team or solely via email, are you?

Of course not. Anyway, we really want our charts and reports.

Sure, every sprint I will give you the number of points committed to and completed for the sprint and release. I will even put it into Hansoft for you automatically if you give me the documentation to the API.

We don’t have access to its API. It requires a license fee. It does have an SDK, but no one’s been able to figure out how to use the SDK. Someone took a look at it and it is extremely confusing. Anyway, that’s not how Hansoft works, it can’t just take that number and input it with everything else.

Bummer. The fact that management software is completely cut off to extension and integration makes no sense to me. If you figure out a way to easily write integrations for Hansoft, tell me, but why should Hansoft’s shortcomings force my team to switch how we manage outselves?

Because we use Hansoft to manage the project.

Right now it sounds like Hansoft is using you, not the other way around. The people on my team hate using Hansoft. It’s a large, fat client that takes up space in the system tray and hogs resources. It is very slow to start meaning we can’t just jump in and out. The UI is too complex for anyone to remember so we always need to struggle with where to find things. Would you disregard the unpleasantness of using Hansoft and how much your developers dislike it?

If I say “yes”, it makes me the type of boss who does not trust the judgement and opinions of others. But I know the feeling of bad software, and while Hansoft isn’t the iOS of user experience, it just takes some getting used to.

Do you want your developers to spend time learning how to use project management software, or actually developing? Other project management options simply involve moving a card on a wall, or clicking and dragging, or something much more intuitive. Why can’t we use a solution that simple?

A project this size requires more sophisticated tools and there will naturally be added complexity. We must sacrifice simplicity for the greater good.

In fact, using Hansoft is not just an awful user experience, but it actively encourages the wrong behavior. We want to be agile, which includes getting better with breaking down and estimating stories. With Hansoft, I never look at the sprint burndown. I never look at what’s inprogress or in the backlog, I never want to break down stories into smaller stories and tasks, I never want to rebid or groom the backlog or anything I’m supposed to do in order to become more effective at agile. As someone who wants to always do better, this is painful. And certainly lack of improvement does not contribute towards the greater good; in fact, it’s the worst thing we can do to harm it! So by forcing Hansoft on us against our will, you are saying the work of the producers and PMs is more important than the work of the developers. Is that what you think?

Of course not! To show you how important we think you are,  we will assign a producer to your team to do the Hansoft work.

Absolutely not! You are committing teamicide by injecting someone like that. They will never jell and will be an always-present and uncomfortable fungus. Furthermore isn’t the creation of busywork positions a big red flag? You are allowing your project management software to make personnel decisions. If every team repeatedly delivered on time and at quality and was continually improving- they were truly Agile- would it matter what software was used to track progress?

If I said “yes”, that would make me a micro-managing boss who likes to meddle for now reason. It would also do nothing to improve the situation, and just turn it into a top-down decision that I’m sure would come up later anyway and hurt morale in the meantime. So I will say “probably not.”

So, clearly, project management decisions- like what software to use- should be made to make developers and teams more effective. If many developers and teams outright reject Hansoft and say it is actually making them less effective and not growing, is it likely Hansoft is making them more effective? Likewise, is there a way for people to grow and improve without experimenting?

Again, if I said “yes”, that would make me sound like a traditional “I know better than you” manager, and I’d be forcing my decision down peoples’ throats. So, I guess not. But, project management really likes some features of Hansoft and it we cannot just give everything up.

Do you consider yourself an equal party to development in terms of the value of the work you do?

I want to say “Of course, we value each others’ work.” But in actually, I know that Project Management is a type of Lean waste. It is necessary for the project to function but should be reduced and eliminated. So by definition, no, I am not an equal party.

But nor are your needs invalid! What I would do is evaluate your actions and decisions by answering, “am I assisting the creators of the value-added work?” High-level charts and information can help you- but you should develop this as you need it, for a clear purpose, and without adding more waste into the system. You should only develop these things when you can convince the developers and team members that they need them. Ideally the team should ask for it themselves, or better yet just do it themselves. So how can we put things on a better path?

I guess the first thing is to pick something people like- or ask them what they want to use. Then we can migrate over to that.

What about people that don’t want to agree? People that want to use a different software (free of course), or physical boards?

Well, we should figure out what works best for them. If we cannot convince them an alternative is better, maybe it isn’t better. I’m sure they’d be willing to test something out, though, and we can see how it works. And truth be told, it may be fine for some teams to be off on their own, where there’s absolutely no benefit to the team of moving them with everyone else.

10 thoughts on “Hansoft is horrible

  1. Butters says:

    Ahh yes, its all coming back to me now.. We moved to boards, saved a lot of cash and time. From what I can recall hansoft is great for management because they can get detailed views of each persons “progress”, and who is constantly over or under estimating their time. I personally found it a complete waste of time as we always added/removed tasks based on the agile workflow. In some ways a Google doc would have done.

  2. Great article. I’m on the prowl for a producer position and I noticed one of the desirables was an experience with Hansoft, so I went and downloaded a trial to check it out. The bloatware aspect of it was immediately awful, and I found it to be unnecessarily confusing.

    I’ve spent the past seven months researching and writing about Lean and it always seem weird that so many people are trying to develop applications that assist in applying both Lean/Agile concepts, when this just introduces more wasteful activity, as you mentioned.

    I’m a fan of physical boards, but I think that Asana meets a nice middle-ground to help track and prioritize both bugs and work processes.

  3. Santokes says:

    Hi Rob,
    I just joined a project that uses Hansoft.

    It’s not that bad, enjoy it with a tall glass of bleach all your problems melt away

    1. Hahaha, I laughed out loud and told that to some new friends. Brilliant :)

  4. Henrik says:

    I agree Hansoft got problems. The UI is not intuitive. Improvements could be made.

    But all in all it’s a useful tool. And I don’t agree with your ranting.

    The generic team member would learn pretty fast how to handle his or her tasks in Hansoft.

    And I don’t really understand the need for a physical board.

  5. Chrisjan says:

    What’s the alternative? I’m researching using Hansoft for our company because using Microsoft Project propperly requires 5 different licenses 3 subscriptions 4 servers and 2 certified technicians and then nothing works anyway. I was hoping Hansoft would be our saving grace.

    1. This post was written years ago. It’s possible Hansoft has improved, and there are definitely new applications available.

      If you have a handful of people, I’d suggest Trello or GitHub. Even for larger teams it can work, if you are very rigorous about other aspects of your work (prioritization & issue culling, automated testing & code quality), but that’s a separate topic. I cannot in good faith recommend any heavyweight project management tools, you’ll have to do some more research.

  6. John says:

    “though I don’t think there exists a solitary human being who likes Hansoft”

    Really? I’ve been using it since 2012 and it’s been great. I have tried others in the meantime, nothing is as configurable as Hansoft. I’m using custom workflows for items and it’s been great.

    Of course it’s always a burden to populate the backlog and we stopped using it for a 1-2 years. When we got back to it everyone in the team was very happy.

    There’s no human being who likes Hansoft? Seriously? What a trash article.

    1. Jira is also very configurable, that must be why everyone just loves using it!
      Thanks for your super constructive comment from an anonymous email address, “John.”
      – Rob

  7. Seb says:

    I used it for years as a PM. I hated it at 1st (It became a much better tool at version 8). I think Hansoft is an over engineered tool with too much features that makes it confusing and discouraging to use and very hard to sell to the team.

    BUT! It has some amazing features and concepts that makes it for me the best project dev and collaboration tools if you keep simple and stupid! PMs just need to understand that they don’t have to use all the unnecessary features (or Agile dogmas!) like burn-downs, points, pipelines and locked sprint. Just focus on the Backlog (WBS Project plan hierarchy). Hansoft backlog with hierarchy and prioritized view is simply amazing and it will help you keep track of your scope and status.

    If you want to try Hansoft, here are some tips to keep it simple :

    1. Create a very clean backlog (I prefer to call it Project plan). Keep this project plan hierarchy as high level as possible (maximum 3 levels)
    2. Delegate sections of the plan to Directors or team leads
    3. Use Sprints for Code and Gantt for art
    4. Let team members decide if they want to breakdown a backlog item in the sprint in sub task or use post-its
    5. Do not ask the team members to update there hours. (who knows how much time it will take? Are you asking members from outsource studios to update their time?).

    Note : The backlog items in Hansoft are assigned to the planning. They stays in the backlog. This is something that is important to understand. You work with a plan. Maybe other tools does that but I did not see one. ( MS Project gives you a plan but it’s not a collaborative real time tool).

    Last thing about having the big picture. Team members complain that they don’t have access to it. Select an item from “myToDolist” Try Ctrl+G. It brings you to the item in the planning view. Ctrl+G again brings you in item in the backlog/project view allowing the user to see the other Scoped item status.

Leave a Reply