Tuesday, April 20, 2010

Agile project management tools- present and future

Recently we did a presentation on the present and future of Agile project management tools at the Richmond Agile User group event. We had a great conversation with the participants. Thanks to Tania Broome and Roney Pate for inviting us to speak to the group. Here is a gist from the session:

1. Simple tool- whiteboard/corkboard + cards/stickies + marker is the best tool for a single co-located team and  online spreadsheet (e.g., Google Spreadsheet) with Scrum template for a single distributed team.
2. For long-term sustainable efficient software development, "purpose built" agile project management tool is a necessity.
3. A team new to Agile, should start with the simple tool available, and once have a good feel for what Agile development is all about, should move to a software-based tool.
4. Tools good for Scrum, may not be good for Kanban, since they use different control and tracking mechanisms. ScrumPad supports Scrum. If you are looking for a pure Kanaban tool, we recommend that you look into AgileZen (recently got acquired by Rally Software).
5. Tools are for making things easier and hence making teams more efficient.
6. Tools are not for replacing human interaction and conversation.
7. Tools are not for making poor implementation of Agile better.

Tools conversation has always found passionate voices on the both sides of the aisle in the agile community. Many agile experts like Ron Jeffries have been very vocal about only using "simple tool." Here is a recent debate between Ron and Ryan Martens of Rally Software summarized on InfoQ.

Here are the presentation slides from our session:

 All skepticisms aside, a tool goes a long way if we are aware of what tools are for.

Are you using any PM tool for managing your Agile projects? What tool? What have your experiences been using such a tool?

Thursday, February 18, 2010

Secret sauce of a successful self-organizing team

I see many teams struggle with how to become a self-organizing team. Even with supportive environment (trust and empowerment) with a few constraints (important, otherwise chaos will ensue. Mike Cohn has a very good post on the topic.), I see teams struggle with it. In fact, I have seen teams very self-organizing even in a less than supportive environment. So, the question is what is at the core of a self-organizing team?

Let's look for examples outside our industry. One comes to mind is the 6-time winner of NBA championship Chicago Bulls. Phil Jackson is a master at assembling and then fostering a self-managing team. He surrounded Michael Jordan with teammates that not only had complementary functional skills, but more importantly complementary emotional intelligence. If we mapped this team's EQ along multiple dimensions, I bet that it would look like a balanced polygon. You might argue that it was all about Michael. I would say he was a piece of the puzzle, a center piece I might add. However, Phil has done it with two more teams at LA Lakers. So, it is not just Michael, but being able to create a team with a balanced EQ map.

What do we learn from this? To become self-organizing, a team must have a EQ map that would look like a balanced polygon. I am coaching a team for a while now that struggled with becoming self-organizing team. We would discuss what we could do at the retrospective, but not much improvement was seen. The team would not follow through on the action items. However, things changed after we hired a QA person. He was very detailed oriented (as you would expect from a good QA person) as well as a good organizer. He started to help the team to follow through on items that come out of daily Scrum and retrospectives. Things have gotten a lot better after that.

Individual emotional makeup contributes to a team's collective emotional makeup. Some of us are extroverts, and some are not. Some like to organize, while some like to follow. Some like to pay attention to details, while some like to stay at the abstract level. Some feel comfortable voicing opinion, while some don't. Some can make decisions quickly, while some are very good at playing devil's advocate. It is important that we have a good  mix of all these elements of EQ. A common misconception is that if we hire the best people (with functional skills) we will succeed. If we do so without looking at EQ, we run the risk of falling prey to groupthink and be blind-sided, or  even worse crippled with still-mate or overpowered by a loudmouth (have a good post on this by Chris). The team eventually crashes and burns.

It is easy to develop a missing functional skill, or plug the gap from outside help, but it is very difficult to plug a hole in the emotional makeup of a team. Some of the EQ elements define who we are, and can only be nurtured and fine-tuned, but not drastically be changed. It is certainly so in the time-frame we want on a project.

So, hire not only for functional skills but also for EQ skills that the team needs.

Wednesday, January 27, 2010

ScrumPad 2010 Roadmap- reimagining the future

We have started this year working on a new look for ScrumPad. It has kept us busy for the most part this month. This new look is our first step towards our overall vision of "reimagining the future" theme that we set for us in 2010. Although the "new look" was a result of the feedback from our current users and our growing understanding of usability and usefulness for a PM tool, it is an appropriate segue to a bigger question- "How would we design ScrumPad, if we started from scratch today?"

In exploring answers to this question, we have identified a few initiatives that we are already excited about. I am sure you will be too. Some of these initiatives are at a high-level and missing specifics. We are intentionally vague about the specifics, because we would like to involve our users help us pull these specifics out in the light. 

Kill features that are not used, expand and tweak those that are used more. In the spirit of lean startup, we plan to remove features that are not used by our users. We see these as distract ors from both developer and user perspectives. Instead, we want to spend our effort on features that made our users choose ScrumPad over our competitors' and make them even more useful. 

80% features will be a result of user pull, 20% push from us. The idea behind this "pull vs push" is that we plan to  put our users in the driving seat when it comes to what new features to add. To streamline our interaction with our users, we have chosen Getsatisfaction. However, we will still push some experimental features to our users. These will things that nobody has tried. We will not be afraid of testing and 

Integration. We plan to focus on building plugins for popular IDEs (e.g., Eclipse, Visual Studio, and NetBeans). Our goal is to allow developers interact with ScrumPad without leaving their core working environment and hence reduce the time spent on ScrumPad. We plan to roll-out support for one IDE every quarter starting with Eclipse. We also want to integrate with services like getsatisfaction and uservoice as well as help-desks like ZenDesk to allow users drive backlog.

API. We started the work on publishing some of the functionalities as APIs in last year. The goal is to allow users to build their own integration or offline reports. The initial set of APIs is currently in private beta. Expect to see these APIs generally available by the end of first quarter. 

ScrumPad Community. We do not see ScrumPad just as another PM tool, but much more than that. We see it as a platform for "Agile Project Ecosystem." We discussed this in one of our previous blogs. We have released a Minimal Viable Product (MVP, a leanstartup term) early this year. It is in private alpha. Expect to see more on this front.
Core functionality. We would like to focus on making product (backlog) management as easy as possible. So, we will be experimenting with different features to make this a reality.

Usability. Our effort on usability will not stop with the roll-out of the new UI in a few days. It is an ongoing journey for us. We plan to have a maniacal focus on usability throughout 2010. We want to get to a point where it feels "just right."

We will be doing all these in small increments, tweaks, and turns. All fun. At the end, we want to move from "product market fit" to "transition to growth." We promise to keep you guys updated about our roadmap with the specifics as they unfold.