By Pim Smeets & Evelyn van Kelle

A real team is more than just a collection of individuals . It provides members of that team with a common purpose, identity and a safe-to-fail environment where people can thrive together and creativity flows freely. Building a team is hard work, requires significant (emotional) investment and takes time.

A while back the virtual Domain-driven design meetup experimented with doing a remote EventStorming. The outcome was that doing remote EventStorming as you would do it offline is sub-optimal. The interaction was lacking during the storming parts, and the number of insights gained was lower. That is the power of EventStorming, and it was not present. Still, we asked ourselves how we can make remote EventStorming more optimal, and with most of the world being stuck at home due to corona, I started experimenting with it. In this post, I will describe heuristics about my first experience with remote EventStorming.

The jokes must go on

It sounds like a paradox. Contradictio in terminis, as the linguistic in me likes to put it. Staying connected in times of isolation. Now that most of us are working remotely, teams need to find ways to stay connected. 

I’d like to think that times like these also bring opportunities for us to get creative, learn from each other and rise above ourselves, so let’s share ideas and experiences as much as possible. 

There is a lot of buzz around the practice of Progressive Delivery lately. Rightfully so, as it’s a great addition to continuous delivery. By gradually exposing new versions to a subset of users, you’re further mitigating risks. As usual with new and shiny things, many of us are eager to try it out, learn about the tools and shift to this way of working. But as is also common, there are reasons to do it, reasons to not do it, and reasons you might not succeed at it. Let me save you some trouble by elaborating on a few of them. 

Did you know that, on average, we use six metaphors a minute? Surprised? Me too! They are so embedded into our speech that mostly we are unconscious about them. Research suggests that metaphors change the way we think of a concept on an unconscious level.

In 2011 a study was conducted in which two groups of readers have been presented with two articles describing the same crime. In the first article, the crime was compared to a beast, and in another to a disease. When asked to solve the crime issue, readers of the first article suggested control strategies while the second group came up with diagnostic or treatment strategies. Hence, changing the metaphor changes the way we think.

Introduction

In the current day and age, technology is becoming part of the core business of many organizations. The software landscape is increasing in size rapidly, and the complexity of the systems grows. When applications, services, or even the entire IT landscape become unavailable, this will have a severe impact on the continuity of the business. 
Many companies rely heavily on third parties to run and support their systems; this ranges from integrations with SaaS services to building upon the services of a hosting party who run the software and maintain the hardware. Without these parties, it is impossible to run your software; however, what if they suddenly can not deliver anymore? 
If integrations with third-party software stop working, then your application will lose some functionality. Worst case scenario your application stops functioning altogether. The same issue presents itself if your hosting party suddenly can not deliver anymore. If your software is not running, then you are unavailable as well. This blog discusses how to prepare and handle such issues.

Mapping the current situation

The first thing that you need to do is to make sure that you have an accurate mapping of your existing software landscape. With an accurate representation of the landscape, you can create an overview of all third-party integrations, making sure you do not miss any. Using this overview, you can determine which integrations are responsible for which part of each of your functionalities. Order these from most important to least important, and you know exactly which third party software is most important to you, allowing you to prioritize properly. 

Ask a statement about their continuity

If you have not done this already, then now is the best time to do it. Once you have a good overview of your current situation, you can start to contact your third-party providers and ask them about their continuity. They will probably have a statement at the ready for you, which you can use to determine if it is enough to meet your demands. If they do not have such a statement, then that is already something to take note of. Why do they not have such a statement, are they prepared to keep the company going even in tough times? In the future, you should ask these questions upfront, before you start using a third-party service if you did not do this already.
Of course, there is still a chance that the company fails to comply with the statement, if that is the case, you will have to make sure that you are ready to handle the issues that arise because of this. Below a number of solutions for these issues have been stated. 

Integrating with third-party software

If your application integrates with third-party services, then you need to check if they have an Escrow agreement. An Escrow agreement allows you to take over the companies source code in case of the company going bankrupt or if something else goes fatally wrong. This allows you to start running the software for yourself until another solution has been found. Preventing you from being unable to use that service. 
Of course, this is a temporary solution. You do not have any employees that can maintain this solution, and you also had a reason for buying this software instead of writing it yourself. The code of these companies is often complicated for you to maintain and expand upon as well, so if this happens, you immediately have to start thinking about new solutions. Finding a replacement for this software is the most natural solution. Another solution is to revise the decision to buy the software and decide to start writing it yourself. However, just keeping the software as you received it will inevitably end up causing problems, such as security issues.

 
Conclusion

Software solutions tend to rely more and more on external factors that you can not influence as a customer. Therefore it is important to be aware of the risk these external factors bring and what happens when they become unavailable. Your company needs to have a clear idea of which preventive actions to take and how to handle it when a third party becomes unavailable. This blog discussed a number of preventive measures that you can take to make sure the unavailability of third parties will not affect your own business continuity. 

Ever since Nick Tune introduced the world to the Bounded Context Canvas, I incorporate it in my workshops and trainings. Nick sees the canvas as a checklist for designing our Bounded Context canvas. For me, it is also perfect as a visualisation tool to make the Bounded Context explicit. The one thing I am missing is examples in the form of acceptance criteria discovered and eventually formalised during our Behaviour Driven Development flow. In this post, I explain how I extended the Bounded Context Canvas with BDD examples from Example Mapping to show how to formalise the behaviour of a Bounded Context.

In information security we have a saying: ‘never waste a good crisis’. As grim as this may sound, there are valuable lessons to be learned from situations like the recent corona outbreak. As seen in the news a lot of companies close down their offices to limit the transmission of the virus. However, this can impact your efficiency or introduce new risks. What can you do to assess this?

Welcome to my second blog in the series of five quality patterns in Agile development that can help you to deliver the right software with great quality. In my previous blog, I’ve introduced Example Mapping as a method to get to specific examples for scenarios or rules that your user story is made up of. The output of the refinement sessions are your requirements and thus your tests. In this blog, we will take a further look at these test cases and why it is important to automate these acceptance tests. Not just from a development team perspective, but also what they can bring to your business.

In a previous blog, we described a novel way for software QA for refactored code already running in production inspired by the Scientist approach GitHub published in 2016. In this blog we explain how we implemented this QA method for testing AWS Lambda functions and our experiences with that.