In one of my previous blog posts, I propose to gather facts and figures on the current testing status quo. For me, that is the basis to make informed decisions on how to proceed in software development. Do we need to spend more time on testing? Do we do too little / enough / too much?
Without good data we don’t know. However – does this really match with agile software development practices? Should management not trust the dev teams to prioritize according to the most important next step?
My answer to the latter two questions is simple: Yes – and YES!!
In smaller companies, gathering many facts may not be important, as management may even be part of scrum teams or closely involved in the development process. However in larger companies and speaking for most scaled agile models such as SAFe, Spotify or others, the usual setup contains:
- A number of Scrum Teams (Product Owner, Scrum Master, Devs, maybe testers)
- Product Management / Chief Product Owner
- Senior Management
Senior Management is responsible for software being developed so that there is a business and a business model in place to earn money. Eventually that is the goal of most enterprises. 😉
Product Management / Chief Product Owners are responsible that the right features for that business model are selected, prioritized and developed. They closely collaborate with senior management and product owners.
Scrum Teams are responsible that the highest value is produced, regardless what has been selected for development. The highest value can be a new feature, refactoring, reducing technical debt, writing automated tests or other.
So what happens usually is that Product Management wants quick new feature developement so the company can earn more money. However, while scrum teams agree to rapid software development, they prefer to develop software sustainably. Sustainable software development again requires automated tests, regular refactoring and minimizing technical debt from the start. This clash needs to be managed on a day to day basis between the involved parties.
In most software development projects, there already is plenty of technical debt that hampers quick software development. At some point scrum teams will need to raise a red flag and invest more time in refactoring and writing automated tests. However in the short run this results in decreased feature development speed and needs to be explained to product management and senior management.
Typically, the more senior management have little technical expertise and certainly less than developers. So the status quo needs to be transported to non technical experts, who are mainly looking at financial numbers. And what better way could there be to make a status transparent to „numbers“ people, than by gathering facts and figures?!
By gathering the right facts and figures, senior management can be convinced to invest money in
- more developers
- time for refactoring and testing
- testers and test teams
- License costs for tools such as sonarqube
And by this the scrum teams can work on what they think is most important!