Dan Ashby enquired on Twitter for information on the balance between the Cost of Delay vs the Cost of Poor Quality.
My immediate thought was that this a false dichotomy, its comparing apples with oranges.
Cost of Delay is a comparatively bounded context, whereas Cost of Poor Quality has so many facets I’m not sure how you could draw a boundary around it.
I was going to tweet Dan some links, but the question has piqued my interest so l’m going to attempt to answer it here 🙂
Has anyone seen any research or investigation into the balance between the cost of delay vs the cost of poor quality?
(I’m assuming there must be some research, since this would be extremely valuable in answering that challenging question so “good enough”…?)
Before Covid struck, I was supporting an offsite manufacturing startup with their software product development.
The startup needed software to help optimise their manufacturing process of modular homes built with Cross Laminated Timber (CLT).
This post outlines how the 3 of us in the software team designed & built a no-code solution for capturing replenishment requests from the factory operatives in order to keep them doing what they do well – manufacturing.
I’ve spoken in previous posts about how at my previous customer I was working with non-software development teams, helping them interface with the development teams in order to increase collaboration.
A fantastic side effect of this coaching was that the non-software teams recognised the importance of having cross-discipline teams being aligned around value delivery, rather than in their specialist silos.
This post outlines an experiment where we created a cross-discipline team, focused on delivering an FS marketing strategy without changing the organisational structure.
In my previous post, I spoke about how I was embedded as an Agile Tester in a team delivering Financial Services (FS) improvements to an ecommerce website.
This post builds on that experience by talking about my time there as an Agile Coach working with several FS teams helping them not only to interface with Agile development teams, but also increase agility in their own working practices.
I often use a pithy phrase I picked up from Michael Bolton many moons ago (which he himself picked up from David Platt author of Why Software Sucks) to help people understand the relationship between software quality & it’s users / customers
I’ve been using it a lot recently, so thought I’d share it here
Here in the UK we’re in the middle of campaign fever as we have a General Election on the 12th of December.
Its pretty important election, with some big topics being used as political weapons so I’m currently trying to gather as much knowledge as I can in order to make an informed decision on who to vote for.
This post is about how i’m applying the critical thinking skills & tactics I use in my day job to test claims made by politcal parties.
Heads up, I won’t be sharing my political views in this post.
*Until you understand the challenges preventing you from collapsing the process into To Do | Doing | Done
I’m a big advocate of collapsing columns on your Scrum / Kanban / Story board from the classic In Analysis / Analysis Done, In Dev / Dev done & In Test/ Test Done (yes, this is a waterfall process on a wall) to To Do | Doing | Done.
There are many reasons why To Do | Doing | Done is more suited to iterative & incremental development – Jit Gosai does a great job of calling out some of the benefits in his “In Test Column” post.
This post is focused on the When & How of collapsing the number of columns on your board.
One of the biggest challenges I typically face when joining a development team is understanding the silo between programmers & testers (& other team members).
I approach this challenge by referring to both roles with the generic term of “Developer”, whilst using “Programmer” & “Tester” to differentiate between the roles when required.
I use the term “Developer” as we are both helping to develop software. I believe I got the analogy of eating from Michael Bolton – you can’t keep stuffing food in your mouth (programming) without swallowing (testing).
This post builds on that idea to share how I use the fire triangle as a metaphor for activities & roles that play a part in software development.
In my previous post on followership, I talked through how it came onto my radar & ideas for being a good follower.
I also discussed how the term is more nuanced than I first gave it credit for. As I dug deeper into the topic, I started honing in on those areas of my life where I was a follower or actually some form of leader & how I felt about each of those relationships.
This post outlines how I used various models to help me understand where on the scale between followership & leadership I was for various aspects of my life.
The working title of this post was “Followership – because sometimes leadership can go f*ck itself”.
This sentiment seemed to sum up where my head was at after a challenging role which left me taking stock of what I wanted from a career & my life / work balance. I retreated back to my comfort zone to let someone else do the leading.
You may be able to tell, in my funk I was seeing the term “followership” in a negative light. After studying the topic further I started uncovering the importance of followers & the related skills of following.