Some time ago I found an approach that work of an analyst in a team could be performed better by a software architect. As one person can connect both roles, it provides better view in code, estimation and information, if feature could be easily implementable. This solution is very attractive from a budget point of view, because we can cut off some costs and shorten communication chain between a team and product owner by removal of analyst. Team of developers could adjust code better to implement required features, so time of analysis will be reduced and overall project will be finished earlier with higher quality. Initially when project scope is not so big, work could be performed without any issues. On the other hand it may appear some changes in requirements or increment of complexity in features. Connection of both roles becomes much more difficult in such cases. It doesn’t make any problem when work is done in one pipeline, but when appear more problems, pipelines and tree branches from main feature than architect can be too overloaded with additional duties.
First problems are coming out
First issues appear when a project is getting bigger and architect doesn’t have so much time to focus on preparation proper descriptions for new features. Too vague specifications for features are more difficult to groom and estimate complexity/story points. Problem is moved to next element of chain – developers and testers. As a result further talks with project owner and architect will be proceeded on their side. Developer could find some boundary cases not recognized in analysis in a task, so the task may be returned to grooming phase. When feature is very important and there is no time for regrooming, developer starts reanalysis of requirements and adds improvement for implementation details. At this moment developers and testers start to take duties of lacking analyst. Overall work becomes less effective, in some cases frustrating for team members. Implementation of vague described functionalities may take weeks, because task which was initially relatively simple eventually appears to be very complex and time consuming. More and more such features makes grooming useless and not helpful for implementation.
Noises in communication
Next drawback related to lack of analyst is lack of a link in communication chain. Analyst may be treated as a filter and buffer between product owner and developers team. Let’s imagine that every team member directly contacts product owner and discusses details – discrepancies in information are inevitable. In agile methodologies there is no need for a very broad project documentation like in cascade methodology, thus communication channels must be organized wisely. Without this aspect team could experience difficult for detection problems. Developers have different knowledge about project and its parts, sometimes such information is opposite. Another problem is related to human factor, it is trivial but everyone could perceive functionality from his own perspective. Finally there is no central point in which actual project knowledge and general overview of entire project are gained.
How to solve this problem?
There is no golden mean for this problem. If some decisions about work without analyst in team were made, then with progress in a project, it will be harder to add such person later, threshold will be to high. When project begins, analysis of additional costs, time required for preparation the analyst to a project and stability of further work when a new person is added to team, should be made. In majority of cases this option is left out and work is continued in the same form as it began, no changes are made. On the other hand, leading a team without an analyst, may cause greater chaos when requirements will be changing and scope of the project is still uncertain. Sometimes it is too late for a revolution in a project, because each new action can be cost consuming, adds some disruption and profit may be very small. We have to remember that the most important in project is a customer. Learn some lessons on our faults or successes.
How to plan properly work of analyst in a team?
Agile methodology gives us very good tools for team management in projects, but it can’t be applied without deeper thinking and modification. It is a pack of tools, which is not a ready solution that could be used out of the box and make any project successful. There are different approaches related to a work of an analyst in a team like:
- no analyst,
- analyst in a team,
- analyst outside of a team.
This topic could be extended to chapters or even whole books on how to organize work in a team. Our decision should be based on many factors, like: size of a team, scope of project, experience of developers, whole time reserved for project and other properties. There is no single solution, but a choice of an option with an analyst in a team gives us a possibility to opt out in the future. Option without analyst will be more difficult and costly in modification. Everything has its advantages and disadvantages, but when we try to implement a solution for a long term project we must take into consideration place for future changes.