One Yoxel

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!

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

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

Here is another article that I really liked: The (Not-so) Agile Waterfall, by Ken Knapton.

I have recently been made aware of yet another organization that says they are “doing agile” when in fact they are not. They are in fact following almost a text-book example of the waterfall method, but using agile terms such as “iteration” and calling it agile. They define every iteration up front, and lock themselves into dates when each iteration will be completed, even for projects that will last six months or longer. The development team is strictly held to meeting these dates, and product is not delivered until the end of the project. 

And why does this happen? Ken suggest one reason:

As to the question of why organizations fall back to the old, comfortable waterfall, I believe it comes down to a very simple answer: metrics. Upper management likes to have nice metrics to track the progress of their organization, and the easiest metric to track is on-time delivery.

I guess for the same reason some commercial ALM tools lure you into this trap too. They sell their tools to those managers after all. Their marketing works way too well promoting “agile”:

• Check out RallyDev’s demo: slide#2 talks about roadmap, release, iteration planning. What I get from this is that they suggest to plan a release (3-6 times a year) and lock iterations within that plan. I am not exactly sure what good a 4months plan with locked iterations will do if after your first iteration (2weeks to 1month) your customer feedback shows that you need to re-prioritize and change half of the plan. Or, aren’t you delivering functional software to your customers after each iteration for feedback?
• How about VersionOne’s datasheet: One of the key features Drag-n-Drop release and iteration planning. As for agile, I understand iteration planning or just release planning (if it is a short incremental one, equivivalent to an iteration), but together? This probably means again, create a waterfall plan and lock your iterations within it. Is that agile?

In general if you’re trying to be agile you will have hard times planning something far away in the future. Giving dates for your future releases and roadmap milestones is quite a challenge:

Does “agile” complicate your roadmap management process?

Agile roadmap 

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.

Scott, thank you for your comment to my earlier post GANTT in agile environment. I wanted to respond to it but could not find a short way of doing that so here goes another full-blown post. A comment like this would probably get lost in the comments section.

Is it GANTT or is it MS Project?

Here is an excerpt from Tate’s article which sort of says that even with agile (I even think more so with agile) you still do prioritization, estimation, resource assignment, … So it is not just my words.

When you have a granular, ever-changing list of software requirements (or features or enhancements or whatever) and the team prioritizes and commits to just a few of those each iteration AND the team then organizes their own way of delivering those requirements in the space of a few weeks or less, it is really, really hard to make a Gantt Chart.

You keep the list of tasks (features and enhancements) using some tool today, Excel, MS Word, MS Project, Bugzilla, right? The cost of maintaining the list is always there, regardless of whether you want GANTT or not. If your tool of choice can generate GANTT chart automatically for you then the incremental cost of doing that is ZERO. And if you use MS Project to manage the list then you would not have a problem with GANTT, I believe. But are you using MS Project to manage the list?

The reason people say creating GANTT is expensive, I think, is because they actually maintain the list of tasks in one tool and generate GANTT in another tool (e.g. MS Project). Now, that is a real head ache, I could not agree more! Entering manually all tasks, information about resources, durations, dependencies, every time any of those change in your master list, just to have a GANTT chart? I would not do that, and naturally I would say that GANTT is not worth it. In my opinion the real issue we’re complaining about GANTT is that a typical project management tool (like MS Project, dot Project, Omni Project, you name it) is not designed to be a good tool for a software product manager and it is very painful to maintain a list of changing project tasks in it. I have a feeling that often when people say “GANTT chart is not useful”, they really express their dissatisfaction with MS Project because it is not the right tool for doing their software product management.

Traditional PM tool is not the right choice

Why is not a traditional PM tool convenient for software product management and people prefer to just use Excel or Wiki and make GANTT chart an “escape goat” (I mean discard it and blame it)?

• Because it is not connected to your request/bug tracker (your backlog) where most of the product requirements, enhancements, bugs are already filed, estimates entered, and task statuses available, plus available resources defined (even with their specific specializations; think Bugzilla, Product/Component -> Owner relationship)
• Because it is not a collaborative environment and you have to do all the input and tracking work yourself whereas you could be benefiting from other people’s input.

  The PM tool for a product manager should be a collaborative environment

If you start using a PM tool that is designed for collaborative product management on top of a request tracker which is used by your support, development and QA teams, you will see how much easier it becomes for you. Even the cost of maintaining your blackog and feature lists (the effort and time you as a PM personally invest daily) minimizes because most of the input and status tracking happens without you even knowing about it. Duplicate efforts to input and track data on your side are minimized (sometimes absolutely removed) and the cost of maintaining the project status up to date is spread out among all the team members hence your personal effort significantly decreases.

Back to GANTT charts

In such a collaborative environment where your whole team contributes to the project planning and status tracking, an accurate GANTT chart with the real-time detailed information incorporated in it is suddenly becoming a quite attractive alternative to your burndown chart, in my opinion.

And even with agile teams I would not discard the importance of providing accurate status information to your managers. They do like GANTT charts, don’t they? Any additional level of clarity within your company can only help to succeed with your projects.

Reading about real life experiences with SCRUM is quite interesting. You see, that compared to theoretical description of the process, you always have unexpected tasks that mess-up even your shortest iteration plans. Software design is quite unpredictable but running a software company with customers is even more so .

Check out Tom Harris’ post describing his experience, for example: Scrum Update.

