The desktop is a native cross-platform app that integrates views into multiple tools so that you don’t have to juggle a lot of browser windows to get your work done.

This is a walkthrough of a preview version of the desktop. Expect to see the final version in about a month. There are three concepts that we are focusing on in this product - Awareness, Collaboration and Conversations. We’ll walk through each one in turn.

(more…)

In it he says (italics mine)

I keep on seeing announcements for the next great Agile Task Tracking tool. I just saw one posted to Scrum Development where it’s author said: “I haven’t done much testing, so if you find a bug and want me to fix it let me
know :-)”.

My reply: Congrats I’m sure you have an excellent application. I’m wondering if you see the irony - you’re posting to an Agile group and say that your app has hardly been tested? What is your definition of Done? Do you use TDD? At least Unit Testing? What was your approach to acceptance testing?

The implied message here is that releasing an app un-tested is un-agile. I disagree.

(more…)

Why would you want to split a feature?

A couple of reasons

1. The feature was too big, so you want to move a few of the tasks into a separate feature
2. Not all of the tasks could be completed in a sprint, so you want to make a copy of the feature for rescheduling in the next iteration

Here is the step by step procedure for splitting a feature:

(more…)

Here is how to figure out everything that the graph is telling you

(more…)

To take advantage of SSL security, you need to use the following link to access the workspace.

https://<subdomain>.toolsforagile.com

Note the highlighted part is https:// which stands for http secure. Use this and not the normal http://

When you login, you will get the following indicator in the address bar of the browser which indicates SSL security connection.

(more…)

If the data indicates that one method is better than another, common sense would tell you to adopt the better method. However, because change is so difficult, this is a very difficult thing to do.

I came across the story of Semmelweis recently. Here is how it goes:

(more…)

Part 1

There is a tendency among some of the folks who practice agile to interpret the “Individuals and Interactions over processes and tools” in the Agile Manifesto to mean that Agile software development does not require any defined set of processes. So what is your take on that?

… What agile says is when you have different projects running, they all run in different conditions. You might have one project which is composed of a lot of senior people, you might have another project with a lot of junior people and a couple of senior people. [We] can’t have the same process for both the teams because the team structure is different, so some practices that work for the senior teams will not work for the mixed team. So while they will follow some practices, they might follow different set of practices. That’s a process, but then it’s not a centralized defined process done by someone sitting in an ivory tower who then enforces it among all the projects in the company…that’s something which people are genuinely against. Have a process - but have a process which is suitable for your condition.

Read the whole of Part 1 here.

Part 2

Agile has its own advantages and people who vouch for it. So does a completely different way of doing things - the CMM (Capability Maturity Model). What are the compelling reasons for a person who is practicing CMM processes to move to agile?

I’d say there’s only one compelling reason – and that is, if what you are doing currently is not working for you. If you’re following CMMI and it is working for you, that’s great, then there is really no need to change. You don’t have to change because it’s the in-thing. That’s something which I’m quite against.

But a lot of people do have problems when it comes to CMMI when requirements are unstable, because of the way it is structured, and with testing and user acceptance right at the end, which creates a lot of issues with respect to changing requirements. Or cases where you’ve not got the requirements exactly or there’s also the case where the customer sees a product and then gets lots of ideas on how it can be done. So when you have a market like this, then you find that CMMI tends to cause issues because you get bugs right in the end, you get change requests right in the end. It can be difficult to cope with it.

Read the whole of Part 2 here.

(more…)