Closing the gap between business and technology

Closing the gap between business and technology

27% of final decisions regarding IT planning, spending and management are now made by someone other than the IT department. For a successful DevOps transformation, you need to have implementation come from both the top and the bottom. Here’s how…

For a successful DevOps transformation, you need to have implementation come from both the top and the bottom.

A recent survey by IT industry association CompTIA found that 27% of final decisions are now made by someone other than the IT department (i.e., the heads of other business functions such as finance, marketing, sales and logistics).

Within a bottom-up, grassroots approach, whereby engineering alone is trying to build a better continuous development pipeline, without the support from senior stakeholders, DevOps will only stay siloed in one area. DevOps can and does scale across whole organisations, the problem is that there will be disconnect between the business and development teams. Changes to the organisation and culture are needed to close the gap.

But how should you go about ‘bridging the gap’?

It sounds cliché, but it’s all about communication. Ensuring goals of both the organisation and the teams within it all have overarching and very strategic goals they can work towards collaboratively. Making sure every product is geared towards achieving that goal. Whether it’s to increase sales or click-throughs to a specific page of a website, it must be specific, clear and concise.

Organisations must bring the business and development teams together so they can build products that help achieve strategic goals, and there are a number of effective ways that can help achieve this.

  1. Impact Mapping

Impact mapping is a strategic planning technique that prevents organisations from getting lost while building products and delivering projects. It does this by clearly communicating assumptions, helping teams align their activities with overall business objectives and make better roadmap decisions.

2. Customer Dashboards

Another way to ensure your team is guaranteeing business and IT function buy-in is through custom dashboards. These show you a representation of where you are as well as the business value of the digital transformation. The best countermeasures to inaccurate communications are the mutually reinforcing pillars of automation and measurement.

Automated systems, like custom dashboards, enable better reporting of business metrics. Rather than relying on information that’s filtered upwards to executives, you have an objective measurement system to share across the business, helping everyone get onto the same page.

Meeting the strategic goals of the organisation is imperative. Dashboards are one of the ways we ensure that we are as transparent as possible when communicating our progress, inspection and adaption from the other two core pillars of Scrum Theory and should be adopted not just at the engineering and team level, but also the program and portfolio level. Mapping things at the start does not mean that the job is done, we must update the plan to take into consideration the competitive landscape outside the organisation.

3. Organisational Culture

Finally, organisational culture is extremely important when planning a Digital Transformation project. It often comes down to how your team communicates with one another that makes the biggest difference. Ensuring that your team plans workshops with business/IT functions to get the most value from the projects, and all stakeholders are kept up to date with new developments on the project will also help.

What have we learned?

With the two examples outlined, it’s clear that if you don’t get your business involved, the product team can easily go-off on a tangent. The business will be frustrated as the product won’t be servicing a business need, and objectives will not be fulfilled.

Communicating is key, without it both parties will become disengaged.

Cultural change has to come from the top, leadership must be bought into the transformation and motivated to make it a success. Those at the coal face, the development teams rarely need convincing, they understand the benefits of a DevOps culture and in most cases will always be your path to least resistance. The key to developing applications that release true business value is bridging the gap between the two, the development teams should be seen as part of the business, rather than a service set up to support it.

ECS Digital can help you close your business’ gap on your digital transformation journey, get in contact today to find out how. We held a webinar in November which explained how to get past the DevOps Deadlock within your company – watch now.

Sarndeep NijjarClosing the gap between business and technology
read more
Behaviour Driven Development: It’s More Than Just Testing

Behaviour Driven Development: It’s More Than Just Testing

Behaviour Driven Development (BDD) is a business-first approach that puts an agreed definition of ‘success’ at the heart of development and testing.

It’s about proper communication from the outset, getting all stakeholders in the business to set out what ‘done’ really means. This, then becomes the cornerstone of agile development, a vision of ‘success’ that all departments can work towards and test against continuously. When properly implemented, BDD should lead to better productivity, quality, rate of change, and ensure that accurately developed products reach the market fast.

BDD is a powerful technique, popularised by Dan North in the early 2000s, that grew from Test Driven Development (TDD). Developers were realising that TDD wasn’t the right fit for their agile development environment; it didn’t provide proper boundaries or structure for coders, because there was no explicit definition of success built in.

If anything, it asked more questions than it answered: When should we test? What are we testing for? How do we know a test has been successful?

The BDD Difference

