From Specification to Implementation (III)

Continuing with related post (From Specification to Implementation) I will described the last processes implementation in a public organization supported with RedMine.

The final photo (today, forward work will be done) consist on:

A set of processes:

• Project Planning (CMMI)
• Project Monitoring and Control (CMMI)
• Requirements Development (CMMI)
• Requirements Management (CMMI)
• Release Management (ISO 20.000)
• Defect Management 

A group of roles (RedMine roles):

• Sponsor
• Expert User
• Functional Director
• Project Manager
• Project Team 
• System Manager
• System Team

And several management elements (RedMine trackers):

• New Initiative
• Goal
• Project Plan
• Requirement
• Requirement Change
• Sprint
• Release
• Version
• Defect
• Request for Change (development)

With these three group of elements the new methodology is ready to be used. The relationship between then is described in the following picture:

Further related documentation have been generated: templates, reports, user manual, change management... and everything is supported with wiki and document functionality.

From Specification to Implementation (II)

Starting from previous post, several approach could be done to get a process implementation in any organization.

From our experience, the process implementation consist on the following main steps:

• Initial Situation: this set of task consists of several techniques and work focus on identifying organization needs, how the organization is working, strengths and vulnerabilities.
• This work generates a document that identifies such things and propose a improvement process divided in three scenarios.
• Process Implantation: once the goal of the first implantation has been defined, the work will be lead by defining working group for each process, in order to identify in detail how tasks activities are being delived nowadays, and how could be unified, attended and systematized to reach users needs and organization goals

Process Implantation finish when the organization has several process implanted with:

• Entries
• Outputs
• Tasks
• Roles
• Reports
• Metrics
• A tool or a set of tools that support it
• Training sessions - Change management
• Initial support

From my point of view the supporting tool is the key to organize any process, and it will allow:

• Monitorization
• Measurement
• Regulation
• Support
• Collaboration

Any ticketing tool will help to fit your needs, we have used RedMine as project management tool and we have good experiences with it.

Testing and Development: sustainable economic model

Test processes increase total cost of projects

This sentence could be the started point for a long discussion about truth and false that have to be analysed in detail.

• Development teams should test every version, if we have a independent testing team for version verification, then we have increased total cost.

This affirmation is true and there is no much to add, the key concept that we have to realise is that this cost should be budgeted from the early beginning and also it should be in our project plan. Another point is that testing cost should be something less than 15% of development cost.

•  Where is the advantage of testing? Do they improve software? Which is ROI of every euro spent in testing?

There are specific economic models to show the value of testing, and how 1 Euro spent on testing will save several in maintenance, operation, codification... it depends on when you invest on testing, as early you start as much money you will save

• As there is a testing team, developers are lazy testing their own work
• ... 

The main goal in the last months in my job has been to define a sustainable economic model  that allow business to have the benefits of testing with a predictable cost.

The model is sustainable with the following concepts:

• For every software version we will know development cost and testing cost.
• For every delivery of the same version we will have two metrics, derived from testing:
• Number of corrections until the software has been deployed in test environment.
• % of requirements passed as ok after testing is finished
• Two indicators and two slas are associated to these metrics:
• Number of corrections have to be less than X (for example three)
• Fulfillment of requirements have to be greater than Y (for example 75%)

With this, it is possible starting a new version and the development team will estimated the cost (ie 100.000,00 €) and the testing team also (15% - 15.000,00 €). Then, when the first delivery arrives:

• If both indicator are better than expected by the sla --> total version cost will be 115.000,00 € and the first version is a good candidate to be  promoted in a production environment (it will depend, but could be)
• If any indicator is worse than expected --> a new release will be delivered, test cost will increase, but development team will be penalized --> (100.000,00 - 10.000) [Developement] + (15.000,00 + 5.000,00) [Testing] = 110.000 €

With this model, as many release are needed less development cost  and more testing cost, the total cost should be constant for final business.

From specification to implementation

