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.

Thursday, November 19, 2009

Opt-in from a Trial to a Paid Subscription

Yes, we have listened to our users. Now your 30-day free trial subscription will not be automatically converted into a paid subscription at the end of the trail period. Although we send an email notification a week before a trail period comes to an end, it seems users may not act proactively to cancel their trail subscription. It was never our intention to mislead our esteemed users to signup for a trail subscription only to convert them into a paid one. We wanted this to be a convenient feature, should anyone decide to continue to use ScrumPad. They can continue to use the service and keep their data. However, we realize that how people can forget to cancel subscription in time and then be surprised later when they receive an invoice. We never require anyone to pay for a service that they did not use. In fact, we do not take our customer's credit card info and do not charge customers' CC automatically when payment is due. We only invoice at the end of the month after our customer used our service for the month. Customer has the option to pay or ask for waiver because they are not happy with the service that month.

So, from now on you can upgrade to a paid account anytime during your 30-day free trail period. Or, your trial account will automatically be suspended after the trail period. If you try to login after the trial has expired, you (account admin) would be prompted to explicitly agree to upgrade to a paid account. Once you agree to upgrade, you can continue to use your original account without loosing any data. You will still receive an email reminder one week before your trial account expires.

We are happy to be able to make this change. We hope there will be no confused users either.

Wednesday, November 11, 2009

Should fixing bugs contribute to a team's velocity?

I get this questions often. I am sure you probably also got this question at one time or the other. There are two ways to look at this- value vs. cost. These perspectives are linked to how you define velocity. Let's look at both in more details.

Value perspective. If you define velocity as the net value (in story points) delivered to your customer, then you should not include bugs in your calculation of velocity. Think about it for a moment. Bugs are something that are not working as expected, but the customer has already paid for them. So, by fixing bugs you are not really delivering any "incremental value" to the customer. If you increase your velocity by including bugs, you are inflating your velocity. Now, granted that sometimes we report something as a bug when it is an incremental feature. You need to work with your product owner to negotiate to change those bugs into stories and account your effort for them in your velocity.

Cost perspective.
If you define your velocity as the amount of work done by a team in a sprint, then you should include bugs in calculating velocity. Yes, bugs take effort and time to fix. Hence there is a cost associated with fixing bugs. But this makes the release planning a little bit complicated. Because you cannot know ahead of time how many bugs you may have until the release. Directly using velocity to calculate the effort or to determine the time-line for the release will most likely be off (undershoot). One way to address this is to break the velocity into two components- feature-delivery velocity, and bug-fix velocity. This is in a way going back to the first option.

I personally am in favor of using "value" perspective and exclude bugs from calculating velocity. This helps keep our eyes on the ball- delivering "customer value." As a result, we are encouraged to reduce bugs in the first place so that we can free up our capacity to deliver more value. That is why we currently do not allow users to point estimate bugs in ScrumPad.

Are you including your effort spent on bug fixing in your velocity?

Thursday, October 22, 2009

The ScrumPad Way- Project Ecosystem

If you are reading this post, chances are you are already using ScrumPad, or thinking about using it. We believe your decision to choose our service should not only depend on what we have today, but also on what we plan to have in the coming days. More important, you should know what drives those decisions. Let us share with you our vision for ScrumPad, the philosophies behind it.

We believe that there are two very important tools that every software development team must have- one is for Project Management, and the other is for actual software development (which we all know as IDE -Integrated Development Environment). These two tools should have tight integration between them to create what we call the "Project Ecosystem." A clear division of responsibility between the two tools would allow us to establish that ecosystem that feels "just right." It can be explained through the following diagram:


What this means is we would only focus on features that would be most appealing to the broadest group of users on a project. We will leave out product integration or features that we see are more appropriate for IDEs. For example, integration with a "CM" (i.e., SVN) tool or a "testing" tool, or "continuous integration" tool is better suited at the IDE level. Integration with, on the other hand, an "invoicing" system or a "help desk/trouble ticket" system is more appropriate for ScrumPad.

