Tag Archives: agile

Agile is not the answer

Posted on by
7

I’m writing this again as a response to Andréas’ post (who wrote this as a response to mine).

As I’ve been looking at the ROI of testing the last few weeks I found out that the most used numbers are still based on the initial study of Boehm from 1979. He calculated the cost of change of a waterfall method and found out that ‘the earlier you fix the problem, the cheaper it is’. That idea is still the most relevant of all. If you look at the implementation of LEAN you get the same. Fix the issues when it occurs, instead of waiting till the end. It improves the lead time and reduces the costs.

But the numbers from Boehm are based on the waterfall method, as said. Now what is the cost of change for Agile? Of course you cannot really compare them both directly, but what I found out surprised me a little bit.

Both of them are based on studies, waterfall by Barry Boehm and STBC, and the Agile by STBC again. Why am I looking at these studies? Well people in QA always use Boehm to elaborate why they want to start testing as soon as possible and both of them are used in the IV&V method for the Public Sector in the US.

 

When you look at both you see a rising amount of cost after the requirements phase of the Waterfall method and after the test phase these costs just go sky high. When you look at agile there is a slight rise in costs after the coding phase in the Agile cycle, but when going into Production the costs will go sky high.

Why are the costs of Agile lower after the business case? Well, one reason is that with Agile documents are created as needed for the development process. So during the full Agile cycle there is not so much need in changing documentation, only the code when an error is found. But when the product is shipped for production, that documentation still has tob e delivered for the Management & Control team of the organization.

Note: This something that is often forgotten in Agile development teams not doing a good usage of the method. Speed is generated by producing as less as possible documentation, but it still has to be delivered at the end of the project. And it’s only human to ‘forget’ this!

But statements from Agile devotees like ‘collaboration between the various partners in the development process is what makes Agile better compared with Waterfall’ are bullshit. In Waterfall collaboration is also possible! That doesn’t have to be a difference. It’s only true that quite a lot of times this is not done in Waterfall. But maybe you have some ideas around this

But one thing is the same in Agile and Waterfall: issues found in Production are always very expensive to fix!

Quality of the cloud infrastructure using ‘agile’

Posted on by
1

It is important to know which quality the cloud infrastructure has to meet. The mostly implicit demands should be made explicit in the cloud requirements. The business is in the driving seat, but it needs to make clear requirements or use an agile approach in creating and checking the cloud infrastructure.

An infrastructure is set up with the usage of virtual infrastructure components; virtual machines emulate the physical infrastructure. When these components are created from standard components, a pre in IaaS, it’s possible to quickly connect the components including the correct high level functioning.

An infrastructure engineer can setup part of the cloud infrastructure and within in minutes check if it functions correct. With every component, either a system, an interface or any other infrastructure component, the system is build like a LEGO® building and checked if it works. When it doesn’t function as needed a change can be directly made to create the wanted situation. When it works another component can be added to the infrastructure; every component is integrated as needed in the infrastructure. This agile approach, is based on iterative deployment in which requirements and solutions evolve in combination and change is embraced, would therefore appear to offer a potential solution to the problems in a traditional approach.

The incremental deployment processes have been specifically developed to increase both speed and flexibility. The use of highly iterative, frequently repeated and incremental process steps and the focus on business involvement and interaction theoretically supports early delivery of value to the business. But the infrastructure basis is in defining the requirements based on Availability, Scalability, Reliability, Adaptability, Security, and Accountability, as described in this post.

Why developers don’t find defects

Posted on by
8

Fellow Twit @testingqa recommended this article to me. It’s about how your brain hides facts from you. Even if these facts are the thruth. This also has its effect of the software development process. On how testers should look at the SuT, but even more important why developers don’t find defects.

As a test manager I try to help developers test their created code and software. Most of the time they tend to check their code quite thorough but don’t see the errors in the software itself. They tend to look only at the mistakes in their own code, but don’t see errors everywhere else in the system. It’s like they don’t ‘see’ the defects.

When I was reading the article I learned that scientists have the same problem. They ignore failures. Kevin Dunbar states “Although we pretend we’re empiricists — our views dictated by nothing but the facts — we’re actually blinkered, especially when it comes to information that contradicts our theories.” I think this goes for a lot of ‘logical’ engineers. I state engineers because not only do software developers have this problem, but also analysts and testers. But why is this? Why is all data is created equal in our mind’s eye, but some data is created more equal than others?

This is because a part in the brain. This part, the dorsolateral prefrontal cortex, or DLPFC, is editing our reality. If you would like to know where it is. It’s located just behind the forehead. This DLPFC is one of the main reasons people ignore or suppress unwanted representations. It deletes unwanted information.

When a developer is checking the software for defects the software produces failures. And because the failures are unwanted to the developer they are ignored. Maybe they are not ignored on purpose, but because of the developer’s brain. Their DLPFC’s kick into gear and delete the ‘image’ of the failure from their consciousness. In most contexts, this act of editing is an essential cognitive skill. However, when it comes to noticing anomalies (defects), an efficient DLPFC can actually be a serious liability. The DLPFC is constantly censoring the world, erasing facts from our experience.

How can we help developers overcome this disability? We know it’s in their brain, but there can be action on taken on this. The article states four steps.

First of all check your assumptions. This is a skill a tester sometimes lacks. Run the test again and check if the failure is still there. Then look at your test and see if the test is correct. But also developers need this skill. They run checks at the system and when these checks fail, the system can be correct and the check can be false. Seek the correct failure.

Next is to seek out the ignorant. Use people from the outside to look at your software. Explain to them how it works and what is wrong. They can have a different view at the problem and can help you fix the problem in another manner.

Too often, developers assume that a failed check is a wasted effort, but testers or users think otherwise. Even analysts can see in differently. Let this diversity help enhance the software and make it work better. More different eyes on a system creates more helpful views on it! When everybody ‘sees’ the system the same way they all have the same DLPFC that kicks in.

The DLPFC shall kick in ‘delete’ the unwanted information. But if you are aware of this you can help yourself to take actions on it. You can try to be very methodical at what you see and act on this instead of your brain.

What I get out of this is that diverse teams help to develop better software. These teams can help each other to look at problems from different viewpoints. Agile teams try to use this diversity create a product faster, but also better. With this in mind agile seems to be a good option to use to help developers not to use their brain J!