I just love this quote. It shows us our unchanging ways and how we stick to something for the sake of sticking to it and after careful consideration we might find that something that held true for years and which we either liked or came to depend on is no longer relevant.
This is maybe the biggest challenge I find as a leader, to continuously challenge the process and to refine it, redefine the reason and to improve on it.
In my team we continuously investigate all processes and try to either improve on them or at least see whether they still hold true or whether we are just doing them for some legacy reason. Processes are only relevant if they still hold true.
Here is an example of our revision when it comes to tracking development work and bugs.
“We need prisoners to interrogate, and that tends to work best when they're alive”
As with prisoners you also need to keep bugs in a location so that they don’t “escape” and cause mayhem. We I took over the department, bugs was handled in a spreadsheet that was mailed around and everyone could do one, add one and it was expected that every developer would test his own bugs / work and bugs was only reported and added to the sheet after the publish was made to the client. This means that most of the bugs were reported by the client. (Not so good)
I started looking at the process and it was very inefficient and costly. Sometimes the same bug would be fixed by two developers, communication on the process and progress was shoddy and we often had recurring issues.
The process was insufficient
The first step we took was to centralize the logging, progress tracking and assignment of bugs by creating a system we call “Devlog”. This meant that all bugs was hosted in a databases and that developers would only do the bugs that was assigned to them or in some cases where the developers were faster than I could allocate work they could claim bugs. This tool has now evolved to where it helps with overall planning and resource allocation.
This process seemed to work really well: in the beginning. Soon loop holes appeared and bugs would still be recognized too late or developers would not test their own work properly.
The process was better, but had loopholes
I soon realized, as a developer, I would test around the conditions that made the software work and users tested a completely different way. Since there was no way I could sufficiently do Hallway testing I decided to hire someone to do my QA (see our blog on QA). So my Quality assurance department was born. Rules were wrote up, reports styled and we would soon dedicate time for every developer to give their work QA for testing, and we would allocate time before any release for testing and bug fixing. This meant that most bugs were reported internally and the client would never see 90 % of the issues instead of reporting 90 % of the issues.
The process delivers results
Soon we had less bugs, better turnaround time, and due to the QA reports being official and used in every developer’s revue we had less bugs and software that was developed faster and better than ever before.
“The Code is more like guidelines, really”
Although this is a small part of our entire development process and even our current QA process, it is a critical one and we continuously look to giants like Microsoft, Apple and Google to see what they do differently and how we could take their processes and apply them to our business. Taking into consideration that we don’t have Google type budgets, man power or timelines there always seem to be some tweaking to a process to get it to work for us, but it does help us to see that one fact holds true. Even though a process might be sufficient today, it can always be optimized tomorrow.
Visit the QBCon website.
No comments:
Post a Comment