***** — my bullet proven dev process does not work anymore.

Quality. Quality is given and just needs to be done.

I work in software development.

**** they know!

Quality has a giant price and is hard earned money. Really. I delivered marketing related hire’n-fire projects to Adidas. Or FB-apps to Mercedes. Or large online campaign sites to BASF. We never had a quality issue.

Then I hired with Sherpany. My first ever real product business. And here I got bumped. Bugs, millions of bugs, serious bugs, large bugs, unfixable bugs and a giant mess of small annoying problems. Damn! I could not believe it, nor I could believe that my proven dev process created them. Hell no!

Yes, it did.

I did hold up the fights for my approach for 2 years, but then it was intollerably clear. My dev process did not work for the quality we need to deliver and for the customers expectations. Nestle, Novartis, Swiss* etc. too many details which were not working. We had to change.

I was honestly afraid of what was yet to come, if you have something working in IT (not only the computers, but also the teams) — the old rule applies: “ never change a running system”. That system was not running anymore.

Hence, we did: a) announce that we will go for a new dev process, b) we changed the most obvious problem to the dev teams: the merging and branching approach from team/sprint based branches to ticket based branches. What a nightmare, merge conflicts, failed merges, branching based on the wrong branch, incidential merges into not yet ready develop branch… hell, that was not going well for at least 4 weeks, then we learned what broke those things, we learned where to be disciplined. at least the branching started working. c) with the new branching we realised, hey, we can deploy faster now. let’s do that. someone sent a picture around for the CEO: the deploy-me button. we did: talk on monday what tix might be ready for release, test those tix a week, decide the monday after what tix made it, then we deployed that on wednesday while working on the tix for the next wednesdays release already. that worked. Not bad. headquarter said they loved the weekly releases, tons of small stuff just sent out more frequently. seems like that this raises the perceived performance of the team. good, bought! d) we learned end of last year, the best sprint was the sprint we extensively prepared. let’s try again: we discuss specs, team prepares their changes en detail(!) for all classes, files, methods, vars ON PAPER! no coding permitted, bevore I approved the approach. and yes, we tried it again, and yes, it worked again. result was good, result was working. e) we got larger features to do then what would fit into a weekly release cycle, we broke them down into small changes which were isolated already working for the user and now were sending these small things to prod every week. if that works, is not yet clear, needs more time. f) we did a bi-weekly bounce review meeting. initial problem driving this, was the QA test effort on the project managers and product managers side. as we’re not working with any QA staff, they (those who know most about the product) were really spending > 90% of their time checking and controlling. that needed to change, they should focus on developing the product and managing the team, requirements and deliveries and communication. therefore goal of the new dev process must be: product manager only just a few hours of rough testing per week, product manager max 30% of the time available. in the bounce review meetings, we just collected the top obvious bounces and discussed the sources of the failure and decided for actions. once we had max 3 actions (things to change) we just stopped the meeting, knowing more would not be changeable in the next 2 weeks anyway. so we kept adjusting (on developer side only) the way we worked.

underlying idea and approach is that when there is a quality problem you can do two things: either hire QA staff (hence money, structure, resources will be invested) or trace down the sources and start fighting it. the former is surely the more easier approach, the second one definitely more challenging. we went for the second, but I’m not sure yet, if we still have to turn for the first approach.

Finally at this moment of time, I cannot say that the new process works, but I have the impression that it already works better, then the old one. Hence, we need to keep going. I will update here occassionally.

And at the end, I have one more personal learning to share. As a developer I hate one thing. QA. I hate it. And I’m not good at it. Therefore, going the approach that we wanted to eliminate the sources of failure, I was considering that developers should in-depth check each others stuff, but I never raised that issue, because I honestly believed, that noone would like it and it will just die the moment it was spoken to the world. Means, after a single tix is done, three(!) other dev team member will check the result in all aspects.

Then, at one of the bounce review meeting, by whatever gods intention, it went over my lips. And what happened, was fully unclear to me. The team just said, yes! let’s do it. I don’t know why but I already see that it made a great difference in our QA and that only my anxiety was blocking me to talk about this earlier. Honestly, I’m very proud of that team and their commitment and preset-free attitude to make things happen.