Single Dealer Platform (SDP) Team Dynamics


Stating the obvious: A SDP build is only as good as the team that is building it. Morgan Stanley Matrix (launched last year) moved the goals posts of what an SDP should look like. Anyone building an SDP today needs to be looking at the next jump in terms of business functionality coupled with User Experience (UX).

What does this mean from an SDP delivery team perspective? For anyone who has worked on a front-office project, the concept of moving forwards will not be new. An SDP delivery team needs to push in terms of delivering an SDP vision, and not drop back to the age old standard look and feel of the pre-Matrix SDP’s. The team needs to be “driven” from the perspective of ensuring that the hours within an available work week are spent appropriate in driving business value, and hence achieving the goal of delivering an SDP. The SDP war is all about gaining desk real estate space from the buy-side. If you can’t match competitors in terms of price delivery, coupled with standard business functionality, and offer a business feature over and above the competition which will keep the clients logging into your SDP each morning, you’ve going to loose the war.

So cutting to the chase, SDP teams need to be lean. Leverage the Product Owner, create the UX vision, and feed the build pipeline in producing a modular SDP platform.

There are numerous issues standing in the way of delivery – not just for an SDP team. Many of the issues I have blogged about before. One of the important issues is ensuring that the SDP workforce get the “front-office delivery mentality” – push, make decisions, constantly move forwards. “Lean” means cut the fat. Cut the wasted time in meetings, cut the silly and wasteful conversations.

Scrum/XP will help with delivery, but without the correct mentality the team will fail, the business will get disheartened, and the project will fail.

Things to look out on a team:

  • Daily scrums have too many people – classic problem which I have blogged about before. Solution: Split the team
  • Stories have vague tests – an age old problem, and probably true on a high percentage of teams. Solution: Team needs to be educated on story writing
  • Story estimate – team under estimate. Again we have all seen this. Often driven due to the team forgetting about testing. Solution: Retrospective to review stories and estimate vs actual
  • Lack of understanding of roles/responsibilities between the business analysis, user experience, software engineers, test engineers. Solution: Team discussion, retrospective
  • Lack of ScrumMaster support. Solution: ScrumMaster needs to review his role and responsibilities
  • Lack of team motivation/drive. Solution: All of the above, coupled with allowing the team to self-managed, works with a passion, and drive to make the project succeed. Team buy-in

~ by mdavey on January 19, 2010.

2 Responses to “Single Dealer Platform (SDP) Team Dynamics”

  1. Would you be interested in a conversation about you moving to another bank? You seem very knowledgable.

  2. […] Posted on March 5, 2010 by Martin Tyler When Matt Davey blogged about Single Dealer Platform Team Dynamics, it was mainly about methodology, but it brought up a point relevant to this blog post: The team […]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

 
<span>%d</span> bloggers like this: