One of the things I've really been enjoying about my job here at Kroll is how we're structured to run software development projects. As I interviewed here, I made it a point to give examples of projects I'd been involved in that had come in on time and on budget. Because, in general, I had found at my old place that that was an exceptional result.
Not so in my new work life. There is a dedication to process and excellence in work output that I've not previously encountered in my career in IT and software development. Granted, points of brilliance can always generate good results, but here it's wired in. If I bring a project in on time and on budget, it's not all that exceptional really. The system drives the result.
However, in some ways my role here as a development manager is a little different from some of the other development managers here. Our team is charged with developing an internal tool that can respond quickly to changing needs. To do that, we've done some hybridizing of the Kroll OnTrack software process. We shorten our cycles and work with more of an agile mindset, although to be fair, we're not actually following the agile process to the letter.
How is it different and better?
A lot of companies understand the need to do requirement gathering. Some even do it adequately. The role of the testing here, I think, is the critical component that most companies miss. Testing is something a lot of companies have their developers do, or their end users. It's a mistake.
Developers who test their code, test their code for mistakes that they expect. The inputs they don't expect and haven't coded for aren't going to be tested. If they had expected the input, they would have already coded for it. Sure, developers should test their code, but it's only going to scratch the surface on how your users will actually use the application.
End users, in general, make lousy testers. A couple of reasons for that. One, they already have a day job to do. Running multiple scenarios through your test system isn't on their list of important things to do today. They are much more likely to not even test some of the things you need tested until it's in production. By then, it's a fire drill to fix it, AND you have the added publicity of a bad launch.
Having a dedicated group of testers who work with your development team to unit test the application code, build test cases, and develop user scenarios catches bugs early in the process. They can be fixed as part of the normal development cycle and then released working and whole to your end users.
The problem is that it's not always easy for the people who manage your budgets to understand the value. But that's a subject for another entry.
Posts
