Bloggo back to the blog
Invisible disorder when everyone calls it Agile-->
Every new technology or methodology which is well distributed always goes through same phases. At the beginning it is specified, after that it gets maximum attention and is used by almost everyone who heard about how good it is, and after that the level of popularity is being decreased to the level which actually have sense. Often it happens that in the second phase – let’s call it popularity explosion, lots of organizations use it, but are not sure for 100% how to use it, or even why they use it, in general they heard it is very good and everyone uses it, but there is no explanation based on described experience is it really as good as they say.
In various software development lifecycles which are known for a longer period of time, and are now in the third phase – stable state – used because we know what it is for and what it gives us, mostly many products of particular phases of those development lifecycles are paper documents. Those lifecycles, let’s call them classics ones, especially waterfall lifecycle model which is classic among classics, but also V model with quality, etc. have specific products in each phase that is a part of the lifecycle. For instance in waterfall model, every phase gives products which are input to the next phase, so we cannot start following phase when the previous one is not finished, and the products of the phase are ready. As I mentioned many of those products are documents, after analysis, design etc. So this means much paper work and bureaucracy. Well that is true, but for sure that bureaucracy despite of horrible time and resources consumption, give a structured process in which we know where we are and what to do. Of course often we have to chase people for signatures, reviews and other process required action, but when it is done properly we have order.
From the other side we have Agile, in general not new, but for many organization still quite new. What Agile says that will give you if you use it? Non of that bureaucracy which wastes your time and make you to do more documentation than building actual product. Less money for resources because lots of work which is required in different lifecycles is not necessary in agile. Simplifying, the main rule is to build a very good team, and basing on team understanding, and communication with client easily build what we want to have without anything what is a ballast for the project. Sounds nice, isn’t it ?
Well, as we know, the truth is not far away from it, Agile actually is really good development pack of methodologies, but it have few rules that following is a must. Unfortunately it often happens, that when an organization starts to use agile, and they know that, that in this methodology they don’t have to create documentation it is enough for them to be interested in it. People hear that we can have quality without paper work and follow those rumors, sometimes not doing the analyze at reasonable level. And in these cases new methodologies are being created. Those are AGILE-BUT, It says we are working in agile but this, or of course we are working in agile, but that. And in all those organizations in projects which are following agile-but methodology real mess is sneaking.
Developers are satisfied that non paper work is required, they do some agile practices, of course, but not as specified, and feels good in it, even don’t see in what kind of disorder the project is. After each day going and working in that lack of any process Agile-but, suddenly it occurs that we are not doing what we had to, and we are very out of track with timelines. Moreover system build is extremely full of bugs. How did it happen ? We were using Agile methodology, so what is the reason that we are not in the straight path to success ?
Well answer is clear and already said, when in a project we don’t follow any process and do a self-justify that process is not required because we are working in very well communicated and build team, sometimes even don’t want to have any guys from quality or testing, and count them as not required, story is always the same. The truth is that Agile is very structured. It has its phases which must be followed even in 100% as described. If we do a daily stand up, let’s do it without chairs, If sprint must deliver something that is working, so it must deliver something what is working, etc. as described in any Agile methodology that is specified in details.
Agile for many organizations is too new to know that its rules must be followed. It is remade to a mess when everyone talks to everyone and all think that do Agile, because no documentation is created. When a testing team wants to do an advise and signalize that not everything is so clear as story tells, sometimes gets the response that it is agile, and we don’t need specified process. This is a difficult task for testing. It was always known matter that communication on sides development- testing was difficult, but here are really new challenges. New difficult thing is that quality assurance specialist must inform others who think that everything is OK because they work in some kind of Agile, that they are not quite right. It is difficult because people doesn’t know how agile methodologies are structured, and tries not to see that and work in a way like before any lifecycle methodologies were defined. In my opinion a testing guy, which has The Quality as a friend, should really keep an eye on the process in every Agile project. This is task slightly new, because the role is moved more in a quality area, but for sure for me testing and quality are very the same family. It is clearly seen that testing and quality have a lot of space to show how important they are in place where at the beginning it was said that no testers are needed. The testing mind, which knows the most important here: that the process is required, or even simple: where bugs might occur, is the real cure for that ill situation of Agile-But.
Despite of normal testing thinking, how to break something, which is of course still very crucial, we need also some more actions and thoughts that always were in testing minds and hearts, but maybe in a delicate nap, how to promote and defend quality in project lifecycle.
Paweł Sokołowski is a Senior Test Designer at Soflab Technology has been working in software testing area since 2007. He was participating in projects with various methodologies, from waterfall to agile, mostly for huge international company, but not only. Some of roles, which he worked in were tester, quality assurance specialist or test coordinator He is interested software engineering and quality standards, is ISTQB Test Analyst and Test Manager certified. He is 30, lives in Warsaw, for free time loves to photograph.