I work for a small company (150 or so people) with a limited IT budget.  When I started with the organization, emergency releases would happen nearly every month with some happening twice or three times in a single month. We have gone over a year without an emergency release. This is a huge success and there are more than one change to bring it about. As the architect of the group, I am proud and very happy with the results of the changes.  Here are the key factors:

Requirements Gathering

We brought into the department a Business Analyst. This may seem like a huge investment for such a small company, but the person we brought into the process had worked in several departments within the organization. Intimate knowledge of business processes was the key to help us technical people understand in more depth what the business was asking the what fors and whys. This helped us produce what the business wanted versus what they asked for.

Improved Sprint Process

We limit the number of change tickets per department to two (more if another department has none) and never over commit. This may sound like it wouldn’t work in the real world but we are very successful in getting what the business needs completed in what they perceive as a reasonable time frame. Our old system was to commit to a huge number of items and complete a fraction of them with the business perception that we cannot get anything done. The pressure was high, the perceived failure was high and morale was low.  With the reduced workload, code quality is higher, satisfaction with work is better and the business sees the IT department as successful because we complete what we say we will.

Code Reviews

Code reviews were hard to get into the development process but the results are unquestionable. Every developer hates to code review, it takes away from coding time, it takes away from getting stuff done. The truth is, it makes coders more accountable, it catches bonehead mistakes before they end up in production, it helps with writing code that adheres with standards, it helps coders comply with the architecture of the application, it helps the coders know all of the code, it just helps. The time taken away from coding is well spent looking over new features and functionality with the eye on the prize: quality. Great code isn’t by accident, great code is crafted.

Definition of Done

One of the keys in scrum is the definition of done. To a coder, done might be when the code runs through unit or evaluation tests. To a business analyst, done is when the code is in test and appears to work as expected.  To the business, done is most often when the feature or fix is in production and can be used. Having all parties involved know what ‘Done’ means to the whole organization puts everyone on the same level of expectation. For us, a ticket is closed when it is validated in production.

I hope to have another year of no emergency releases. Improving the process of making software has been very beneficial to the organization and the customers we serve.