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.