≡ Menu
Pawel Brodzinski on Software Project Management

MSF Basics: Team Roles


This is another article from MSF Basics series. This time I’ll describe roles in MSF team. In MSF 3.0/3.1 there are 6 of them, version 4.0 adds one more.

The Team

Nice and lofty rule in MSF says that there’s a team of peers and all decisions should be made by achieving consensus. That means an organizational structure should be left behind and the whole team should be treated on equal terms. You should try hard to organize people this way, but probably you won’t reach the ideal. Don’t worry – being close is also counted. Thing you should remember here is that everyone should be able to contribute in decision making. At least in making those decisions, which can be made collectively.

It’s funny that if you reached the ideal you wouldn’t be able to make most decisions because if they have to be made unanimously there’s always someone who doesn’t agree (I believe there has to be a Murphy’s Law for that). Solution is to have the one more equal among all equals. It’s the person who is in charge to force a decision when consensus can’t be achieved. Usually it’ll the same person who is a manager in organizational structure.

Roles

There’re 6 (7 in MSF 4.0) roles. It doesn’t mean that you have to have at least 6 people to create a MSF team. Some roles can be merged, so one person fulfills a couple of them. Every role can be fulfilled by more than a single person. Smallest MSF team counts 3 people. Guys from Microsoft say that the biggest effective MSF team counts about 20 people. There’re of course methods to scale MSF to bigger teams. I’ll write more on that in another article.

List of MSF roles contains: Product Management, Program Management, Development, Test, User Experience (former User Education), Release Operations (name brought by MSF 4.0; former Release Management from version 3.1 and Logistics from version 3.0). A new role introduced by new version MSF is Architecture.

Product Management

This role is responsible for delivering a solution that fulfills customer’s needs. Product manager is an advocate of customer for the team. Her main goal is to keep customer satisfied, so she usually tries to smuggle as many cool features into development as possible. Cool features are something customers would like for sure. Product manager usually talks with decision-makers, not users, so she’ll come with knowledge about things which are selling the product. The opposite role for product manager is

Program Management

This hard-working and undervalued role (OK, you got me – that’s my role) is responsible for delivering the solution with planned functionality, on time and in budget. Like someone said program manger should ensure that the right product is delivered on the right time. It’s obvious that program manager’s job is easier if there isn’t much to do – there’re no risks with deadlines or budget then. That’s why program manager will always try to cut as much functionality as possible. Product and program managers make a well-matched couple to fight… er… discuss product functionality. The program manager is usually the one who is “more equal”.

Development

Someone has to develop whatever those guys above would come with. Any volunteers? I talk to you, my developers… Developer is responsible for (you won’t believe) development. In MSF there are no designers and coders – both fulfill a development role. I think developer’s tasks are rather intuitive, so no detailed explanation is needed. Where there’s code there should be someone who will verify it. This is the task for

Test

Another easy to define role. Tester ensures that the product is stable, especially that it’s stable from customer perspective. She’s tasks covers not only verification if a program doesn’t have any bugs (of course it has), but also ensuring that functionality covers customer’s needs and fulfills requirements list. Tester should catch every issue like a bulldog and make sure it’s addressed (what a nice word) and resolved. It’s a cool role because you can be malicious and it counts as a positive.

User Experience

An advocate of a user for the team. The user, not the customer. There’s a great difference. Customer buys your software for his users. Users didn’t choose to work on your product, but still they can be happy (or in many cases unhappy) with it. Quality of people working in user experience is counted in user satisfaction rate. Preparing user documentation, forcing tiny improvements making the product user-friendlier, trainings, creating different materials dedicated for users (e.g. tips & tricks, FAQs etc) – these are all tasks for user experience.

Release Operations

This role delivers (in their own hands) the solution to the customer. Range of tasks performed by release operations varies the most within MSF roles. It can be just uploading a new version to the web site but it can be implementing whole solution in customer’s environment either. It’s hard to describe tasks performed by release managers, because it’ll differ vastly between the one whose goal is to put the boxes on the self and the one whose goal is to deliver a carrier grade system for e.g. mobile operator. A brainwave from MSF authors says the product delivery should be smooth (another nice word).


Architecture

Last but not least. The brand new role introduced by MSF 4.0 the architecture. It’s probably the greatest thing MSF 4.0 introduced. Architect is responsible for solution design on a high level. Integrating designer role into development works well, but when there’re many developers someone should coordinate their actions on higher level, yet still having technical background. Before MSF 4.0 this task usually landed on program manger shoulders, even though there were quite often a dedicated architect in the team whose role was defined rather different than program manager. Now, with MSF 4.0 issue disappeared and we have a new role for software architect. He’s a translator between program managers and developers. If you aren’t ashamed of code and design of the system after few years of development it’s a time to give your architect a raise. He’s performed well.

Defining Your Role

It’s very easy to define your own role (or roles) basing on elementary knowledge about MSF roles. After short practice it becomes very intuitive. It’s easy like whole MSF.

in: project management, software development

0 comments… add one

Leave a Comment

Next post:

Previous post: