Agile, Testing and DevOps: Are they a Separate conversation or a progression of capability?
DevOps, Testing and Agile have shared environments that facilitate working together. Spurred by greater demand for excellence, these three methods are more than simply adopting new tools and processes. The synergy involves building an evolving and a stable Continuous Integration (CI) Infrastructure, as well as an automated pipeline that moves deliverables from development to production to meet users’ expectations. They can work together, and the entire build process should be transparent, and it should enable and support development and operations. This transformation depends on: significant changes in culture; roles and responsibilities; team structure; tools and processes.
The Round Table session is for 45 minutes. The speaker at each table will have a set theme and delegates join any table that they are interested in. They are given all the topics with their joining instructions and again at the time of registration and so make their choice on the topics that they want to attend. This is a discussion group and so no presentation slides are necessary, but please submit a topic if you would like to chair a discussion on a topic related to Testing, Agile and DevOps.
Among the topic addressed are
Agile frameworks provide guidance for efficient operational software
Adopt a “build-and-run” teams concept
Automation and SAFe
Agile and DevOps – moving with flow based awareness
Testing: “Measure twice, cut once”
Continuous Testing – running tests at each stage of s/w delivery pipeline.
Improve DevOps with SAFe
Automating for improved flow
The agile release train and continuous integration
Scrum board Gamification
Modern Software Testing
Sustainable Test Automation
Individuals and interactions over process and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan…… have been achieved and helped establishing a faster and practical way of getting things done.
We are inviting speakers – thought leaders, subject experts and start up entrepreneurs – to share their knowledge and enthusiasm about their work and their vision in the field of Agile, DevOps and Testing.
We understand that successful projects are written up as “White Papers”. Please share these with us. But projects that did not achieve their targets – “Black Papers” – are of interest to us too. They can be a very important topics of discussion / panels that you can present. Talk to us about both, we welcome your input.
Please complete the speaker’s response form and submit a proposal to present at this event.
UNICOM’s Code of Conduct & Views on Diversity
We at UNICOM strive to be a leading provider of knowledge to the business community and to engage the global business community as a specialised provider of knowledge. We strive to do this maintaining a culture of co-operation, commitment and trust. We want every UNICOM conference and training day to be a safe and productive environment for everyone – a place to share research and innovation and to build professional networks. To that end, we will enforce a code of conduct throughout all our events. We expect cooperation from all participants to help ensure a safe environment for everybody.
Our approach is that our events are dedicated to providing a harassment-free experience for everyone, regardless of gender, gender identity and expression, age, sexual orientation, disability, physical appearance, body size, race, ethnicity or religion. We do not tolerate intimidation, stalking, harassing photography or recording, sustained disruption of sessions or events, and unwelcome physical contact or sexual attention. We do not tolerate harassment of conference participants in any form. Sexual language and imagery is not appropriate for any conference venue, including talks, workshops, Twitter and other online media. Event participants violating these rules may be sanctioned or expelled from the event without a refund at the discretion of the conference organisers. Please bring your concerns to the immediate attention of the event staff.
Diversity: In our endeavour to be the provider of knowledge to the business community, we understand that this depends on hearing from and listening to a variety of perspectives that come from people of all races, ethnicities, genders, ages, abilities, religions, sexual orientation, and military service. We welcome diverse speakers for all our events, we do not always fully achieve this goal, but it is an ongoing process.
Dave Snowden, CTO, Cognitive Edge
Before you place a bet in a horse race you check out the ground conditions. Some horses run better on heavy, wet soil others on the dry. The various method and ideology wars in the whole Agile movement is inhibiting innovation, preventing progress. Agile is increasingly starting to look like a highly structured commodity to the detriment of the original values. In this presentation Snowden will look at how to frame a mixed methods approach and radically reduce risk. Getting methods and tools defined at the right level, defining transaction protocols, looking at unarticulated needs and turning the involvement of testing to a much earlier stage in the development cycle all change the dynamics of delivering value for Agile and DevOps alike.
Seretta Gamba, Test Automation Consultant
In this tongue-in-cheek talk I will show how easy it is to disrupt or utterly ruin a test automation project. By describing seven proven methods to reach this end, I intend to give managers, testers and automators the means to recognize early on if their automation is in danger. And by ‘warning’ against possible defences I will actually give them the tools to counter and solve such issues.
Lynoure Braakman, Scrum Master & Programmer, Neuland - Büro für Informatik GmbH
The role of the Scrum Master is on the surface level easy to understand as someone making sure Scrum is implemented correctly and facilitating meetings. This talk is about the difference that can be made by Scrum Master who fully embraces the potential of their role.
Boris Wrubel, Software Test Engineer, Independent Consultant
Scrumboards can be annoying. It needs discipline of all team members to keep it up to date. But there are some things and easy fixes you can do to keep a better overview. Boris will show how you can motivate the team and trigger the gamer in all of them.
Ilari Henrik Aegerter, Managing Director, House of Test / Association for Software Testing
Software Testing is a young discipline and as with many new things, it is not yet fully understood. Is software testing a technical problem to be solved by engineering solutions? What exactly is the goal of testing? What can you do to become a world-class tester?
A world-class tester understands that we are confronted with a techno-human system and that our goal as testers is to extract and deliver information about the product in a way that help stakeholders to make the right decisions. Having said that, it does not make a lot of sense to distinguish between manual and automated testing as this categorization is not very helpful.
Ilari Henrik Aegerter presents a model of software testing that takes both engineering and social aspects into consideration. A lively discussion during the presentation is very welcome.
Sabine Wojcieszak, Agile & DevOps Enabler at getNext IT
In the agile world we find a lot of slogans around the topic of failure: "Welcome failure", "fail fast", "Fail early" or "Fail often" are used regularly. And in theory we all agree that we can learn from failure. Some of us also dreaming of a Blameless Culture. But then daily business chatches us up...
The search for the guilty person starts as well as the finger pointing procedure! Everyone can breathe a sigh of relief not being identified as the originator of a failure. The idea of having caused a failure is often closely connect with the fear of negative consequences. There ae still managers who believe that "punishing" is the only way to make people learn for the future. And yes, people learn: to hide failure; to avoid work, which is more complex; to not look out of their own box; to follow rules blindly and many more.
But in our modern and complex world failures often happen because of a concatenation of previous situations. If we use the chances of having a close and detailed look on all these events not only from the retrospective point of view, we will be able to identify weaknesses in our system and processes. And who can give us the best and most qualified insight of what has happened than the originator? The originator is the expert for this failure or failed situation and allows us a change in our perspective: not only the retrospective but also the situation and decisions through the eyes of the originator! But to enable this we need to guarantee a culture of psychological safety and punishment is not the way to do this! This talk will shed a light on the significance of the failure slogans for our daily work and doing as individual, as team and as manager. The talk will also take a look from the Just Culture perspective on the topic of failure and classify types of failures. The importance of knowledge management and resilience engineering will be discussed. The talk will try to answer the question what can be done to close the gap between our theoretical understanding of how to deal with failures and the actual daily doing. It will be a trip through the world of failure which will end up at the topics of culture, mindset, leadership and discipline to make the audience re-think their own behavior.
Paul Gerrard, Principal, Gerrard Consulting
Dorothy Graham, Software Testing Consultant
There are many places to visit it the world and it can be interesting to see "where you've been". There are many places in the software for tests to visit, and seeing "where the tests have been" can be very interesting for testers.
Dot Graham explains what coverage is, and why it can be misleading to talk about 100% coverage. Coverage is a relationship between the tests and the software being tested, and is an objective measurement of some aspect of thoroughness of the testing.
There ways in which the term coverage is mis-used, and four caveats of coverage which you should be aware of.
So is coverage a good thing to have? In other words, should testing be thorough? Not necessarily; sometimes testing should be more like strawberry jam than butter or margarine. Whenever you hear the term "coverage", there two important questions that you should always ask: Coverage of what? and Why?
Maria Ball and Terry Bowen, Senior Project Managers, Media Services, BBC Design & Engineering Platform
When the stakeholder "just" wants something simple done, they tend to expect it to be done quickly. What happens when there is more than one team involved?
In a large organisation, teams often work in silos, use their own flavour of Agile, and have their own roadmaps. It can be challenging to get the alignment and the flexibility needed to deliver a simple request. This is then complicated when the requirements evolve from the initial request to something more. Maria Ball and Terry Bowen discuss the complications they faced in managing the development and delivery of a project that required three internal teams and an external supplier, while using Agile methodology. They will share how they were able to resolve the conflicts and software limitations they came across to deliver the feature.
Kevin Rutherford, Software development coach
This talk presents a simple visualisation tool that helps software teams self-organise, deliver, and communicate more effectively. The talk uses examples from recent software development projects in a variety of organisations, showing how this technique has improved both the rate of software delivery and the engagement of key stakeholders.
Andrew Fullen, Digital Consultant, Sogeti UK
It isn’t science fiction anymore: Artificial intelligences have tackled chess, quiz shows and can even drive a car. Now they face the greatest challenge ever. Testing. How will we cope? How will they deal with us? And how do we test a computer system that knows more that we do? How can we trust the answers and what do we do when it gives us an answer that we don’t agree with?
Find out how you will start testing the world of tomorrow.
Steve Challis, Plutora
Test management is only one piece of an efficient software testing process. Enterprise IT teams need to consider test environment management and release management as well in order to successfully shift left.
Mark Smalley, The IT Paradigmologist, ASL BiSL Foundation
A fast-moving, entertaining and insightful session in which you’ll learn about:
♦ 'Selling' the value of DevOps to business executives
♦ Discovering the weakest link in the business-IT-business value chain
♦ Identifying effective collaborative behaviour between business and IT
♦ An ancient DevOps proverb “If you meet DevOps on the road, kill it”
♦ Language Constraints and Agile Coaching, Thomas Hoyland, Agile Delivery Lead, Sky Betting & Gaming
♦ Test Automation, Dorothy Graham, Software Testing Consultant & Author
♦ Approaches to Iterative Delivery, Seb Rose, Cucumber
♦ Environment Management, Steve Challis & Matt Drury, Plutora
♦ Test Automation Mobile, Jitesh Gosai, Team Lead / Tools & Infrastructure, BBC Digital
♦ “Put the spanner down Dave”: Intelligent testing on intelligent systems by intelligent testers Andrew Fullen, Sogeti
Stephen Mounsey, Agile Coach
Are you really listening? Listening is an important skill for any human being but for a tester an essential skill. If part of testing is about information gathering and interpretation then Listening is a key component.
A look at the art of listening, parallels drawn between listening theory and how we test.
Ash Winter, Consulting Tester and Speaker
API design looks easy, right? Lots of material, methods and examples to look at. However, we've not been on a team that hasn't struggled to build a clean interface for their consumers. From unconventional use of status codes, difficult to parse responses to endless debates about what to name endpoints. This is coupled with iteratively built API's, which potentially realise value and feedback earlier but may suffer from inconsistency over time.
By testing first with effective automation, common errors with API design can be flushed out quicker, even before the code has been written. Design and architecture should not be left to the developers and architects, by following some of these guidelines, as a Tester you will be able to contribute to a consistent, transparent and maintainable API.
Seb Rose, Cucumber
When you invest in the stock market you’ll often be warned to “remember that the value of investments can go down as well as up”. For over a decade User Stories have been the rock steady investment of agile adoption - and they’ve come a long way since XP called them “a placeholder for a conversation”. It’s time to re-evaluate what user stories are trying to achieve, what they’re good for, and why so many of them suck. In this session we’ll explore what a good user story should look like and discover why so many of them fail to live up to our expectations. We'll look under the covers of the INVEST acronym, popularised by Mike Kohn to help people write better user stories and look at why, in many cases, it doesn’t seem to have helped. It's time to stop investing in the boring, formulaic user stories that litter your boards, choke your JIRA and stifle your meetings. Today we're going to see how to make user stories RIVETing again.