It seems that Agile is in a state of momentum (though not exactly new) in one or another implementation (Scrum for example), which is indeed a good thing. But not everywhere is necessarily appropriate (industries that require a very large infrastructure), not everywhere is easy to assimilate it (large companies with a lot of distributed teams), and not everywhere is ready for it (a matter of conservatism, for example). Sometimes there is a mix of the above reasons.
Even in places that are ready for it and accept it, it is not always applied "as it should."
For example, in the Scrum guide in, you will find the sentence: "Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team." In practice, we see that many organizations working in agile still leave the testing body independent and hierarchical, even though the test engineers themselves are in the teams. By the way, in Google, at least according to the book "How Google test software" since 2011, we see that the testing organization is working in the above method. It makes sense because it gives independence to the testers and the administrative body can renew and ensure that the teamwork is done in the best possible way.
In other words, the organizations took the principles of agile and Scram (for example, or any method) and built what they thought would be appropriate for the company and its organizational culture, the industry, and the nature of the work. But in this case, a considerable part of the spirit of the agile is still present.
The question is what happens in other organizations that are not prepared to accept the spirit of agile?
I think that here too there are things that can be done. I think that ultimately everyone understands that the times are changing, and if we convince the people in the company that we take things with caution and with calculation, it will show that we and the organization are innovating, and we can say that we have innovated and it will really bring value to the organization.
So what agile characteristics can be brought to the organization of Waterfall?
Continuous Integration
Unit testing and automation. UT is a must in agile - see an article by Gil Zilberfeld, and I also think automation. Without declaring an end-to-end automation intent, let's talk about Continuous Integration that contains these elements.
In general, this means that besides the encoding of the feature and the preparation of UT, the development process is automatic. By pressing a button, the programmer checks its new code. If the test passes, there is an option for a local build where they will run automatic smoke tests, then transfer to the repository of all the product code, build a full version, and run a little more extensive test. Each failure point stops the process and returns to the programmer's responsibility. The whole process, although complex, should be fast, and done several times a day. The test engineer receives the product at the same point he had previously received, perhaps faster and more stable.
Benefits:
The process is fast.
Quick feedback on Problems.
Fewer frustrations of testing personnel and developers.
Saves testing time.
Especially when there is a lot of new code all the time, doing the process several times a day will reveal problems with small updates, so it is easy to find the problems quickly.
What should be considered?
In a large system, it will be wise to verify that there are not too many dependencies between parts of the product that will be difficult for CI.
The installation of the product should be automatic.
The goals of the CI are clear.
Defining responsibility between the test engineers, integration personnel if there are and programmers.
Source Control and CI infrastructure.
Clear results for automation.
Exploration Testing
I've talked about it quite a bit and here is not the place to mention it again. It is worth remembering that under the appropriate conditions, this method saves time, especially in tests writing.
Software tester that is part of the development team
Not Scram, but something relatively easy to realize and bring about very good results:
The test engineer will learn about the product,
It will bring quality at an early stage - by checking at an early point, telling developers about scenarios that the test engineer thinks about even before encoding,
It will help developers test parts of the product early,
The test engineer will be more professional - will know what development does, may learn to code,
It will save time later on testing the system - will teach the rest of the testers about the technical and product parts, there will be parts that will already be tested and quality, etc. The transition to development - testing of the product will be faster.
Requires training of the test engineer and the developers regarding the idea of working together. Also requires monitoring, but worth the while.
Multidisciplinary teams
It is early to talk about agile, but it is possible at critical points during the product life that all the testers, programmers, product managers, UX, DBA etc. sit together. It saves time, it's effective, and it's skillful.
In one such case, I know it has spared (and I'm careful) 15% of the 200-day test predictions. But it also spared the introduction of incorrect bug reports, resulting in a situation where bugs are handled immediately.
At what points can this be done? Such as the beginning of tests or the end of development.
Ready for a little more?
How about a water-scrum-fall model?
Yes, there is such a life and you can read about it here, for example: https://reqtest.com/agile-blog/agile-waterfall-hybrid-methodology-2
Ready for Agile But are you a big organization with a tight schedule?
One option is the SAFe. It's agile on a large scale. I'm not an expert on the subject, but it works for example at Nice Actimize.
As in the previous case, there are agile characteristics, such as multidisciplinary teams, sprints, etc. But there are other layers that determine some of the things like the schedule.
In conclusion:
As you have seen, it is not necessary to adopt Agile as a single unit when it is unsuitable for the organization for various reasons. But yes, I would say that it is almost a necessity to adopt Agile characteristics. It is possible to adopt some part or the other from what I have recommended, slowly and in a monitored manner, to correct a little and continue until it suits the organization completely.
Comments
Post a Comment