We run into such situations every day. As a matter of fact in our teams we run two queues of requests/tasks:

1. Critical - something you have to jump on right away and fix/implement ASAP (usually some bugs that are show-stoppers for our customers: crashes, major accuracy issues, …)
2. Non-critical (high,medium,low customer urgency) - this is the part of our backlog that we create iteration plans for and execute according to the plans.

Check out my other post on this topic: Urgent vs. Planned
I guess what SCRUM calls ‘velocity’ should help you deal with these situations. You will figure out your velocity over time when somehow handling both critical and planned work in the beginning. When planning for an iteration know your velocity! Or have some other way to account for ‘regular unexpected’.

But even that wont always save you. You will be having times with bursts of unexpected requests. So we do not plan N iterations ahead. We examine our backlog and do full re-prioritization, re-estimation, and collaboration session before each iteration to create detailed plan only for that one iteration. Why bother planning for longer when you know that your priorities will significantly change in the next 2 weeks.

This brings another challenge - your product roadmap. Does “agile” complicate your roadmap management process? That is a topic for a separate discussion though.

But I think those ‘unexpected requests’ are a useful indicator. If they do not allow you to do your iterations at all then may be it is time to stop and think. Your software may be in a stage when you only want to address the critical requests (maturing alpha/beta releases), forget about the iterations for a while then. Or may be something needs to be changed in your development/testing process and it is high time you seriously looked at Continuous Integration.

Cheers.

Have you noticed a significant increase of commercialization of “agile” model and approaches. A few quite successful ALM companies are pushing very hard to create a new market for themselves. And although they are doing a great job educating masses on what agile methodologies are and how they can help your business, they also create certain frame of reference and an “agile” trap for you.

Here is an article worth reading on this topic: Am I Agile or Not?

When trying to satisfy the label “agile” imposed on you by an external opinion or a marketing campaign, don’t you forget that the original “agile manifesto” is simply about these four key points?

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

The specifics and details of how you are going to achieve this are up to your team to decide upon.

Another interesting comment from the article mentioned above:

In an effort to get acceptance in corporate centers, as well as provide a bit of control over the system, there is an increasing standardization of what constitutes an “Agile” practice.

And even this:

VendorX, an ALM provider, recently gave the top ten reasons you might NOT be agile:

1. The “Send/Receive” and “Save As” buttons initiate most team communications.
2. Your whiteboards are mostly white.
3. “Test-driven” still refers to your car.
4. You don’t yet know what PHB stands for.
5. You know what CPM stands for, and continue to rely upon it.
6. You spend more time trying to manage project dependencies than remove them.
7. Someone still believes in the “Can’t Chart.” (Oops, that’s the Gantt chart.)
8. Developers only develop, testers only test and managers just manage.
9. Simplicity is presumed to be simple.
10. A change control board meets…ever.
    

Labeling! I believe my team can be agile with my Bugzilla and my GANTT charts as long as there is no communicational barriers for the team members, and I incrementally release relevant functional software for my customers. And I do not know what Pointy-Haired Boss (PHB) is :). We happen to be doing “Continuous Integration” without knowing that it was called so. And although our whiteboards are not white we quite often do better job with printed reports than story cards. Ask you customers whether you are agile or not, they will know better.

Cheers

A very valid point made by the following post Is Agile Enough? (part 1)

Therein lies the key omission of Scrum (and most other agile methods): The backlog of user stories are taken as a starting point. They are not examined for their “quality”, “completeness”, “cluefulness”, budget impact, etc. The user stories are assumed “good”, and used as an “input” to the Scrum process.

(… good read …)

Does your request tracker allow you to have hierarchical requests so you could be breaking down original user stories and requirements into more detailed tasks suitable for iteration planning?

Does it track the duplicate requests so you could see the most popular requests and prioritize accordingly?

Does it allow you to specify dependencies between requests and respect those in iteration plans and project deadline estimations?

Does it allow your customers selectively (in “controlled by you” fashion) access the request records to give you more feedback regarding the content and priorities?

Check out a demo account at www.yoxel.com to see how Yoxel request tracking system can help you do all that within agile environment.

I believe in the future you will see more and more software solutions bridging Customer Relationship Management (CRM) and Product Lifecycle Management (PLM/ALM/SLM).

Your customers will be involved more in your product requirements planning/prioritization/feedback process, and you will be collaborating more with your customers and listening more to them. Well, that is if you want to give your customers what they want, be competitive, and stay in business :). This aligns really well with the “agile” product management model (short release cycle and frequent customer feedback), which there is so much hype about already.

Today’s CRM is very one-sided - just your view of the customers (log of calls, contact information, sales forecasts). But you also need to know their view of you. Companies like SATMetrix and IdeaScope preach about that 2nd side of the relation with your customer trying to create a new market for themselves. They call it Customer Experience Management (CEM).

To get that precious feedback, guidance, and loyalty from your customers you need to give them something first, right? That something is your product, your enhancements that are relevant to customers needs, your services that are relevant to their goals. So the way I see it is that your product as a focal point of your business really requires all those pieces working together: CRM, CEM, PLM.

So you will probably see CRM, CEM, PLM solutions integrating more with each other or overlapping more in terms of their own functionality. You already see CRM trying to provide project management capabilities, or PLM trying to provide customer support capabilities, or CEM trying to do product requirements management. Here is a good example where things are going exactly the way I expected:

http://www.f4tech.com/product_mgr.jsp

Cheers!