IT Team simulation

Problem definition

At the time I am working in an IT team of a start-up insuretech company that offers life insurance online and provides its clients with the application which makes a score of client’s physical activities - the more the client does sports the bigger cashback from the price of the insurance contract he can get. As that company is software based, the IT team plays a big role, but unfortunately it did not have a proper process of solving business requirements. The following sections will describe the new process of a team (implemented recently) and the simulation is supposed to help to identify the bottlenecks of the process, meanwhile, the results from the simulation are supposed to help to come with the solution about the right distribution of the resources in order to boost the effectiveness of the team.

Method

Simprocess is a relevant tool for such kind of problem mainly because the aforementioned situation can be described as discrete. There is a clear entity (business requirement) which goes through a series of operations (development process), it includes different type of events (delays, “fight” for the resources etc.) which creates queues. Simprocess and the process modeling also allows the author of this model to include decision points and define time delays by a probability distribution.

Model

In order to create a Simprocess model, the author of this works has to describe the process of the given Development team, resources available, historical information available, and limitations of the model that the author included.

Requirements gathering process

The main operation in this case is the procedure for registering requests. In this case, a requirement is understood as any formally described condition that the created solution must satisfy.

In particular, the requirements are:

• New functionalities or change requests
• Errors identified during internal or external testing on already running solution

Requirements can come from various sources, for example:

• Company management
• Customers (through the Customer care line)
• Tester as part of a project team

All the requirements are placed into Backlog in Jira software tool and are monitored.

Resources in the simulation

Product owner

• Formation of plans
• Monitoring the implementation of plans
• Organizational work (including with the sources of the requirements)
• Conceptual architecture of the solution
• Part of the analytical work

The product owner is the first contact to deal with business requirements. He is in close contact with analyst when it is decided that a task is ready for backlog (business case or cost-benefit analysis of a new functionality is done; in case of defect management – bugs are either accepted or specified for the Debugging processes).

1x Analyst

• Development of technical specification for functionality
• Development of test plans
• Conceptual testing of functionality
• Development of user documentation

The analyst is available onlz 2 days a week

1x Techlead

• Conceptual consultancy
• Code review control
• Production release

Techlead is able to solve Code reviews and Releases only 2 days a week

9x Developers

• Development of functionality
• Correction of errors in the code
• Conducting initial testing of the code
• Participates in complex code testing

All developers are full-time employees with the same level of seniority

1x Tester

• Functionality testing in all of the environments
• Writing UAT tests

Development process for the model

For the development process the team has chosen the Kanban approch under the condition that FIFO principle will be used (first task in – first task out). The following process describes all the phases from the moment the task was passed to the team to its release.

The team’s Kanban board includes 8 phases each task goes through:

1. To develop

   After identifying the requirements to be developed within the framework of this version, a detailed development plan for this version is drawn up and added to Kanban Board. Then, according to the plan, the Developer, together with the Techlead (in terms of conceptual architectural solutions), based on the technical specification, prepares the work draft.

2. In progress

   After agreeing on the working draft, the Developer proceeds to its implementation. For sufficiently large requirements, the functionality) is implemented in several parts.

3. Code review

   After the development of one part, the code quality is checked by the Techlead. If deficiencies are revealed, the Developer eliminates them.

4. Acceptance

   If needed, the functionality demonstrated to the Business owner on the development environment already (rare cases).

5. Testing

   After the implementation of all parts of one requirement, the Developer demonstrates the developed functionality to the Tester who is testing for compliance with user needs. If inconsistencies with the needs of users are revealed, the changes are implemented and the functionality is immediately finalized (in case of minor comments that do not require changing of the business logic and the architectural model).In case of successful concept testing, the Developer proceeds to the implementation of the next requirement in accordance with the version work plan.

6. Stage release

   The functionalities that are tested on DEV are prepared for the stage release and waiting for the Techlead to prepare the release.

7. UAT

   The tester repeats the testing on Stage environment

8. Done

   All the tasks wich are ready for the PROD release are moved to the column Done and are waiting for the Techlead. After all the improvements planned in the version have been implemented, the the Techlead builds the versionand generates Release notes, in which:

• Version parameters are described (number, release date etc.)
• Requirements implemented in the version are listed (new functionality, fixed errors)
• Contains version deployment information (steps)

Also, after agreeing on the new functionality, the Analyst updates the user documentation for the solution.

Data used and model limitations

1. The model presumes that the reaction of the product owner is that agile that no irrelevant tasks appear at the Kanban board and the cycle of the team is fast enough, that this task is never moved to the old backlog during the development process
2. The model presumes that the analysis is done with the FIFO principle
3. The model presumes that the seniority of all of the developers (resources) is exactly the same (while in reality even if all the developer are similarly senior it does not mean that they are able of exactly the same performance on all type of tasks,or have the same performance everyday)
4. This model excludes the impact of unpredictable factors (like new legal requirements, that can get higher priority and be handed over directly to the dev team and implemented as a hotfix)
5. This model excludes the phase of Acceptance because of this phase is often jumped over and even though it in reality this fact often leads to the big list of bugs reported later, this is not the objective of this exact model.
6. This model does not separate the process Testing and UAT testing, because UAT is considered to be insignificant for the purpose of this model
7. Bug are supposed to be less priority and always to be served after Change requests (in reality some of the bugs are that huge, that they are served earlier
8. There were not sufficient statistics about the code review quality, but it was estimated like that by the Techlead of the team. There were not enough statistics about the testing failure, estimation by the tester was used for the purpose of this simulation