BDD is often misinterpreted. It isn’t a testing framework that allows you to automate tests, although such techniques do form part of it. Rather, it’s a way of working that promotes testing for the right reasons, at the right time. It’s about communicating business value within integrated teams, and altering development priority from one that tends to favour implementation to one that also considers proper functionality at every step.

To do this, BDD encourages keeping code repositories and consistent toolsets, as well as making everything accessible and readable to all stakeholders, whatever their technical skills, through the use of natural language.

It’s also about testing more than just code. Before development even begins, BDD leads us to test our assumptions about what the software should do and how it should be constructed. Working through hypothetical situations on use and construction leads to more accurate requirements specifications; these, in turn, create a common understanding and a more efficient and painless development cycle for all involved.

Project owners and BAs working under BDD-enabled Project Managers gain greater flexibility and create better requirements documents. Developers, when all levels are involved in its creation, become less sensitive about criticism and analysis of their code, and improve their focus on the reasons for its creation. Testers find themselves more able to appreciate the user perspective, and their tests become more efficient. At every level, BDD can make a huge difference to the business.

Recommended tools

Communication is the key tenet of BDD. There are a number of tools and techniques that can aid the implementation of BDD and the enhancement of agile communication in teams:


Similar to pseudo-code but even more abstract, Gherkin is a writing syntax that puts the ‘what’ in front of the ‘how’. Writing and reading Gherkin’s simple constructed language is an ideal way to structure acceptance criteria and example scenarios, which leads to more accurate software specifications and a much lower defect rate on the tail end.

It’s also inherently testable: Gherkin is an executable specification, created for use with automated testing tools, such as Cucumber and Specflow and others. Check out some examples from the Government Digital Service to see what Gherkin is all about: about

The Three Amigos

Unity and communication are, in any agile team, priority number one. The Three Amigos (or Power of Three) concept pushes for pre-development consultation between Dev, QA and business analysts, the latter of which presents the aim of the project and its testing criteria, which is then discussed and developed in combination between the three pillars of its development.

This helps solidify requirements, understanding, and the goal of each part of the development cycle right at its inception, as well as codifying the three elements into a single team. With a combined and co-developed goal, and communication firmly established from the outset, change is easier to handle and can happen much more rapidly.

Impact Mapping

Strategic planning isn’t easy, but impact mapping, a form of discussion-grown mind map, makes it easier to approach. It breaks down the task into its key goal, the actors who will interact with that goal, the impacts those individual actors will have on the goal, and only then are the deliverables which come from those impacts considered.

This results-first structure aids in doing away with the counterproductive features shopping list, and instills greater understanding of the project up and down the chain.

Living Documentation

At every stage of a project, every cog in the machine needs to be aware of which way the others are turning. Living documentation and BDD go hand in hand; as examples are generated for use as acceptance criteria, they’re added to a living document as a matter of course.

This documentation forms the core of the project, and grows and develops alongside it. Written in natural, formulaic language like Gherkin, it is useful for everyone from stakeholders to testers to developers at every stage of the project’s completion, and trickles down to maintenance teams once development is complete.

Test automation frameworks

BDD helps to soften the nervousness around adoption of automated testing; living documentation means the inputs and outputs are available quickly and immediately quantifiable by all involved. Automated frameworks remove human error when properly applied, and drastically reduce workload.

BDD success

Many companies are employing BDD to great success. The Financial Times uses BDD techniques to structure its projects and ensure that ownership of testing isn’t restricted to developers – it’s a group effort. Says Platform Tech Lead Sarah Wells:

“I knew we were getting somewhere with BDD when our first response to questions about a story we were already working on was to grab the product owner and a tester and add new scenarios into the feature files right there. You can’t easily do that with a unit test.”

There are other major users too – from Paypal to BP to News UK – but the true success of BDD isn’t measured in numbers, it’s measured in less quantifiable metrics: team unity, communication and development efficiency, project success.

Eyes on the prize

It’s important to reiterate that BDD itself isn’t a tool or a testing framework; it’s a ruleset that produces order. It’s a subset of agile development that encourages working from the outside in, putting testing first, and collaborating and communicating efficiently between team members of all levels and roles.

With everyone on the same page, and that page being the correct one, more resources can be spent on progression rather than correction. Knowing what success really means helps to drive teams towards goals in a fast, united fashion. BDD means better products, better communication, and better teams.

If you would like some more information about Behavourial Driven Development, or if you have any questions, please get in touch.


Sarndeep NijjarBehaviour Driven Development: It’s More Than Just Testing
read more