189
product team make project risk management a priority, discussion will be more fruitful.
Teams that avoid defensiveness move forward faster and with their credibility intact.
Development projects sometimes get behind schedule. It is a fact of life in software
development. But, top management and product teams expect timely delivery of technol-
ogy, especially where the technology creates competitive advantage. This puts pressure
on the development team. If deadlines must be met and the team is behind, the team can
simplify the scope or designs or cut features.^4
Sometimes unavoidable design decisions complicate the implementation of a feature,
such as integration with legacy code or functionality, or support for multiple environ-
ments. In general, the team should always implement the simplest solution that meets
requirements today. Planning too far ahead or too broadly can induce delays. Some devel-
opment teams get bogged down designing robust architectures, portions of which may be
irrelevent to the success of the trading system. Overdesigning and overbuilding are signs
that the development team is unable to focus and prioritize features.
Sometimes, a specific feature may by implemented through a simple, alternative
method that still solves the business purpose. For example, if a trader wants real-time,
straight-through processing of trades, he may actually accept hourly batch processing.
While the alternative solution may be suboptimal, the quicker implementation may speed
up development and permit trading to start on schedule.
As a last resort, the development team may need to eliminate low priority features
to satisfy a timebox deadline. This is why business priorities must be understood before
each iteration. The development team may spend weeks working out a technically dif-
ficult problem that is relatively unimportant. They may spend even more time explaining
why several simpler features with higher priorities are not done.A development team spent several months building redundant and backup systems for real-time, market
data feeds. A year behind schedule, they still had not yet programmed the algorithms for performance
metrics. The customer ’ s priority was working software and performing systems. Backup data feeds were
a luxury that could wait till later versions. The firm missed a tremendous business opportunity.The development team must communicate with the product team and top manage-
ment about simplifications and proposed cuts as soon as possible. This will allow all
interested parties to renegotiate priorities. In the end, the customer, that is, the product
team, decides which features to defer. When its people involve others in tough decisions
early, an organization can build mutual trust, respect, and confidence, rather than blame
and adversial relationships.20.5. LOOP 1: Document Software Requirements
The product team creates the SRS, the starting point for the development team. The SRS
defines the functional and software quality attribute requirements needed by the product
team. (Software quality attributes are defined in Chapter 2.)
Together the two teams agree upon a release plan. From then on, the agile development
team plans, designs, builds, and tests the technological implementation of the trading/
investment system. Before each loop, the development team should meet to plan features
and tasks and schedules for the ensuing iteration. The first loop will design, build, and test
the business tier. While we have devoted only one loop to this section, we fully expect and
advocate that the tasks be broken down into many, smaller iterations.20.5. LOOP 1: DOCUMENT SOFTWARE REQUIREMENTS