Avoid Role name Confusion

Abstract

Don't you find it confusing when you go from one company to another and find all sorts of different names for similar roles people play in the IT software development process? I've had heated debates with people only to find we were in violent agreement and it was the use of different terminology that was causing the incorrect interpretation, because we were ultimately both trying to say the same thing. This doesn't only happen with Roles and Activities on projects but with many different terminologies meaning the same thing!

Its time to start trying to standardize on common names for certain roles and activities. The Rational Unified Process (RUP) and other processes have gone a long way towards improving this, but its a non-trivial issue because of certain factors such as team size, the team process, peoples skills and interests, etc. We look at some suggestions as to how to go about resolving this confusion, both on this project and for future projects.

Introduction

Lets look at some Role examples:

• Analyst, Business Analyst, Requirements Specifier, Requirements gatherer, Use Case Modeller, Business modeller, Systems Analyst, Domain expert are all roles form the Business / Requirements end of development. Many of them have an intersection of common activities, but there are also some roles that have no common activities, unless there is a really small team and one person is doing the effective equivalent of multiple roles.
• Developer, Coder, Programmer, Implementer, Techie - once again all very similar, but subtly different in some cases. Typically a developer implies more than a programmer or coder - they do Analysis & Design also.
• Architect, Data Architect, Information Architect, Business Architect, Functional Architect, Systems Architect - say no more!

The problem stems from the fact that there is a collection of related activities that people do as part of their job.

Person - Activity: So looking in the class diagram on the right, one Person does many Activities. Of course an Activity can be done by many People. e.g. Use Case Modelling Workshop typically may have John (a User), Mary (a Business Analyst), Pete, Harold (some requirements gatherers), etc. in attendance during a workshop.

Role -Activity: A Role is defined by its make up of a collection of many Activities. Similarly an Activity can be done by many Roles. e.g. Use Case Modelling Workshop. This can be done by Requirements Analysts, Architects, End Users, etc.

Person - Role: One Person may have many Roles they play simultaneously because of someone being on holiday, or at different times in the project. e.g. Mary who is a Business Analyst, can also double her role as a Requirements Reviewer on the team during the same iteration.

Team size matters

The issue is further impacted by the size of the team. Generally the smaller the team, the more Activities that have to be performed by a much smaller set of people. The assumption is largely that the base Activities do not reduce as the number of people diminish on the project. One accepts that on huge projects, certain activities are done that in no way would be done on much smaller projects, but there comes a point where the list of Activities remains constant and is usually a much larger list than the number of people to execute these Activities.

Lets hypothetically assume that we reduce the same team. As the team shrinks in size, what happens is that Mary who was our Business Analyst on a much bigger project, gets to do all the Requirements gathering, Workshop organising and Business Analysis in a more agile process. We loose say Harold and Pete as requirements gatherers. Mary simply has to take up doing some of the Activities that Harold and Pete were doing when we were on a bigger team.

The point of this is Mary has always been called after her main role of a "Business Analyst", and on a smaller team she would be doing the roles of Requirements Gatherers, Workshop scribes, etc. Even if mary did rename her role, it would still probably not describe the Activities she is responsible for to someone who had just come into the team.

Process Matters

Not only does the size of the team affect the Roles and Activities, but so to do the particular Process Framework and Methodology we choose to follow on the project. What approach we are going to use for gathering requirements? Will we only do System Use Cases? Or will we also do Business use Cases? Will we build a Business Object Model either way? Are we going to document Business Rules separately? etc. etc.

The outcome of these decisions (and this was only a small snapshot of the Business & Requirements discipline of the project) will directly affect the Activities that are going to be configured for the project process and in turn who will be responsible and able (skill and experience wise) to perform them.

Getting process defined in time to do the iteration matters

All very well spending all the time creating fancy plans for how the project will be done, but while the Project Manager is doing that, many of the rest are waiting. Or are they? No way! Most IT people I know are working away doing what they feel is best (in all good intentions for success).

Often by the time the Project Manager or team presents their plans, the rest have already done their own thing and are halfway through. And guess what? Very likely that it will NOT be what are in the plans! Then they spend the rest of the iteration trying to play catch-up and figure out what they have versus what they want and how they will get the team back on track. Sound familiar?

Peoples' Skills & interest areas Matter

There is another dimension to this worth considering. People's Skills and interest areas. If the Project Manager inherits a team of people, the task is to understand what there is to work with in terms of people skills and experience. Obviously the Project Manager should try and maximise his staff potential to their best most experienced skills. Further more; also try and put them in areas they are very interested in working in, even if their skills are not entirely suitable, as self motivation can be a huge driver for success.

Trying to obtain this information while the project is underway, can be disruptive, time consuming and from experience, rather political. People start wondering what the ulterior motives are for wanting to know what they know, especially when times are tight and people are being made redundant. Make sure people are told what the exercise entails and that training will be given where its needed, etc.

What the real problem?

I'm sure most people could live with the fact that I got confused when they told me they were a Business Analyst and it didn't immediately imply that they were also in charge of gathering and modelling all Requirements. So big deal! After being on the project for a couple of weeks, I'd soon get to know all the idiosyncrasies of the team and its interrelationships. Fine for a team of 5 or 8 people. Any bigger and it starts getting to be a problem. Things start falling between the gaps, especially when everyone is under tight deadlines.

The real problem is that if the people themselves don't realise what they are responsible for, how are they ever going to get it right first time? This is where lots of errors creep in. "Oh! I thought Joe was going to write that code" or "I thought Mary was going to identify and model all the Actors."

Suggestions

While there is no easy answer to this problem, there are probably some ideas that could make it a little easier to live with (probably more relevant for teams larger than about 10-15 people):

• It would be useful if there was an international standard set of naming conventions for roles and the activities they perform. RUP, as mentioned above, has gone a long way toward putting a stake in the ground to define these in some detail. Some other processes and methodologies have too, but there is still no real agreement. Lots of discussion on the forums though; which is good for the longer term.
• Teams should then map individuals onto a collection of Roles and selected Activities that they had tailored their process to conform to. I realise this is extra work and is not that agile, but just doing the exercise forces the Project Manager to think through the process and the work load on individuals.
• Map these Roles and Activities considering the skills and interests of the People on the team.
• This mapping could be put up on a central intranet for the project, and adjusted per iteration as things change. This helps to focus the team on:
  • What the overall goal is.
  • What the individuals are responsible and accountable for.
  • What their team mates are responsible and accountable for - so they know who to talk to.
• Another set of ideas that is coming out of the Agile and XP methodologies is to try and rotate people per iteration, so that they work on different parts of the system or sub-system. This makes for a bigger understanding of what's going on in the project and the code.
• The more this flexibility is implemented, the more we will need to be on-top of who is doing what, so that we know who we should be talking to on the project. It's definitely easier to manage on smaller projects.

One of the big benefits for doing this properly on one project is that for subsequent projects, if you take the Project intranet you set-up last time, you will get a lot of re-usability in terms of the Activities and Roles and the job won't be nearly as hard the second time round.

Conclusion

There is nothing new here. I'm sure you have all experienced this situation to a greater or lesser extent throughout your software development careers. The question to ask yourself is, are you or your team doing anything about trying to improve the status quo? Hopefully these ideas will help you consider getting a better development process and team spirit going.

I envisage a day when all new projects start, with a list of predefined activities and roles that were harvested from the previous set of projects, on an established project web. Configuring the process and defining the Development case will be much quicker and easier in the future, the output of which will be better quality software delivered closer to the deadline. But most of all by a team of people who work well together and who enjoy the experience.

References

Edwards, Charles.     www.processwave.net, July 2002.