Comments on: Changes in development methodology http://wealthfly.com/blog/2007/06/11/changes-in-development-methodology/ A blog for investment advisors, brokers and financial planners. Tue, 06 Jan 2009 08:10:48 +0000 http://wordpress.org/?v=2.3.3 By: Matt Abar http://wealthfly.com/blog/2007/06/11/changes-in-development-methodology/#comment-209 Matt Abar Mon, 18 Jun 2007 07:59:28 +0000 http://wealthfly.com/blog/2007/06/11/changes-in-development-methodology/#comment-209 Techfi used agile development obviously. I'd like to clarify that we used people from both our sales and support departments in the "stakeholder" role as stand-ins for our customers. If Techfi had continued, we eventually would have added actual users to the stakeholder list. But, since we were moving so quickly, sales/support was a good substitute. Both departments had a good handle on what our prospects/clients wanted in the software. We would make a big list in permanent marker, sorted by priority. Then the development team would sit down and put rough timeframes on each feature request. Then I would pick the actual feature list based mainly on those two pieces of information. If an important feature took too long to implement, it would be dropped and if a less-important feature was quicker, it could be moved up. These lists were hung on an easel in my office so anybody who came in could comment on them and we'd move things around based on feedback. Occasionally we would do an emergency release if there was something that took priority. Once we did a release that was too buggy and we put everything on hold until it was cleaned up. And, right at the end, we decided we needed to do an emergency update to the AdvisorMart interface to respond to competitive pressures from StatementOne. We dropped everything and started working on that. Actually I "left" in the middle of the project and it was never finished. As a result, we lost most of our big AdvisorMart prospects and it's probably why Advent abandoned the broker/dealer market. But I digress... Techfi used agile development obviously. I’d like to clarify that we used people from both our sales and support departments in the “stakeholder” role as stand-ins for our customers. If Techfi had continued, we eventually would have added actual users to the stakeholder list. But, since we were moving so quickly, sales/support was a good substitute. Both departments had a good handle on what our prospects/clients wanted in the software.

We would make a big list in permanent marker, sorted by priority. Then the development team would sit down and put rough timeframes on each feature request. Then I would pick the actual feature list based mainly on those two pieces of information. If an important feature took too long to implement, it would be dropped and if a less-important feature was quicker, it could be moved up. These lists were hung on an easel in my office so anybody who came in could comment on them and we’d move things around based on feedback.

Occasionally we would do an emergency release if there was something that took priority. Once we did a release that was too buggy and we put everything on hold until it was cleaned up. And, right at the end, we decided we needed to do an emergency update to the AdvisorMart interface to respond to competitive pressures from StatementOne. We dropped everything and started working on that.

Actually I “left” in the middle of the project and it was never finished. As a result, we lost most of our big AdvisorMart prospects and it’s probably why Advent abandoned the broker/dealer market. But I digress…

]]> By: Mike Benson http://wealthfly.com/blog/2007/06/11/changes-in-development-methodology/#comment-206 Mike Benson Thu, 14 Jun 2007 14:25:05 +0000 http://wealthfly.com/blog/2007/06/11/changes-in-development-methodology/#comment-206 I think your right about things getting lost with salespeople. There are some problems with that method. In my experience salespeople tend to have niche of client types they work with and you can end up with a pretty narrow view. Including all the salespeople is not much better, you end up with a product that is not really usable to any of your clients. Anyone remember Techfi Trader?? All things to everyone ended up being nothing to everyone because it was so complex. I think a focused client group that can really direct a product is the best way to go. That way your key players really understand the trade-offs and can hash out a method that would work for everyone. I also like having developers on-site. I can't tell you how many times I have been in someones office watching a person do the same task over and over and wondered why they don't automate the process. Developers think that way, Advisory staff generally does not. I think your right about things getting lost with salespeople. There are some problems with that method. In my experience salespeople tend to have niche of client types they work with and you can end up with a pretty narrow view.

Including all the salespeople is not much better, you end up with a product that is not really usable to any of your clients. Anyone remember Techfi Trader?? All things to everyone ended up being nothing to everyone because it was so complex.

I think a focused client group that can really direct a product is the best way to go. That way your key players really understand the trade-offs and can hash out a method that would work for everyone.

I also like having developers on-site. I can’t tell you how many times I have been in someones office watching a person do the same task over and over and wondered why they don’t automate the process. Developers think that way, Advisory staff generally does not.

]]> By: Bill Ramsay http://wealthfly.com/blog/2007/06/11/changes-in-development-methodology/#comment-203 Bill Ramsay Thu, 14 Jun 2007 13:45:24 +0000 http://wealthfly.com/blog/2007/06/11/changes-in-development-methodology/#comment-203 You are spot on Mike. We were just talking about this topic last week, as we were working on systems to provide an account transfer process as we're in the midst of transferring all our TD Ameritrade accounts to Pershing. Your point is exactly why we don't outsource development. To go one step futher, how about having developers on site with a small number of key customers (or one might be enough in some situations). This would allow the developers to see opportunities that a customer or salesperson would never see. There are several problem with relying just on the customer to suggest features- mainly because they don't see the relationships in all the data relevant to their business and customers. I would think in some cases it would get even worse when requests get translated through salespeople. You are spot on Mike. We were just talking about this topic last week, as we were working on systems to provide an account transfer process as we’re in the midst of transferring all our TD Ameritrade accounts to Pershing. Your point is exactly why we don’t outsource development.
To go one step futher, how about having developers on site with a small number of key customers (or one might be enough in some situations). This would allow the developers to see opportunities that a customer or salesperson would never see. There are several problem with relying just on the customer to suggest features- mainly because they don’t see the relationships in all the data relevant to their business and customers. I would think in some cases it would get even worse when requests get translated through salespeople.

]]>