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 have 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!
It’s time to begin to standardize common names for certain roles and activities. The Rational Unified Process (RUP) and other processes have created a lot of progress toward improving this, but it’s a non-trivial issue because of certain factors such as team size, the team process, people’s skills and interests, etc. We will now look at some suggestions on how to go about resolving this confusion, both on this project and for future projects.
Introduction
Let’s look at some role examples:
· Analyst, business analyst, requirements specifier, requirements gatherer, use case modeler, business modeler, 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 and 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: Looking in the class diagram, one person does many activities. Of course, an activity can be done by many people (e.g., use case modeling 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 makeup of a collection of many activities. Similarly, an activity can be done by many roles (e.g., use case modeling 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 diminishes 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. Let’s hypothetically assume that we reduce the same team. As the team shrinks in size, Mary, who was our business analyst on a much bigger project, gets to do all the requirements gathering, workshop organizing and business analysis in a more agile process. Let’s say that we lose Harold and Pete as requirements gatherers. Mary simply has to take up doing some of the activities that Harold and Pete were responsible for when we were on a bigger team.
The point of this is that 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 that 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 also 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?
The outcome of these decisions (and this was only a small snapshot of the business and 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
It’s fine to spend 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 that 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. Very likely, it will not be what is in the plans! They then 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. Does this sound familiar?
Peoples' Skills and 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 to maximize his staff potential to their best most experienced skills. Furthermore, 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 it’s needed, etc. What the Real Problem?
I'm sure that 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 modeling all requirements. After being on the project for a couple of weeks, I would soon get to know all the idiosyncrasies of the team and its interrelationships. This is fine for a team of five or eight people, but any bigger and it becomes 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 realize what they are responsible for, how are they ever going to get it right first time? This is where many 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."
If we do anything, it should be to get the process for the iteration defined as early as possible (i.e., before the iteration starts) on medium to larger teams, then publish it to all concerned through a verbal presentation, then document it on the project web. "I love deadlines. I love the whooshing sound they make as they fly by." Douglas Adams
Suggestions
While there is no easy answer to this problem, most likely there are some ideas that could make it a little easier to live with (probably more relevant for teams larger than about 10 to15 people):
· It would be useful if there were 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 to which they had tailored their process to conform. I realize 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:
1. What the overall goal is.
2. What the individuals are responsible and accountable for.
3. What their teammates are responsible and accountable for, so they know who to talk to.
4. Another set of ideas that is coming out of the Agile and XP methodologies is to try to 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.
5. 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 benefits of doing this properly on one project is that for subsequent projects is that you can use the project intranet set-up used last time. Most likely, you will obtain a good amount of re-usability in terms of the activities and roles. Because of this, the job won't be nearly as hard the second time round.
Conclusion
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? I hope that 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 and on an established project web. Configuring the process and defining the development case will be much quicker and easier in the future. The output will be better quality software delivered closer to the deadline, and by a team of people who mostly work well together and enjoy the experience.
References
1) Edwards, Charles www.processwave.net - July 2002
