CASE STUDY: TradeStation
2012 Barron’s Award
Best trading experience
and technology
TradeStation Receives Highest Rating – 4 ½ Stars – in Barron’s Annual Ranking of Online Brokerage Firms: higher than Schwab, Fidelity, E*trade and 20 others
In the March 2012 Barron’s magazine review of 27 online brokers, TradeStation received the Highest Overall Ranking for Online Brokers (4 ½ stars). TradeStation also beat all competitors in three additional categories: ranked Best for Frequent Traders, Best Trading Experience and Technology and Best for International Traders.
- Highest Overall Ranking – Online Broker (4 ½ stars)
- Best for Frequent Traders – 2nd Category Win
- Best Trading Experience and Technology
- Best for International Traders – 2nd Category Win
Background
TradeStation provides a premier brokerage-trading platform for rule-based securities trading. Starting in 2009, Keith Black, John Bartleman, and their teams applied the framework for an all-in, all at once agile transformation that involved over 100+ practitioners at that time. While there were many challenges, a few of which we will highlight below, the result was successful as they were able to significantly improve productivity of development and resultant product quality. In 2012, TradeStation won the Barron’s 2012 award above, highlighting the “best trading experience and technology”. Keith and John attribute much of that success to their new, scaled agile paradigm.
Experiences at Trade Station
On Product Managers and Product Owners
As we describe in Product Owner, SAFe recommends a dual role approach to fulfilling the traditional Scrum Product Owner role, a more market-facing (and more traditionally extant) Product Manager, each supported by more technical, team-based Product Owners. TradeStation was one of the places where this patters was initially developed, and successfully applied. Even then, there were challenges in filling these critical roles, as John describes:
“Before transitioning to agile, our product management team was made up of ten product managers who reported into development. When we transitioned to agile, seven of the ten product managers became full-time product owners; the other three now focus on the market-facing product manager role. This separation of labor and concerns has helped us bring additional focus to both the market and technical aspects of our solution.”
John then comments on the staffing challenge: “When staffing the product owner role, I would have preferred to use a few lead developers and/or testers, since they have the domain knowledge and technical expertise; however, we are reluctant to do this because of the impact on development resources. Therefore, we hired a few additional product owners from outside the company. These people need to be technical but also need to have good industry-specific experience, and that is a difficult combination to find. So far, former developers/tech leads with business sense and good project management skills seem to be best fit . . . in my view at least, technical skills are mandatory, and domain experience is a plus whenever I can get it.”
On Feature and Component Teams
Another interesting discussion (and debate) arises around the organization of the teams. In the Feature and Component Teams guidance, we describe a typical “mixed mode” where teams are organized around end-to-end feature delivery wherever possible, while other teams are organized around common components or services.
Even in light of this advice, we must also recognize that features and components are both abstractions, and the line is not so clear. One person’s feature may be another’s component. And sometimes a single feature may best be implemented as a stand- alone, service-oriented component. This debate was highlighted in Agile Software Requirements, where Tradestation was highlighted:
TradeStations online trading system where “charting” is a key capability for the trader. A few co-located agile teams work together on the charting function. On the surface, that looks like an excellent example of a feature team, because charting certainly is a major feature of the system.
When new online trading capabilities are developed, such as “trading foreign exchange currencies (Forex),” new chart functionality must be added. However, driving this new chart functionality are major components such as streaming data, account management, and interfaces with Forex exchanges. Is the new feature value stream described as “trading Forex all the way through the specialty chart function?” If so, that would make an obvious vertical feature stream, and the teams might reorganize by taking some members of each component team and creating a new vertical feature team for Forex trading. Or is the feature “trading of Forex” plus “charting Forex,” in which case the charting team is already organized appropriately?
Is the charting capability a feature set or a component? Both?
Does it matter what you call it?
Even in the case where it is clear what you call it, is a feature team always the best choice? Keith Black, notes this:
“Online trading requires a great depth of technical expertise and industry knowledge at many different levels. We could not reasonably form feature teams that included members from every component area. Therefore, for our transition to agile, we organized around component teams and, through maturity, we are now in special cases putting together feature teams where it makes sense. While feature teams are excellent at driving an initiative through completion, in some cases they simply don’t make sense. For example, if you have twenty feature teams and they all rely on a common component, such as a time-critical online transactional processing engine, it may be unadvisable to have 20 different teams sticking their hands into this critical component. Rather, you might choose to have these changes controlled by a single team that can broker the needs of the 20 teams and make sure they don’t jeopardize areas they don’t understand by making changes for their particular features.”
===========
Sep 2013 update: here’s a recent update from Keith Black on this topic.
