MS Outlook, Email, Tasks, Google Wave?

I had an interesting meeting the other week. Demo’ed our new product to a director of project management at one pharmaceutical company and tried to learn about his challanges at the same time.

The most interesting discovery was the following:

Reading e-mails and distilling project information for inclusion in project plans is a major part of what project managers do these days.

How about that? Surprised? Maybe not. Now, think of your favorite project management solution (MS Project), even one of those new web-based ones (Clarizen, Zoho, BasecampHQ, …). Do they solve this “email management/organization” problem for project managers?

Microsoft seems to realize the issue  better than anyone else then? Because MS Outlook does try to provide a solution here by integrating Email & Tasks. Although their approach is again a bit incomplete, the personal planning part is kind of missing (well, they want you to use MS Project for that I guess). But MS Project’s “command-and-control” model, I am afraid, is not going to fly. In the time of social networking, teams seem to be looking for more de-centralized approaches.

Google also seems to have realized that the email clients we use dont cut it anymore. How many times do you find yourself looking for an email message in your Inbox that had some short but quite important comment relevant to an active project? You know it is there but it is just not  easily accessible, maybe already archived by MS Outlook and gone. First, the Gmail threading email organization and now Google Wave make alot of sense to me. I think such email channels would also make alot of sense for project managers. Imagine if each request listed in your project plan had this email channel associated with it, and you could easily see all relevant email communication in it? Wouldn’t that improve productivity significantly?

-Alexey

Rolling wave planning compromise.

David @ 37signals is saying, You do not need a product road map:

It’s better to turn customers away than to placate their instincts and lure them in with vague promises. It’s incredibly rare that a single feature will truly make or break your chance with a customer. If your software is a good enough fit, most people can make do without that one or two things that they’d like to see. 

John @ SplicedNetworks is saying, Goodbye Roadmap:

The concept of a roadmap has been thrown out, replaced with list of initial functional features . These features are currently in development, and will be the initial AppOS 4.0 release. AppOS 4.0 won’t be the bells and whistles release initially, instead it will be functional. Features will be expanded and added based on customer feedback , as well as our own use of the product.

These are agile companies talking. I support this concept and I am pretty sure they know what they are talking about. Our backlog is our idea of a road map, it is telling us what could be coming in the future releases (most probably the higher priority items) although you can not really say when exactly and in which order. One or two iterations ahead the situation is much clearer but beyond that not really, it is all driven by the changing market requirements.

But then, even scrum masters keep bringing up the concept of the rolling wave planning, which basically means: lets still try to maintain our road map and long term release plans, even though we’re agile. Isn’t that somewhat contradictory to the iterative “agile” concept which tells you that it does not make much sense to predict that far ahead?

I think Jerry Manas expressed it very well in his comment to  Forced Into ‘Agile’:

But even in the Defense Industry, Rolling Wave scheduling is becoming the norm, where each horizon is planned at a more granular level as it approaches (although the whole project is laid out up front at a higher level). I look at Rolling Wave as a hybrid between Agile and BDUF (and it’s appropriate for most projects most of the time).

So is the rolling wave a vehicle for transition to agile or a means to keep your business/management/VC folks happy (by giving them a plan that wont survive the reality)? What is your take on this issue? Do you create product road maps in your agile environment? Do you use the rolling wave concept? How practical is that? It would be very curious to learn.

Our product Yoxel Agile Product Management  is quite straight forward in this sense. You’ve got your backlog and your iterations, which we also call incremental releases, because for us those are the same (~1month: implementation+testing). No rolling wave with long term release plans and even longer term road map plans. You can start planning next iteration while you’re implementing/testing one and so you will have a good idea for what is coming in a month or two but beyond that your best bet is the prioritized baclkog .

Cheers!

Bookmark: Agile SCM – Review of 2007 and Predictions for 2008

Agile SCM – Review of 2007 and Predictions for 2008, written by Brad Appleton, Robert Cowham and Steve Berczuk. An interesting read.

Bookmark: Automating and opening up product planning

Here is an interesting post by Christina Noren, Automating and opening up product planning. Yet another example of a team trying to hack and integrate a few existing tools to build a useful product management flow. The problem I have been describing in my earlier post, Think bigger, Think Agile Product Management. Seems like many teams face the same inconvenience and some new, more integrated tools could help.

So the experiment: We’re hacking Jira, our bug tracking system, in order to automate the entire product planning and marketing process and facilitate real-time communication back to customers, internal stakeholders and even the community at large via our public roadmap. 

…

This means that we setting it up to automatically bring enhancement requests from our SugarCRM system into a PM work queue within Jira; asking PMs to enter call reports and market datapoints; linking all of these to problem statements;

What I especially like about this post is that it confirms our efforts with our project Yoxel Systems. Yoxel is exactly that integrated system: request tracking, release planning/tracking, key CRM capabilities, and even customer portals! And if you really like your Jira, Bugzilla, Mantis, GNATS, Yoxel can connect to them too.

Customers with enhancement requests tracked through the support portal will be able to see how they’ve been triaged, how the problem has been interpreted, and what requirements are at what stage of delivery to meet the request.The public roadmap will be maintained in real time, with the potential for drilldown into more of what’s behind each listed feature. 

Once again, Bridging the worlds of PLM and CRM  seems to be creating value and helping you build better products.

Check out our demo accounts as http://yoxel.com

The future looks bright (for agile teams)!

