tearing down walls

Table of Contents

Key Takeaways

• Silos and lack of collaboration slow down software delivery and create quality gaps.
• Adopting Agile and “Shift Left” practices helps break down walls and foster teamwork.
• Involving QA, security, and business stakeholders early leads to better outcomes and faster feedback.
• Automation and continuous integration support the shift to a more collaborative, efficient process.
• Co-located, multidisciplinary teams deliver better solutions, reduce risks, and keep improving together.

The “developer throws their code over the wall to someone else” analogy is one of my favourites. It helps to truly visualize one of the key inhibitors of modern, enterprise level software delivery. The silo.

The picture is a little something like this;

A developer creating code and throwing it over the wall. Satisfied in his silo, that his code is great, the developer moves onto another story card, task or project, that developer has put this code far out of their mind - it’s someone else’s problem now.

Sure, the code may be tested at a unit level and it may even have some functional tests included in as part of the merge - but a developers’ definition of done probably varies drastically from someone who is responsible for QA or even the person in the business who is in-charge of the particular product or area. But the developer doesn’t care, he’s gone.

Now enter the QA - in his own silo, separated from the developer by the wall, along to the big pile of code on their side of the wall and picks up a ball of paper and unfolds it - looks at it from a few different angles, then goes off to make sure that there are tests covering what they believe the code should do based on what is written on the piece of paper.

If there are no unit tests, QA are left to test as much of the affected code as they can with very limited knowledge of the expected outcomes or expected behaviours of the newly modified system. Regression testing ensures things that weren’t broken before code changes were made, did not break as a result of the code changes.

Where does the QA go if they want to try and understand some of those edge cases and make sure they are covered in the test plan they are writing up? The developer has moved on to the next thing, sure you can usually find who wrote a particular line of code (thanks git blame) but usually it’s so far out of their mind that when you have questions. They will probably resort to reading back into the code or reading possibly outdated (if it even exists) documentation to try and get some answers.

Can you identify the problems?

With traditional waterfall methodology, units of work make their way down the waterfall with little or no communication between the different stages and often no common understanding or outcomes. There are often communication issues (or no communication at all) between business stakeholders, developers and QAs.

Enter Agile and the Garage Method.

Culture is the starting point for innovation and agile transformation. According to the agile manifesto, an agile culture values individuals, interactions, working software, collaboration with customers, and response to change.

To truly embrace and embody agile, the new objectives and benefits of agile to your teams must be clear - the methods must be adopted from the bottom up with sufficient sponsorship at the top levels (often executive) to uproot a no doubt well ingrained and well defended culture that is resistant to change (after all, if it wasn’t resistant to change, you would already be agile). With that in mind, be warned, since it’s easy to say “we want to embrace agile” but it is hard to really go all in and truly embody agile culture within your teams. Unfortunately, very little of the benefits of agile are realized when you pretend to be agile, but continue to work in a waterfall-ey way with a sprinkling of Kanban boards and Stand Ups every day so that you can stand up and say “look how agile we are!!”

Some challenges are not just mental or theoretical either, take the wall analogy from before. Your Dev and QA resources might not even reside in the same building or be in the same country, never mind be working together in the in a colocated space. You might need to, literally, break down walls to foster collaboration and co-creation. Creating (or building) new collaborative spaces can be a tough idea to sell up top (virtual spaces can work too), but I’ve seen first hand the benefits of a space that a squad can call their own - equipped to allow ideation, co-creation and real productivity as an effective, multidisciplined team.

You need to challenge the established normal and take a second to pause and evaluate what needs to change, what makes sense in an agile world? Again, the QA example. Testing code that’s been thrown over a wall by a developer after build isn’t really quality assurance anyway is it, (hint: no) it’s actually quality control. So you’ve discovered that your teams aren’t even delivering their intended functions anyway, so how do you move forward in a positive direction without a) massive structural organizational change b) hiring a new team that know agile from the ground up?

You can start by shifting left and aiming to build diverse, multidiscipline teams.

The principle of Shift Left is to take a task that’s traditionally done at a later stage of the process and perform that task at earlier stages. An example of this is testing. With the traditional Waterfall model, testing is done just before releasing the product into production. This means that serious problems uncovered so late can cause major redesign and long delays.

Shifting left is the ethos of “fail fast, fix fast” that allows teams to build and deliver high-quality products and features rapidly, consistently and with a tight feedback loop to enable continuous improvement.

This enables allows your agile team to react early, build quick and fail fast and learn. Then do it all over again. Moving discussions closer to the left side of the software delivery cycle allows for problems and issues to be identified and assessed early, when there is time left in the budget to adapt and tackle those problems.

Most people know continuous integration and continuous deployment at a high level, but this more than just delivery of code into branches and deployment of artefacts into production. It’s about continuous involvement, continuous collaboration, continuous creation, continuous compliance, continuous feedback and continuous improvement.  

Shifting left addresses your pain points with testing by involving testing teams early in the process, and this can be true of most capabilities you decide to shift left. Shift left long-term is less about problem detection and more about problem prevention. Issues in design or coding can be observed and solved early by effective (but not cumbersome) collaboration, process and governance - before they, become blockers or inhibitors to your teams.

This shift in mindset changes the QA from someone in a silo, on the other side of a wall being drowned in paper balls, to someone who is really part of the same team as the developer. Someone who feels empowered. People who are now part of a team with common understanding of the desired outcomes and direction of the features they are being asked to assure the quality of. Someone who can provide input and expertise into the early conversations around the definition and design of the potential feature, someone who can help the team to truly understand what quality means and deliver value early.

And this example is not just restricted to QA, or even testing. You could and should have (for example) Security addressed right from the early stages of development, (this is commonly achieved by combining DevOps and security into a practice called DevSecOps). Teams should be thinking about running their software, not just building it - continuos deployment has become common practice in the cloud world, but your team should be having the conversations centred around operability and performance right from the early stages of development. You should be including your business stakeholders in the process, not just your technical team, collaborative design and requirements analysis will ensure you have a product that is fit for purpose and that the expected outcomes for your features and ultimately your software are discussed, aligned and agreed with the team before a single curly brace has been stamped. Your team can adopt a design thinking mindset, adopt a user-focused, outcome-first approach, organize their work into smaller more cohesive change sets and ensure that all of these considerations are being included as far left as is practical in the feature lifecycle.

Shift Left is about culture, processes, and people but it’s accelerated and enabled by effective and flexible tooling. Automation tools play an integral role. The same tools within a development environment can often be reused (or continue to be used) and with the help of automation and careful analysis of the responsibilities of those automated pipelines they can ease the implementation of Shift Left. Continuous Integration and Continuous Deployment both rely on automation and will help to accelerate your Shift Left and Behaviour-Driven Development.

So what benefits can you expect for your new co-located, diverse and multidisciplined teams? Here are a few highlights which I often observe;

• Better designed solutions through shared collaboration
• Better distribution of knowledge of the code and the expected behaviours within your team
• Faster delivery. Complex issues are identified early and solutions to challenging problems are found more quickly
• Consistent processes and practices through collaboration and automation
• Improved feedback. Teams show constant and demonstrable progress.
• Reduced technical and business risk. Your teams understand your system and are flexible enough to adapt and react to any problems which might spring up.

What’s next?

Make sure you and your teams are committed to your agile journey and shifting left. Take the time regularly to pause, reflect and review. Always consider the health of your squad, as healthy squads are happy squads. Don’t just spend time reflecting on your lows, but make sure to celebrate your highs - but always together, as a team.