Improved software quality and faster release cycle
Improved requirement setting accuracy and requirement quality
Increased competence development and information sharing
These main goals are explained more detailed in the following subsec-tions.
3.2.1 Improved software quality and faster release cycle
High quality of software products is one of the basic competitive require-ments. On the other hand, lack of quality very soon will impact the overall success of the software product by negatively impacting the customer per-ception of the product and the whole software supplier company. There-fore, it is of utmost importance, that any quality issues and faults in the software are identified and corrected as soon as possible.
There already are strict quality criteria in place in NSN product creation to ensure that only high-quality products that fulfill the defined criteria, are delivered to the customers. Software quality is ensured in all phases of the product creation process, e.g. by reviews of the product artifacts like spec-ifications and by verification of the produced software at different levels.
However, the phase when the errors in the software which have the widest impact at system level are found, is often quite late in the project, e.g. in system verification when the different products with new software are fi-nally put together as a system. Correction and reworking usually takes some time, which delays the final verification and acceptance of the soft-ware. Therefore, in the worst case, the whole software release may be de-layed.
The preventive action against project delay is to perform system-level ver-ification earlier in the project than currently. It means a change towards Agile working model in the system verification phase too. This corre-spondingly sets pressure for system specification and requirement defini-tion: the most important and riskiest system-level Use Cases and require-ments need to be available early enough in the project. This is necessary to enable software release and iteration planning, and to enable planning and running the necessary test cases already during the iterations of the pro-ject. Based on the requirements and Use Cases, it has to be possible in ver-ification planning phase to reach sufficient test coverage for the function-alities included in the iterations with an optimal test case amount.
When missing requirements are identified during iterations, they can be implemented and verified during the coming iterations of the project.
Software development becomes more efficient, because less visiting in the previous phases has to be done, and thus less amount of rework is needed when compared to Waterfall model.
From a project management viewpoint, this approach brings more visibil-ity to the actual software project readiness. When a better visibilvisibil-ity and predictability to the software project is gained, the project planning be-comes easier and project delays can be to a greater degree avoided, which in turn helps to shorten the release cycle.
3.2.2 Improved requirement setting accuracy and requirement quality
From customer satisfaction perspective, there has to be a right focus in each software release to match the customer need. Finding the right focus requires, that there are sufficient business and technical understanding about the customer needs in place when the release or feature scope is be-ing defined.
In the current working practice at NSN, the Use Case and requirement def-inition for a new feature is typically done mainly by a feature expert. The feature expert carries out the feature requirement specification work by consulting other relevant experts about relating business and technical as-pects. Regardless of arranged work meetings during the requirement defi-nition process and finally reviewing the ready work product, in this work-ing method it is possible that all different viewpoints and interworkwork-ing is-sues are not identified. Even the feature scope may partially miss the cus-tomer demand, if the scope is not correctly understood. Later, additional specification work is needed to cover the missed Use Cases and require-ments.
It can be argued that the main reason for this is not lack of competence, but instead it is more about lack of communication. One person, despite how experienced, cannot be an expert in every aspect from the feature business value analysis to delivery. Especially the product environment with plenty of interworking features and functionalities increase the com-plexity level even further. The overall required experience and compe-tence, however, reside in the organization, but it is distributed to several organizational areas and experienced individuals. Therefore, more cross-functional team effort and communication are needed for feature scoping.
Equally, team effort brings benefits for clarifying and choosing the right Use Cases for a software release from business and technical viewpoints.
If the real customer needs and business requirements are not clearly un-derstood, it may have an impact on testability of the new functionality as well. In the worst case, it may happen that during testing the emphasis is in verifying that the implemented software is just according to what has been defined in the earlier system specification and implementation phas-es, while some of the actual customer requirements may be neglected. On the other hand, if the feature scoping and Use Case selection has been done successfully to match the customer need, it is possible to define an optimal set of acceptance test cases, which are used to ensure that the cus-tomer need is fulfilled.
A successful Feature scoping and Use Case selection, which matches to the customer real need, makes possible to divide the features into smaller entities. For example, instead of specifying a full-blown system-level fea-ture, which requires a year to implement, it may be better solution from the customer viewpoint to have a trial solution available for a subset of feature functionalities within a couple of months.
3.2.3 Increased competence development and information sharing
As mentioned earlier, a huge amount of competence resides in the organi-zation, but full benefit of competence of the experienced individuals may not be cashed out in the current way of working. On the other hand, addi-tional team work in the requirement definition phase would enable to share the knowledge between all related parties right from the beginning, to create a common understanding on the feature under development.
When the new feature is handled from different angles from business as-pects to verification, wider understanding of the problem area and re-quirements is gained. This helps to ensure that the most important Use Cases and requirements will be successfully managed through the product creation process for the release.
When the experts from different areas are collected into virtual groups to work with the new feature or functionality, everyone can support the group by bringing in his or her own competence. This way, the virtual group, which may also be called as a feature team, should be able to deliv-er high-value results much bettdeliv-er than an individual can do alone.
In the traditional product creation process, the shift between the different phases is very much dependent on produced documentation, for example, requirement specification documents. In additional, formal training, events are organized for competence sharing to the next product creation process phases after the system specification has been completed. Even though these events naturally, to some extent, are increasing the overall under-standing about the release scope and content, they do not yet give all the necessary information for the following phases to start their work effi-ciently. When the following phases are actually starting their work for the release, additional clarification sessions and planning meetings are needed about the new feature or functionality. The need for such additional ses-sions can be reduced by forming feature teams at the beginning. This al-lows participants to learn what the feature or new functionality is all about, with a possibility to add their own contribution to make the Use Cases and requirements more meaningful to perform the tasks, that are needed in the other phases of product creation too.
The overall teamwork benefits in innovative projects have been empirical-ly studied, for example, by Hoegl and Gemuenden (2001). It has been shown that teamwork positively impacts into project success by increased quality, as well as by increased efficiency of project schedule and budget (Hoegl and Gemuenden, 2001, p. 439).
The six teamwork quality construct factors are (Hoegl and Gemuenden, 2001, p. 437 - 438) are:
Communication: Information sharing and information flow within and between the teams is a direct prerequisite of project success.
Coordination: Team is able to agree on a common target and tasks, and divides the work into smaller subtasks. Team members are able to carry out the subtasks independently and efficiently, with-out overlap between the tasks of other team members.
Balance of member contributions: Contributions to the team tasks is balanced based on the expertise and experience of each individ-ual team member. Everyone is able to bring in the relevant knowhow into the team work.
Mutual support: Team members are able to assist each other, and further develop ideas towards the common goal.
Effort: The required effort to carry out the tasks can, and should be, fairly shared within the team to share the workload.
Cohesion: When the team members feel that they belong to the team with a common goal, it maintains the motivation on the team tasks.
Therefore, in addition that increase of teamwork is expected to bring in-creased competence development and information sharing, it also contrib-utes to the software quality and project efficiency overall.