Rooosterboys Agile observations

I've been speaking to people, recruiters especially about what I do as 'Global Head of Quality' at iflix. Today, I hammered out a reply in a chat, it went something like: I have worked with QA teams both here and in India. However I try to focus on building quality into all stages of the product development cycle . The QA teams I've worked with started off being post-development testing teams, focusing on regression testing applications built by teams prior to pushing code to production. My goal has been to reduce the number of stand-alone QA's, not increase them. To embed good agile practices across the organisation and identify and eliminate any 'over the wall' behaviour the engineering teams have. If the organisation has a 'stand-alone' QA team, and a long post-engineering testing cycle, they are doing software WRONG! QA as a standalone practise is actually a common sign of waste in software engineering, so eliminating waste should be every &#

In start ups, getting your idea out there and used by your customers as quickly as possible is sometimes THE most important thing. However, at some point, your product, hopefully, becomes successful and ignoring code quality can come back to bite you. I speak about this topic purely as an observer, not having been in the coding game for a long time now (apart from a bit of haggling with wordpress php but I’m told that doesn’t count ;) ). These are some of my observations from being a mediator between the ‘do it fast’, &  ‘do it right’ crowds. I’ve lost count of the number of times I’ve heard someone say “Don’t worry, this is throwaway code, we’ll do it right next time”. That code is still out there, sometimes doing very well but giving engineers headaches every time they work in it. The balancing act then is between the rush to market and the maintainability of your product years down the line. I’ve seen the impact of rushed code on productivity in a number of places I’ve w

Another question for the #agile crew out there. I have conversations with senior engineers a lot, often people relatively new to agile. A question I am often asked is "How does architecture work in an agile environment?" I notice some discomfort with not knowing, and fear of things like scalability, security etc being forgotten in an emergent architecture approach. I was looking around the internet for inspiration, stumbled across this thread: http://softwareengineering.stackexchange.com/questions/165971/how-is-architectural-design-done-in-an-agile-environment There are some good thoughts in here, like: "take the decision at the last possible responsible moment - meaning its fine if you haven't taken all the decisions at the beginning of the project, especially since you have least information at this stage. Over time, you may take decisions that "evolve" the architecture" I particularly like the idea that the team be given as much responsibi

Yesterday, I was watching a documentary on the "Battle of the bulge" A famous battle in World war 2. The docu makers were investigating German tactics during the battle. Specifically, tactics which had worked so well early in the war, over extended periods of time, towards the end of the war, fell apart after 3-5 days. Early in the war, German officers had Mission Command, that is, Hitler and high command had high trust in their teams. As the war went on, and things started to go wrong, mission command was gradually eroded as trust fell (especially when his officers tried to kill him). Mission command basically means, set the goal, let the teams be responsible for how they are carried out. Training is centred around this, discipline and training carry you through the unexpected, as long as you know the end goal. Effectively, the German high command no longer trusted the lower ranks, and only gave them enough information, goals etc for the immediate goals and set them