Applying Accelerate as a Strategy Legend

TL;DR: What I learned from applying the research from the book Accelerate (2018) by Forsgren et.al. as a strategy legend on my Wardley Strategy Map. Spoiler alert – it’s more about people than technology.

I use Wardely Maps to read my projects’ context and identify a test strategy that aligns with stakeholder needs. Currently, I am doing yet another project – this one is primarily based on Infrastructure as Code (IaC) and Functions as Services (FaaS) and creating an API engine/event-driven broker. My usual starting point was my Situational Aware Test Plan template – below with the headings from my DPCG mnemonic.

	Darlings	Pets	Cattle	GUID’s
Situation	X
Delivery / Release frequency			X
– Staffing	X
– – Collaboration	X
– Environments			X
– – Tools				X
– Test scope / Verification			X
– – Test Data		X

This is not a map

This, of course, is not a map, as I have not considered the user need, but more given each element a score based on my initial reading of the project. It’s a new project team that hasn’t worked together before – building a new system, that does not yet exist similarly. That we know of – so it’s Cynefin Complex domain. The tech stack and testing challenges are well-known and can be mostly automated.

There is probably a natural order to the items above: It’s a new situation (for the customer too) and a release is needed. the delivery needs staffing – staffing needs collaboration and tools. Delivery (releases) needs environments and verification and verification needs test data. The table is neither a strategy as I have not considered which items to move – but I had an idea.

Research From Accelerate

ACCELERATE – The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations by NICOLE FORSGREN, JEZ HUMBLE, and GENE KIM (2018) identified a key set of practices to optimize for organizational performance and a great delivery culture:

Saved you a click: https://itrevolution.com/book/accelerate/

If we zoom in, we can see the prerequisites for Continuous Delivery to be successful:

• Test Automation
• Deployment Automation
• Trunk-based Development
• Shift Left on security
• Loosely Coupled Architecture
• Empowered teams
• Continuous Integration
• Version Control
• Test Data management
• Monitoring
• Proactive system notifications

These items are just in the order from the book – but I can similarly score our ability and tools. Because of the platform, most are a commodity or best practices: Loosely Coupled Architecture, version control, CI/CD, trunk-based development, and deployment automation. A few require a bit of a push from possibility to active use (proactive system notifications, monitoring). The sore spots are (as detailed in 24 Key Capabilities to Drive Improvement in Software Delivery):

• for the development team to own test automation: Test automation is a practice where software tests are run automatically (not manually) continuously throughout the development process. Effective test suites are reliable—that is, tests find real failures and only pass releasable code. Note that developers should be primarily responsible for the creation and maintenance of automated test suites. 
• establish test data management: Test data requires careful maintenance, and test data management is becoming an increasingly important part of automated testing. Effective practices include having adequate data to run your test suite, the ability to acquire necessary data on demand, the ability to condition your test data in your pipeline, and the data not limiting the number of tests you can run. We do caution, however, that teams should minimize, whenever possible, the amount of test data needed to run automated tests. 
• Empowered teams: Research shows that teams that can choose which tools to use do better at continuous delivery and, in turn, drive better software development and delivery performance. No one knows better than practitioners what they need to be effective.

The Test Strategy

Hence my focus as a test manager would obviously be the first two. Let me be the first to move for test automation by the developers (the domain for the test is mostly API endpoints) and the first to ask for killing the test environment so that we can learn to bring it up again – and again.

But because I care – and because I have read in the book what is a requirement for the listed team capabilities above – I should be mindful to consider also empowering teams and encouraging transformational leadership: Vision, Inspirational Communication, Supportive Leadership, Intellectual Stimulation, and Personal Recognition.

Using the research from Accelerate as a mapping legend for the team’s Continuous Delivery Practices I can see that even with state-of-the-art tooling and a modern high-level stack – it’s a people problem first of all – and thus the test strategy is threefold:

1. Encourage testing by the developers (evolve test automation)
2. Prioritize the construction of stubs and drivers for test data (evolve test data)
3. Encourage collaboration, learning, and a supporting culture (evolve culture)