I’ve been remiss in posting since I’ve been back in Seattle. Readjusting to life in the states, and adjusting to the new role has kept me busy. I hope to rectify that in the future. I have been lucky enough to be invited to speak several times this winter and spring in the US and Europe. If you’ll be there or live nearby and want to meet up, drop me a line on twitter and let me know!
It was great speaking in Seattle once again. This is an updated version of my earlier talk on failure. Failure is critical to innovation. So if you need to fail to innovate, how can you fail in a safe way?
Let me start out with the understanding that the article as written is being interpreted through the writer’s own biases and background. I certainly have been misquoted or had a radically different interpretation of my words by an author than was meant.
This is a response to the article as written. I would be happy for someone from Yahoo to let me know if they feel the article was an accurate depiction or not.
Yahoo’s new approach to quality is something many other companies already do
What yahoo learned is what many other companies have learned a long time ago. That segmenting test and development is a bad idea. It leads to developers and testers living in their own silos and playing a blame game on each other. Agile methodologies challenged this idea 16 years ago. Having separate test and development teams is a pretty big red flag for waterfall development.
It wasn’t the fact that there were QA that was the problem
Taking away QA can improve quality to a point because it makes quality everyone’s job, but it won’t get you a high-quality product. You could do that by creating a culture of quality, making everyone feel responsible for quality and keeping the QAs on the teams. You can’t find every bug in the product through test automation. Developers tend to be poor testers of their own code, because they expect it to work and they have a hard time using the product like a non-developer. Having someone on the team with an expertise in quality thinking and a user mindset can do real wonders for product quality.
What Yahoo should try next in their quality evolution
Yahoo could also have increased quality and velocity substantially by keeping the QA, integrating the teams of developers and testers and by creating a culture where everyone feels responsible for the quality of the product. I contend that in their evolution they might yet find another factor increase in these by doing exactly that.
As you grow as a developer (and development leader) and you work with more and more technologies over time in different projects, you start to realize how easy it is for the team to get more focused on the challenging technical problems than the actual product issues. Ignoring the product issues will kill the product (and possibly the company). With limited attention (he calls them innovation credits), it is best to put your effort into innovations that can differentiate your product. All too often, teams get more focused on the next cool technologies, turning everything into a nail as the old saying goes.
Dan McKinley does a great job explaining this in his talk below.
This was my talk at the Daho.am conference. Listening back to it now, I am struck by how often I said “many, many.” And I cursed! I usually try not to do that. So, it’s a bit of a looser take on this presentation. Luckily the audience had beer (this was in Bavaria, after all), so all were fine with it. I had flown in from Stockholm that morning, so I might have been a bit more tired than I thought…
I was really impressed by the lineup of speakers and the content of the presentations. A really good day. The Stylight engineering and event teams did a great job.
The organizers of Spark the Change in London asked me to speak about the Spotify matrix model. I was only too happy to comply. It was a great conference, and I met a ton of good people. As usual, I tend to talk to my slides, as opposed to putting a ton of text on them. Hopefully, you can still get something useful from it.