The last few months have been challenging for most Sales teams, and ours has been no exception. The uncertainty of the economic climate has led many businesses to hibernate. In the space of a couple of weeks, the market went quiet; projects were put on hold, budgets cut.
According to the 6th principle of the Agile Manifesto: "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." So, does it mean that managing agile projects in the new world of large-scale remote working is impossible? Our answer is no! In the previous blog, we talked about how we ensure efficient communication with the home-based teams. In this blog, we discuss the important adjustments we’ve made to our remote Sprint Planning meetings as part of our Agile project delivery.
The quality of communication within a project team is often the most important aspect in the successful delivery of any project. Since our switch to remote working at the start of the pandemic, we’ve been faced with the challenge of using our project management tools in different ways to ensure that the quality of our communication and collaboration doesn’t suffer.
COVID-19 has turned our lives upside down. Just a few weeks ago, companies had to quickly transition all employees to work remotely. As businesses and people are gradually adjusting to the new circumstances and realising the benefits of working from home, many predict that this operation model is here to stay far beyond the crisis.
At Infomentum we have successfully moved towards a centralised logged infrastructure where systems, application, network and security logs are parsed and made available in one central point. Using components such as Elasticsearch, Logstash and Kibana, our logging infrastructure provides us the ability to apply filters to perform queries and basic trends analysis or counts.
One of the challenges we faced was shipping Windows Server logs from a logfile onto Logstash’s syslog listener, and we found a tool that does exactly that - nxlog-ce-2.9.1716
Part 2: Implementation
In Part 1, we talked about picking the tools for our first foray into the world of headless Content Management System (CMS) architectures, during our project with Fudgelearn. We had other options on our radar, but we decided that WordPress was the CMS that fit in best with our requirements. These were the main ones:
Web development is accelerating at an incredible rate - new frameworks seem to pop up every day. Whilst this is exciting (at least to a front-end geek like me!), it can be difficult knowing which new tools are any good and which ones you should be using.
In my last article, The evolution of test documentation; lessons learned from implementing Cucumber, I explained two things. Firstly, how we at Infomentum have adopted Behaviour-Driven Development to define test scenarios, and secondly, how we use Cucumber JVM as an implementation platform for running these scenarios as automated tests.
The old way
I'm going to let you in on a secret. I learnt my trade in a traditional software testing consultancy - I'm talking a waterfall approach to test planning, test case definition and test scripting. Over the last 5 years at Infomentum, I've evolved and have worked hard to optimise Infomentum's testing practices to suit our agile development environment.
The fun side of cultural change
You’ll remember that last week I discussed the crucial need for a cultural change in how we dealt with time logging. After the CX team’s thorough research, we were ready to take the findings – and our ideas – to our board of directors.