The perception of software development performance truly varies according to management style; hence, performance assessment is, in fact, a question of perception. The performance assessment of a development team is closely linked to the management style and, more precisely, to the priorities it dictates; in software development as in any other activity.
Any manager would like to have an objective assessment of the performance of both his development team and his IT department as part of a software development project. The term “objective” is the key to the riddle here. Is there an objective method for assessing the performance of a developer, a development team or a software development company? Is there a key performance indicator in software development that really tells the truth?
In fact, one can hardly count the systems, methods, and nomenclatures that have been created since the beginning of the industrial era to evaluate performance in software development, as in any other field.
So many companies are wondering whether their software development team or that of their IT consulting firm is performing well. Surprisingly, there is an objective and universal method developed under the CMMI system (Capability Maturity Model Integration) to objectively assess the performance of a software development team.
This performance evaluation method, FFP (Full Functional Point), makes it possible to evaluate, constantly and independently of the technology, the effort required to generate a defined deliverable. This evaluation, associated with velocity, will enable the performance assessment of a software development team. However, in practice, this method is also subject to management style.
We will develop in details the notions of FFP and velocity in our next posts; in this post, we will explain the two main project management styles in software development and how they influence the performance assessment of a development team.
In short, it’s all a matter of management and metrics.
So, are you Agile or Waterfall?
What kind of Manager are you? Agile or Waterfall?
In other words, when it comes to the software development project that you launch; what’s more important? The Value or the Plan?
Considering the representation below of the two management styles, there is no right or wrong answer to this question!
The reality is that in large companies, some large-scale projects involve several departments and several stakeholders. In this case, there is no doubt that the plan is not only useful but necessary.
Typically, in a large-scale software development project such as “redesigning a critical back-office application”, all beneficiary and/or contributor departments present their queries and constraints. And they expect to see their requests filled and realized since all the requested functionalities, small or large, are considered necessary by each applicant. Hence, all required (and considered necessary) functions within the project will be integrated into the final plan.
A software development project is launched with the objective that it will have a positive impact on all parties involved. It will solicit the coordination of several departments and will mobilize many resources at different times. Its realization will require a collective effort of collaboration. Incidentally, the plan will have a mobilizing effect and will act as a coordination tool among the various stakeholders.
For all these reasons, it is essential to carry out the software development project in its entirety, despite the unforeseen events and their possible impact on costs and schedule. In the “Plan” management style, costs and time can be variable while the project’s completeness is immutable.
In “Plan” management, the team performance will be evaluated on the basis of achieving cost, time and schedule objectives, while the project scope (deliverability) is being fixed. Yes, costs and time are variable but how close to the initial estimates was the team able to deliver? That is the question. Of course, it will be argued that the initial estimate was false but this will be the subject of another post …
As for the evaluation of the project, it will be based on the impact of the application (its benefits) on the different departments involved, once the project has been completed.
In the case of a smaller project or within an SMB, it would be more prudent, considering the restrictions imposed in terms of resources and costs, to opt for Agile methodology management style and to consider as a priority the value brought by the project, the benefits for the company.
Typically, as part of an Agile development project, all the functionalities of the application to be developed will be evaluated in terms of value (benefit) provided to the company according to different hierarchies; for example, functionality viewed as critical, important, useful, desired, optional, etc.
Thus, the project to which a fixed budget envelope and a specific production schedule will be allocated will begin with the development of the functions deemed as critical and important in priority. The Agile project is driven by Value, not by Plan.
In “Value” management, the performance assessment of the development team will be based on the number of features/functionalities delivered in the time and budget allocated, that is fixed. The evaluation of the project will, therefore, be based on the benefits obtained (increased productivity, access to business intelligence, reduced costs, etc.) thanks to the functionalities delivered. As a reference, note that each type of management calls upon different project management tools.
For example, in the Microsoft environment, the Project Manager by Plan will rely on a tool such as Microsoft Project that emphasizes the remaining tasks to be performed while the Value Project Manager will use a tool such as TFS (Team Foundation Server), which focuses on the remaining hours to be accomplished.
The perception of a software development team’s performance is truly dependent on the management style of the Project Director, the Department Director or the Board; the fact is that management styles dictate different priorities, which guide performance assessment.
In the end, will you evaluate the costs and time required to deliver the project in its entirety, the impact of the final project once completed or the quality of the value (the benefits) provided to the company within the allocated time?
Perhaps the ideal would be to always be Agile locally (in execution) without ever losing sight of the Plan, regardless of the type of business or the scope of the software development project!
Have a good project,
Denis Paul & Michel