So expect to see integration with popular IDEs and Invoicing services in the near future. We are currently working on publishing APIs to facilitate these integrations. If you are enthusiastic about creating a plugin for your favorite IDE, please contact us. We would love to support your endeavor.

Now that you have an idea about how we decide what features to consider for ScrumPad, let's talk about how we go about implementing them. Our implementation is always guided by the principle of "convention over configuration" as much as possible. For example, we do not allow configuring a workflow, or what is displayed in a view, or what reports you can generate, or what you see in a report (but we will add reports that all of you ask for). WYSIWYG- what you see is what you get. We try to take the common denominator approach to keep things simple, yet very useful and comprehensive. We believe that you can get the most value out of a PM tool when you do not have to think about how to use the tool. You should spend the least amount of time with the tool to get the most value out of it. As a result, we try to do most of the work for you where possible with minimum input from you.

Last but not least, we believe software project success depends on appropriate "collaboration" within and across teams. We are taking it to the next level by opening up collaboration across companies- "ScrumPad community." If you have an idea on how companies can collaborate to achieve project success, please share with us.

Also, please note that we are making changes (i.e., fixing bugs, experimenting with a new feature, improving usability, performance etc.) to ScrumPad every two weeks. Be prepared for an exciting ride of "evolutionary product development." We expect you to be an integral part of that ride to build the "Project Ecosystem."

Do you still think ScrumPad is for you? Like to hear what your take on PM tool.

Friday, October 2, 2009

How to manage multi-team product development

Managing single team project or product development is easy. All project management tools provide this capability. However, things start to look different when we start to manage projects that spans multiple teams. Some tools do not support this scenario, and others do it through project hierarchy. In ScrumPad, it is as easy as managing single team project. However, the terminology may come in the way to understand it.


Before I explain how we do it using ScrumPad, I need to introduce a few concepts as they are applied in ScrumPad. First is the project. A project is implemented as a means to manage a single team development work. So, a project is associated with a team and a product backlog. The team creates a sprint backlog from the product backlog to manage work in sprints (i.e. iteration). Second is the portfolio. A portfolio is a set of related projects. A portfolio may have its own (product) backlog. You can access a portfolio if you have access to all projects as a product owner. A portfolio is a way to track and manage related projects. Projects within a portfolio share same tags so that you can track progress at the portfolio level. We do not like hierarchical association of projects. We think it unnecessarily complicates things. With non-hierarchical setup, we can easily move between single team project to multiple team program.

Multiple team product development. It is recommended to use a single product backlog for multi-team development. However, it is not required in ScrumPad. You could keep separate backlog for each team. In that case, it will be just like managing multiple single-team projects. If you prefer to manage multiple teams from a single backlog, you would need to setup a portfolio in ScrumPad. You would use the portfolio backlog as the single product backlog for all your teams. First you would need to setup a project for each team. Then you would create a portfolio from "backlog > portfolio" menu and add the projects to the portfolio. If you already have a backlog before using ScrumPad, you can easily import your initial product backlog into your portfolio backlog in ScrumPad from "backlog > import." If you are just starting your project, you can start adding stories to the portfolio backlog as you elaborate requirements. Then you can move stories to project (a,k.a. team) specific product backlogs (a.k.a. team backlog) as you see fit. The teams can then work off its product backlog like any single-team project would.

Program management. If you have a program consisting of multiple related projects, but each project with a single development team, you would setup each projects separately. Then you would define a portfolio representing your program. Add the projects to the portfolio. Now you can track your program across all projects while your projects work independently (without needing a portfolio backlog).

The beauty of the loose coupling between project and portfolio is that you can start small as single team project. As your project grows you can seamlessly move to multi-team development using portfolio.

If you are using the portfolio feature, we would love get your feedback on how we could make it more useful for your needs.