Processes specification is a hard work that many times finish with a theoretical approach, high amounts of money spent and low or null use in the organization.

Main reasons for these situations are:

• Processes goals is aligned to organization goals but they are not supported by end users, main affected of the new way of work that implies a new methodology.
• Methodologies approach are so wide and nonspecific, they could not be implemented by default, but need a customization for each organization.

For me the reasons why a methodology does not fit in a organization is due to:

• People who has to work with it are not involve in processes specification.
• Processes definition is supported as documents, but not implemented in any tool.
• Managed elements defined by the methodology are not valuable, they only suppose more work, but not simplified work and reporting.

In order to avoid these situations and minimize methodology pitfalls I recommend you to start this work with the following partners:

• A short list of goals: few processes in a organization with a list of identifying problems and a set of metrics that evidence how to improve.
• A short list of users: process owner and end user process. They have to be able to define their requirements and validate your work.
• A corporate tool to implement, document and support the processes. This tool will be the base of any organization work.

From Classical to Flexible Testing

From Classical Testing to Flexible Testing

From a long time ago Quality Assurance Department were involve in several works: 

• methodology specification, 
• process definition, 
• process implementation, and 
• quality reviews. 

These functions are being enhanced and improved and different teams and responsibilities are being defined.

Testing is a new department in business with a separated responsibilities focus on product verification and validation, integrated in product specifications, product schedule and involve with product goals and success.

This new approximation implies a new paradigm which require new techniques and process focused on succeed.

Differences of a flexible approach. Project Success

In a context where project success is a matter of IT business head, quality is a way to guarantee project success, where all processes are focussed on quality, productivity and excellence. Quality is not an external matter in product generation, but is implicit in all activities and roles.

From this approach, testing could not be a set of process executions oriented to defect detection and request new deliveries, but focus is detect prevention, expecting that with only one delivery software will be accepted and promoted to implementation.

In order to reach this goals, we should:

• Publish our methodology and any automated tool that could simplified verification, in order to allow any developer team auto-evaluated every day and previous any delivery.
• Training service in verification and in any specific consideration that should be know by any part in development and system specification.
• Defect tracking system, in order to communicate development team and testing team.
• Flexibility model: what happens in case of a blocking defect? Should testing ask for a  new delivery? Answer is always yes, but the way we allow this new delivery should be different for certain situations.

Flexibility model

This model allow a conversation between testing office and development office in order to reduce number of deliveries, and makes all one group with one goal: project success.

If we have a delivery in which everything works but there is a dependency no satisfied we can:

• Ask for a new delivery (with all the cost associated with it)
• Allow several correction to each service (for example compilation service), which will be more cheaper and project schedule will be better.

Flexibility model defines for testing office: which services will be flexible, the amount of corrections that will be allowed and the maximum time that testing will wait for them.

With it project quality is not at risk, cost could be reduced and schedule enhanced, but all teams have a must that is project success.

Continual Improvent Process

The continual improvement process is almost the most important concept that every methodology must define, and that should be always implement in any organization.

If we take a look at most significant methodologies, we can see this process area definition:

• ITIIL V3
• CMMI - Dev - 1.3
• TMMI

Continual Improvement Processes aimed to be used not in an initial application of any of these methodologies, but in a later step, and this causes several miss-performance situations in organizations:

• Organizations that are making an effort in methodology improvement don't have a continuous improvement process included on their process map.
• After implementation of the methodology in the organization there are no metrics to determine if performance is increasing or not.
• Basic diagnostic is not determine: is the methodology in my organization being used?

To avoid those situations any implementation of any methodology must define a set of processes, with almost the following matters:

• A set of processes not in paper, but with a computer based solution that support then.
• A set of basic metrics that measure how are  being used processes.
• A set of performance indicators to determine if throughput is increasing or not.
• A set of reports that inform the methodology leader how everything is going on.
• the organization must know how to inform or propose improvement  to methodology.