There are many reasons why you want to move your organisation towards Agility - Faster time to market, higher Quality, happy employees - the list goes on and on. It is supposed to be the promised land for employees and employers alike. Soon after familiarising yourself with the values, principles and processes you probably come to the conclusion that, while all of this sounds really good, but you don't yet know how to actually make it work. Seeing as the information readily available to you might appear very vague, without a clear connection to your unique situation, and there is no precise map of how to navigate your way, the whole process will most likely seem daunting. To give you a bit of confidence and courage to adapt the basic principles to your specific needs, to encourage to take that step, we'll explain how we made it work for our company, VSF Experts, all those years ago.
How do you do quality?
One of the questions we are asked quite frequently is "How do you do quality?" or "Do you really have no tester?". The answer depends on your specific project and team as it so often does, but let us share an example of how we solved the Quality Assurance in one of our clients legacy systems. We were asked to ramp up development for an application, let's call it "Legacy". This roughly 15-years-old application was given to us, undeveloped for over 5 years apart from bugfixing, barely tested and using a lot of legacy frameworks. Of course, time was of the essence and results were needed quickly. Sounds familiar? Then these next few lines might be for you and should give you an idea of how you can use Agility for higher Quality.
A little bit of background information: In the past our software development approach was to deal with work package assignments and tasks for individual developers. Based on requirements a tester or in non-critical cases Requirement Engineers would formulate test scenarios which would be used for Unit Tests, Integration Tests and some Automated Tests. To cover the entire project "Legacy" quickly, start immediately and cover all angles we decided to ramp up an agile, team focused and learning based approach. After all, agile teams are supposed to self-organize and take responsibility for their work in which they take pride - therefore quality should automatically increase.
First, you should know about our agile teams: They consist of several software developers and a tester, thinking in classic roles. The ratio is generally between 1:3 to 1:5 (Tester : Developer). When reading about Agile teams and roles, you often only read about "Developers", "Product Owners" and "Scrum Masters" leading to the assumption that you do not need a "Tester". Reading this you probably heard the same idea before and ask yourself - "Can this really work?" In theory, yes! With high functioning teams that know the strengths and weaknesses of each team member and are well versed in the Agile way of working. For us, transforming to this new way of working, it didn't initially work so well and the general agreement in the development team and on the periphery was that a dedicated tester just sees more and is trained to find those things a developer doesn't. During this phase, we learned the hard way that the term "Developer" doesn't solely describe a "Software Developer" in the classic sense. In an agile setup, every "Developer" is able to perform in whatever role you need in your team to get the job done - combining the skills of a Tester, an infrastructure specialist and a frontend developer in one, for example.
The VSF Approach
Now, how does one get a full set of these Developers? The way we approached this topic was another important discipline in the agile development world: knowledge sharing. We worked on transforming the classic functional tester role into a Quality Assurance Lead (QA Lead) role. The goal of this role is to share knowledge of Quality, the execution of tests, how to write meaningful tests and how to find those tricky corner cases in the whole team while making sure that Quality is steadily increasing. This has several benefits:
- QA Lead is strengthened because they are in a leading position which highlights the status of quality insurance
- QA Leads can delegate work and are less often the last guys to leave the work place
- QA Leads have more time to think about good test cases and are not rushed because they live in a world where they need to test deliverables from 5 developers alone
- QA Leads help the team share knowledge because test scenarios provide further insight
You can probably ascertain that switching the development approach to team based, agile development methodologies doesn't immediately result in a massive increase of quality. However, adapting the transformation by following another principle made the change definitely viable. (Adapting general agile principles to our company's processes has enabled us to lay the groundwork for steady, sustainable growth and imrpovements) By now our Quality has reached a point where frequently potentially shippable product increments are delivered at the end of each sprint - by teams who have the help of a specialist who strengthens the team as a whole.
If you've enjoyed our article, look to the right to find a selection of related content and services.