This post by Alex Iskold, The Future of Software Development, has circulated the web very fast . I have already seen many blogs referring to his article and it has been even mentioned in LinkedIn’s Q&A section. I share the views expressed by Alex and wanted to bookmark this link on my blog too .

Equipped with a modern programming language, great libraries, and agile methods, a couple of smart guys in the garage can get things done much better and faster than an army of mediocre developers. 

I think that now one should write how those smart guys in the garage can market and promote their product better than an army of marketeers in big enterprises. I think Bob Walsh’s blog may have a few suggestions in that regard .

http://47hats.com/ 

Agile roadmap

Here is another great ‘real-life’ story of transitioning to ‘agile’ Agile Team (with personality observation) by Susan Lim. You know I like such stories more than any theoretical discussions on this topic, because it is very individual and it gives very good examples. I learn alot from these myself.

The point of having two plans, long term release plan (or roadmap plan) and a short term iteration plan comes up all the time with agile/SCRUM. (Agile Hallmarks post brings this topic up again and again, accompanied with very neat diagrams and chars.) I believe it is quite challenging to follow your roadmap. Sure you can create it as your management and marketing books tell you but will you be able to follow it exactly? If the market requirements change swiftly, will it make sense to follow it? In my case, having prioritized backlog gives me an idea of my overall roadmap but it is also quite flexible, because the iteration plans are really the ones that align that roadmap with current market situation. I have written down a few more thoughts on this topic before:

Does “agile” complicate your roadmap management process?

This O3 magazine article is even saying “Goodbye Roadmap”:

http://o3magazine.com/pastissues/issue7/

Yoxel v1.17 with a SALES module is available for download.

Release v1.17 (http://yoxel.com) has a bunch of new capabilities and I am quite excited to list a few of them here:

1. YOXEL SLS (an experimental suite for sales teams), that has been only available in our on-demand version, is now included in the open source version. You get two subsystems: sales forecast tracking and product evaluations tracking. Many other CRM products have forecast/opportunity tracking solutions but you will not see many good product evaluations tracking solutions. We would like to think that ours are quite unique and powerful, plus they become integral part of the whole product management solution:
   

   Bridging the worlds of PLM and CRM

2. Profile editing capabilities added for customer/contact logins. Besides entering contacts information only on your side (correct name/email/password/opt-out options/…), the traditional CRM way, you can now rely to some degree on the contact itself. Certain fields have been opened for your contacts, that have login access privileges, for editing. This kind of makes it CRM 2.0 – more interactive relationship with your customers and better feedback management .
3. CVS and basic Subversion integration is enabled though email comments support. Besides capturing email responses related to requests and attaching them to the request history/log, Yoxel in a similar way now can attach your commit messages coming from CVS or Subversion.
4. Responding to a request from one of our users, support for Retrospectiva external bug-tracker has been added too. Now it is possible to configure Yoxel to import requests from one of these bug-trackers: Bugzilla, GNATS, Mantis, Retrospectiva. For a smooth transition to “agile”!
5. … other more specific capabilities and bug fixes …

Ejoy!

PS: And please send us your feedback.

Areas to improve for your software projects

A very insightful analysis indeed, by Carl Rogers in his post A little insight into our customers’ process capability …

With tons of useful graphs. A few things that I notice from the graphs:

1. The most challenging problems that software projects face are: Delayed Delivery, Cost overruns, Poor Requirements, Unclear/Imprecise Business Objectives, Poor Communication, Lack of Testing
2. Importance of software development process in building applications: hight for the most teams
3. Use of software development process: In-house grown is the most popular one especially for smaller teams, compared to others like MSF, SCRUM, …

Clearly known agile methodologies emphasizing incremental delivery and frequent customer feedback management focus on solving #1 challenges and must be the only right way to go.

For the most part this survey results seem to be in agreement with the other survey that I mentioned earlier, done specifically for agile methodologies: Agile Project Management Tooling

The only major difference I see is that in Carl’s results the in-house/hybrid methodology and MSF are the most popular ones whereas in the other survey it is SCRUM and XP.

PS: Here is another article that seems to be quite relevant to the topic of the problematic areas for software projects: The Absent Product Owner anti-Pattern

Testing and sprint planning challanges

An insightful article/survey by Derek Morrison:

Points to watch out for when converting from waterfall to agile testing

100% stated that:

• There was a lack of written requirements to test against, not enough detail in the requirements resulting in no real understanding on how a feature should work. Also a lack of forethought on features causes problems later on in th sprint.
• No formal tracking of defects: only the tester is using the defect log and changing the status.

The 1st one is probably in the hands of your product managers and product engineers who are supposed to have the best idea of how a customer would be using a feature but the 2nd point, I think, could be easily taken care of by a good request/bug tracking system (preferably supporting agile processes, and workflow that provisions testing/sign-off stage).

50% said there were:

• No proper test management processes.
• No re-use of test scripts across the different on-line products using the same backend systems.
• Not enough sharing of information across the different groups (group = testers, product managers and developers).

1,2: Check with the experts of Continuous Integration (http://testearly.com) regarding the best practices for test management processes.

3: I believe what is required here is a request tracking/product management system (probably more than just a Wiki, or in cobination with one) that is designed to be a convenient tool for multiple teams: developers, testers, support, and product managers.

Prioritize, prioritize, prioritize, …

Commenting on the article by Max Pool, Get Your Manager To Prioritize Your Tasks, I would just add:

• prioritize iteration work in the beginning of every iteration
• prioritize your critical/unexpected requests daily or weekly

And the tools to do both of these tasks efficiently and collaboratively exist.