How to escape the traps of development and testing in multiple streams of work

Prelegent: Bruno Mańczak
Software Quality is important but so is Time to Market, i.e. time needed for the software to reach its end-users. Balancing between those two factors decides which product prevails and which product becomes obsolete and forgotten. Fortune awaits for The One who knows how to find the balance between those two forces.
Take Friendster as an example: it was a social media website which started in 2002 and was adopted by 3 million users within the first few months. The attention was so big, that the website started to struggle with performance issues. It was so slow, that eventually myspace took over. After additional two years, Facebook launched. Who remembers Friendster now? An indigenous example can be found in Poland: NaszaKlasa („OurClass”) faced the same issues.
Unfortunately for QA engineers, quality of the software we test, automate and care about is definitely not the only factor determining the success of what we are building. But it for sure is one of the most important ones (why test otherwise?).
This presentation aims to describe lessons learned from a real project, where I learned in a hard way that quality can be intentionally lowered by some stakeholders to meet the imposed deadlines.
To speed up the development the project was delivered by multiple scrum teams working in parallel and it was supposed to introduce agile methodologies to the company we worked with, as well as train its employees in software development. The presentation will exhibit practices that went well and things that did not work out. I will highlight some consequences of not following some well established good practices of software development.
There are plenty of materials available on the web about scaling the scrum methodology. Software development is an industry that has matured over last decades. Thus a problem you are facing is probably (but only probably) a problem that someone already tried to solve in the past
I have seen very little technical problems when coordinating the work of multiple streams. Technology is mature enough to support such a way of working. The hardest challenge that one needs to face is communication or reluctance to change the processes and already established ways of working. Lack of communication, bad communication or too much communication – all of those can lead us to various traps and make our projects fail.


Tagged under:

Program konferencji

TwitterFacebookLinkedInGoogle+