How processes in organizations may influence productivity?


How processes in organizations may influence productivity?


Agile, waterfall, Kanban, documentation, specification, analysis, user stories, use cases, test cases, test coverage, and hundreds of others… What do they have in common? They all can be a part of software development… or not. 

This time let’s talk about how processes in organizations may influence productivity. As usual, it all depends.


Company ABC needs to develop a new, but seasonal product (it can be a part of a promotion or a specific version for a concrete scenario). The company starts with defining what the client expects, trying to provide feedback to analysts, they will produce user stories, and so on. 

The below diagram shows the routine steps, of how ABC develops products.



ABC does not see a need for change – it has worked pretty well, people are familiar with processes, and no one complained. On top of organization processes, they have also processes related to tests – 80% of coverage is the minimum that code needs to achieve (and not only Unit Tests but also Module Tests/System Component Tests). If rules are broken, then code can’t be pushed or a bug is raised to increase the coverage (if somehow such change has been committed to the repository). Everything works well, so the company decides to also go with these rules.

Finally, products start to be developed. Processes are in place, so the next persons receive feedback from previous stages (sometimes in parallel to make organization processes more “agile”) and the product is slowly created. After the specification phase, developers start their work on the product. Everything is a good shape, so there are no big doubts about how to code it. Developers start to complain that this product does not need so much test coverage, but rules are the rules – they are spending weeks to reach coverage and finally push all changes.

The product reached the test phases, which went smoothly, testers checked the specification, acceptance criteria, and software behavior – everything matches, so the product is ready to be delivered.

It took 1 year. The season ended, the customer did not pay, and the product went to the trash.


Every process has its implications for productivity, quality of software, or maintenance. There is no golden rule like 80% test coverage – is it a seasonal application, that needs to be delivered to a limited number of people and needs high-quality software? It would be best if it has, but it all depends. Software development needs compromises, adaptations, or just evolution.

What processes are needed for your company, how to adapt to incoming, customer expectations, and how to successfully develop a product – we, at RSC, can help you with this.