Imagine a leaf flowing down a river. It keeps turning, sometimes picking up speed, sometimes slowing down, sometimes jumping through little ripples, sometimes it hits a rock and starts drifting backwards till it is picked up by the stream again. But sometimes the leaf gets stuck in a pile of rocks and sinks.
Software development is very similar. It also goes through various phases towards a certain direction, moving through a pipeline, working through challenges and trying to make the deadline at the end of the river. Unfortunately simple waterfall does not fit well for most software projects. There are too many rocks hidden under water. Nobody can predict and prepare for everything. The plans might end up obsolete before getting started.
Agile was invented to work with the unpredictable. To deliver value. We accept that we will never know about all of the rocks before jumping in but we are prepared to deal with whatever comes. In fact we welcome the rocks because we know that each stumble is an opportunity to learn and find the right outcome. If we are lucky we hit on a rock that nudges us into a branch that is better than the initial direction. Instead of fighting the stream we are able to recognize the opportunities and use them to our advantage.
In order for agile to work the team has to be unified, everyone has to jump on the same leaf. Focus on the same goal, solve problems together and be responsible for everything, together.
If so, does it make sense to split quality assurance from the team? It would be like another leaf trying to nudge you to stay on course. Another ripple, another rock thrown by design. The team will still find it’s way, it might even learn something in the process, however a lot of wasted energy will be spent by navigating around each other.
Instead QA should jump on the development leaf. Work with the same goals in mind, integrate testing in the development process, become part of the team. Most of the time a shift in mindset for the developers can make them the best quality enforcers.
Developers write tests and test things themselves whenever building something for fun, for themselves. It has spawned some of the most amazing projects like Node.js, Docker or Jupyter Notebook. How come as soon as the same thing happens in a business environment the developers need their hands held?
Is it because the requirements are really that much more difficult? More unclear, yes. More difficult, I don’t think so. For most developers their day job is the simple, boring way to make some money.
So is it because developers are bored and are not really invested in the project? If you are not invested in something the quality is not going to be great. But is this the core problem? Surely not all developers are bored.
How come that agile companies with professional developers and QA teams somehow end up with missed requirements and late delivery?
Many people believe that developers are blind to their own faults, unable to find their own bugs and might overlook something important. It’s true to some degree, there is bias.
But does it warrant introducing a whole waterfall phase for QA? No, there are agile ways to solve this.
The team can work in pairs, rotating with other team members every day or week. Whenever something is developed there are 2 people that have thought about it and reviewed it. Pair programming takes a lot of practice but has many benefits that go beyond quality. The team shares knowledge about the project and the features, there is no superhero developer that can’t be replaced if needed. There is also no need for code reviews, the code has already been reviewed by both of the developers that took turns writing it.
Pair programming is a nice start. The next thing is to develop with test driven development principles. Code should be written starting with tests and continuously tested throughout development process, not just when it is delivered. This way it is simpler to maintain. Once you have tests for everything code is easily testable. It becomes harder to introduce bugs with upgrades or new features.
Most importantly, the team needs to take the responsibility for the quality of the project. It is a mindset that is missing in many teams, partially because of misinterpreted roles. Some developers get used to just dumping untested code to QA. Because that is QAs job. In a way having a separate QA team promotes careless attitude towards quality. Instead developers should feel like they own the project, their self image and career development should be tied with the success of the project.
Another common argument is that without a QA developers would spend too much time testing and it would drop their productivity. I don’t agree.
Think about the amount of time that goes into bug fixing, communicating with QA and repeated work. Writing tests and continuously testing during development ensures that bugs are found and fixed quicker. In a traditional development to QA phase, the developer has already moved to another task, his thoughts are already elsewhere. It takes time to get back in the mindset and workspace. A lot of this double work is mostly eliminated.
In addition, QA reports items that are out of scope, bugs that are set to be fixed in a later stage, or are irrelevant to the end product. It is almost impossible to filter such issues if QA is not part of the development team. It is a waste of time both for QA and developers to go through such issues.
There is a saying — beta testing is a symptom of poor communication with customers. In my experience this is true. Customers should be just as involved in the development process as the developers are. That is the only way to ensure that the end product will match the expectations.
In reality, many agile teams do not practice this, and instead rely on QA to steer the quality. Quality is not just about adhering to specifications.
It is much more efficient to show a demo of the feature as soon as possible. Let the customer play with it, and urge to provide feedback. Until the demo the developer should only ensure that the feature is presentable.
It is fine if the feature is not polished, it is fine if it does not look perfect. The real value is in the feedback that the customer can give you by getting hands on experience early.
It is entirely possible that the feature will need significant changes, or that it is fine as presented. Any thorough QA before this would have been useless.
I have spoken with many developers and test engineers in companies that have adopted agile. Almost none of them truly believe in agile, almost none of them really understand the values, almost none of them like it.
It is no surprise that the leaf keeps hitting the rocks, the people steering it have no direction, no understanding of their roles and responsibilities. They are just going with the flow. These teams are still working in waterfall with some agile titles and ceremonies sprinkled in.
Such an environment is bound to confuse people. People resent the meetings, resent pair programming, resent needing to test things and eventually it leads to lack of quality. In such an environment both development and QA teams keep throwing rocks in front of themselves, hitting into each other and missing the opportunities.
And the worst part is that these teams believe they are agile. And therefore agile is actually the cause of the problem.
