I’ve recently been working with project teams who are attempting to remain effective after their organisation has chosen to adopt the Scaled Agile Framework (SAFe).
I’m trying capture & refine the common patterns I’ve observed across several SAFe implementations that have helped those involved in the implementation remain effective after they have been left wondering where they fit.
I’m hoping it will help others who have been in touch with me who are trying to understand what it means to be a practitioner in their newly formed SAFe organisation.
Several projects I am working on within my organisation are adopting SAFe in order to build software solutions, so I thought I should perform some SAFe testing!
With my Agile background, I am able to provide a lot of value in helping the teams follow an iterative development lifecycle (predominantly Scrum), but I have little experience of processes outside of the development teams themselves.
I also seem to struggle to get my message across to senior stakeholders within my organisation who are new to Agile & SAFe.
I’ve been studying Don Reinertsen‘s work on product development flow for some time. Whilst I talk about the ideas from a testing perspective, I’ve never actually attempted to get my thoughts on to paper.
I’m attending Don’s workshop on flow in Cambridge at the end of September, so I’m using this post to record my current thoughts so I can use them for reflection after the course.
I typically use the metaphor of an orchestra with Testers across different teams/products/squads within an organisation to help the understanding of how different testers can offer value within their teams.
The idea being that the argument “I test websites & they test data” is redundant when you’re thinking of the product or system as a whole
This idea started out as a doodle during Richard Bradshaw’s MEWT talk & thanks to Del Dewar, it became a “thing”.
In Richard’s talk, he rightly pointed out that the ice cream in the ice cream cone anti-pattern of test automation only sits on top of the cone.
In this post, I relate Richard’s fledgeling model to that of Bach & Bolton’s idea that Testers are the headlights of a project, purposely shining the light so that others do not have to work in the dark.
This is the 2nd post in my series on Truth. It builds on the first post by hopefully demonstrating how my opinions on truth & “Living Documentation” have changed after some research into what is truth.
This research was done in preparation for the fabulous MEWT conference. Here is a link for the slides of my “Single Source Of Truth Is A Lie” talk – this post aims to follow the structure of that talk.
One of the advantages of being part of the ISST is the fantastic opportunity to dig into topics & ideas with a community of critical thinkers. There is nothing like a good Skype IM chat to sharpen your own thoughts & beliefs!
The other day, the topic of “single source of truth” arose. Who had heard of it? Is it actually a thing?
For me, it is. Or at least it was. My beliefs have been challenged & now I’m rethinking what I have previously thought to be true.
This post was written immediately after that chat and is my way of trying to get straight in my head the conversation I had around “single source of truth” and what that phrase actually means.