Agile Frameworks and the lack of test expertise Martin Jansson
I am a tester and these are my perceptions and reflections on agile concepts.
There are several agile frameworks available for implementation to guide the agile transformation. I have not experienced many frameworks myself, but I have experienced several implementations in an agile organisations. One core theme in the agile movement is that everyone should test and no single person is responsible for quality. This is great! Still, there is a need for guidance and strategy within testing and quality.
If we perceive these frameworks as something to implement and follow blindly, then I think it is doomed to fail. If you instead see them as building blocks, where you take them, tweak them and put them together, you will be less likely to fail. Because each organisation has its own structure, culture, products and people that together create a unique context.
In each agile transformation you also see agile coaches. If these coaches see the framework as a set of rules, instead of a set of guides, then you will probably not be able to tweak how you work with testing, thus being forced to follow the limitations of the agile framework. I have never seen or heard of someone with the capacity to fully know all crafts (software development, hardware development, testing, support, operations, management, and so on) within product development. In that case, how can you coach a whole organisation on all its crafts? I rather see the need for expertise within each of these crafts to guide the agile implementation. But this should not be a problem. Continuous improvement is a natural philosophy of agile, meaning that evolving the implementation of agile and the framework should also be done?
When I study an agile framework such as SAFe, I find lots of good material and good ideas. On the other hand, I do not find much material on testing, culture of testing, test approaches or test strategy. In the bibliography list [see reference 1], I can find one book from Lisa Crispin and Janet Gregory, but that is it. I do not count TDD or ATDD as within the testing craft, rather a development craft. I think SAFe and probably other agile frameworks would benefit from some enrichment of test expertise. I also fail to see any known testers in the contributor list.
What I believe is a common theme in agile is that testing has no special seat at the table of leadership since everyone is expected to work with it. I believe this is wrong. That is why I want to contribute to the subject with my own thoughts, ideas, reflections and experiences on the subject in order to change, add and possibly remove some of their parts. I know that many great testers are struggling with this as well. So instead of saying that the frameworks are crap, I want to tweak them to become better to help in the agile transformation.
References
-
Bibliography of scaled agile framework – http://www.scaledagileframework.com/contributors/
Thanks for a great post!
I find it ironical trying to use a fixed framework to implement a agile way of working. In fact I see it as severe misunderstanding of agile core values – to interact, evaluate and improve continously.
My experience is that all light-weight development models (and frameworks) requires additions and adaptations in order to fit the organisation.
QA, just like other competence areas, often needs exactly what you wrote “…guidance and strategy…”, QA coaching!
My interpretation of “knowing all crafts” is that they are needed from the team rather that each individual. For instance, a lot of the team work can be done in pairs to avoid dependencies on individuals.
I’ve gladly used inspiration from SAFe as well as Less, but I would not recommend using them literally.
No special seat at the table for testing is a straight way to failure.
It is true that more people than just testers should test (although not necessarily everyone). But, each project needs a special seat for someone – I call that person a tester – whose goals are related to the quality of the product, not its features nor delivery time.
Else, we could find ourselves in super-optimistic teams which have all the cool features done on time… Except that these features hardly work at all.
@Christer, thanks! I agree it is a bit strange. Adding that you can get certified in the framework hints that it should be static in its implementation and avoid being changed. On the other hand, I think these frameworks are excellent as a way to take and pick from, like a smörgårdsbord.
@Antoni, good points.
Thanks for starting this thought. Yes, Agile Scrum and some of the other process/frameworks focus a lot on the implementation aspect vs the values and principles of Agile. They use new words to justify paying for the 2 day certifications but underneath the marketing sheath is the fact that craftsmanship in each of the disciplines such as requirements, coding, and testing is more valuable than the practices that we all must follow. Do developers suddenly come back from Agile Scrum class and think hey I am accountable for my own code and therefore I will do all the testing? We all forgot that a bad requirements writer, a bad coder, and a bad tester does not suddenly become a good craftsman of their trade after taking a Scrum class.
“Couldn’t agree more! After all, a framework that furthers continuous improvement should not be looked at as rigid, with no scope for tweaks & refinement.
Also, I resonate with the concept of having the respective experts as coaches for the different aspects of product development.”
@Martin Jansson _ Nice and good points that you have mentioned regarding Agile and testing. As you said it might be wrong and need a change in the processes