SOGETI UK BLOG

Closed_for_Maintenance_JPGAs you all know, an increasing number of companies are moving their development processes toward so-called agile methodologies. From a (very) high-level perspective, the goal of these methodologies is to avoid long development cycles, where the user won’t see their product until it’s finished. This goal is obtained by using incremental development cycles where a few new functionalities are developed during each cycle, but in each cycle a fully functioning (sub) product must be delivered to the user.

Using an agile methodology, a higher interaction with the user is put in place, which allows for better communication, less misunderstanding, and finally, a more satisfied customer.

To allow these short development cycles (usually a few weeks), some renouncements have to be taken:

– Small and highly skilled teams are needed instead of big heirarchical teams

– Daily meetings and exchange between team members

– Continuous testing (instead of the usual: let the customer do it…)

– Lightweight documentation instead of complete requirements and functional analysis.

What we have here is a theoretical model, and as usual, each company has its own implementation based on one of the numerous declinations of the Agile Manifesto (foundation document of Agile development methods), such as Scrum, Kanban, AUP, etc.

In the last 5 years, agile has been skyrocketing here in the UK, and the same is true around Europe. Almost all of our customers have implemented or are experimenting with agile, and we have already seen an important number of projects developed in this way. 

In most cases agile implementation has been positive. It allows possible disasters to be detected much sooner than under a traditional development lifecycle. This is an important point that allows the development and testing team to either correct the problem or to scrap the project with much lower costs than big monolithic projects. Of course, some failures have also been registered, but probably much fewer than with traditional projects.

In every case, there is a common result that I must say is not directly related to development methodologies, but more to human being’s natural procrastination allied to unrealistic planning: the lack of good documentation at the end of projects. Agile unfortunately seems like a good excuse to create any documentation, since it is considered as no longer being the core of the development and the agile manifesto claims that working software is more important. This isn’t the case – less documentation is needed, certainly, but an amount is still necessary for ongoing, successful delivery.

Agile projects, once in production, will probably be better adapted to customer needs, leading to higher customer satisfaction due to projects being done on time and on budget. From a maintenance point of view, they will be the same nightmare as usual…

Related posts:

1. Agile-Testers as the Trojan Horse in Traditional Development Projects!
2. Apps development loves agile methods
3. Large, complex projects benefit most from Agile
4. Agile (testing) – the final solution?

Patrice Marillier AUTHOR:
Patrice has been working in the IT industry for more than 25 years, and is part of Sogeti for 14 years, since specialized in Software Testing activities. He is responsible of the Sogeti’s Spanish Software Control & Testing delivery, trying to convince Spanish customers that saving money on a development project does not mean necessarily shaving testing budget.

Posted in: Application Lifecycle Management, communication, Innovation, Opinion, Quality Assurance, Rapid Application Development, Scrum, SogetiLabs      
Comments: 0
Tags: , , ,

 

Pair testing gone wrongThis post follows Gro Rognstad’s previous entry about how Product Owners should be supported in the Agile process, to allow better results in the development process. My humble contribution wants to show that even in adverse conditions, it is still possible to have a controlled and efficient testing process.

In the past few years, we have been able to witness a major shift in software development methodologies: Agile methods, through their various implementations, are now everywhere. Nowadays, companies that do not have their own Agile Software Development Lifecycle (SDLC) seem to be coming from another age (closer to prehistory than to 21st century).

Nevertheless, when coming to complex projects, Agile methodologies are much tougher to manage than initially foreseen, and a lot of challenges must be solved, due to the increased complexity of interactions between several development teams. Talking specifically about testing (sorry, that’s my job…), our experience shows that in these kinds of complex projects, one should not throw away all the experience acquired during the “prehistoric” times we were talking about at the beginning of this post.

Let’s talk about a real example: two years ago we started a project for a low-cost airline that was (as they usually do in this business) moving very fast in a very competitive market. At that time, a lot of new features were developed and tested during each release cycle. And yes, they were able to deliver the new functionality as planned, and in a rather good shape. Unfortunately, doing such a good job on new functionality had a drawback: not enough time and, more than anything, not enough forward thinking to organize an efficient regression testing process. This problem was particularly critical as almost no part of the system was kept untouched during new releases.

Don’t forget that the customer was a low cost airline with a tight budget; because optimization was key, we started by first controlling the regression test process and introducing some TMap® techniques to optimize testing coverage:

–  Effort estimation using standard techniques

– Risk based test prioritization

– Optimized test design based on TMap® techniques

These techniques, which are of common use in normal (i.e. not Agile) testing projects, were rather simple to implement and immediately brought profits to the customer, allowing for better control of regression testing process, and limiting defect leakage in production.

Pair testing gone wrongOnce regression testing process went under control, we started to extend these techniques to the rest of the testing phases, resulting also in benefits on the coverage obtained during the testing of new features. Once again, utilizing “old-world” techniques but maintaining agility helped to join the best of both worlds: fast movement and quick results but in a controlled and predictable matter, something which is more than important when you really want to go fast…

This post was based on the document created by Isaac Alvarez from Sogeti Spain, which describes in a more detailed way the real story behind this post. Interested to know more? Get in touch!

Patrice Marillier AUTHOR:
Patrice has been working in the IT industry for more than 25 years, and is part of Sogeti for 14 years, since specialized in Software Testing activities. He is responsible of the Sogeti’s Spanish Software Control & Testing delivery, trying to convince Spanish customers that saving money on a development project does not mean necessarily shaving testing budget.

Posted in: Agile, Software Development, SogetiLabs, TMap      
Comments: 0
Tags: , , , , , , , , , , , ,