Last week Åsa, a colleague at Steria Sundsvall, had a link to a great article by Kelly Waters: 3 Reasons Why I Wouldn’t Do Agile Software Development.
…
There are some circumstances where an organisation’s culture is possibly too different to successfully adopt agile. At the moment I can think of only 3 reasons why I wouldn’t do agile software development:
1. If I was working for an organisation that believed it needed complete clarity about a solution before it could start a project. I believe this is a false positive, and it would be very hard to adopt agile in an environment where key stakeholders insist on this.
2. If I was working for an organisation where the relevant product owners couldn’t – or wouldn’t – commit to being actively involved throughout the project. I really do believe that active user involvement is the first principle of agile, and imperative for a project to succeed.
3. If I was working with a team that I didn’t believe could cope with ambiguity, or didn’t have sufficient communication skills to collaborate effectively with business colleagues or customers.
…
This week I hit number 1. The past 2,5 months I’ve been working at Statens Pensjonkasse in Oslo Norway.
From now on the team I’m in will be completely responsible for the production and delivery of new maintenance releases of the main application used by SPK. We went through the process of producing, testing and delivering the next version and something very interesting came up…
A complete new version of the application (front, middle and back-end) is being made by another group – a quite large group where Steria Norway is also involved – using Adobe Flex and Java. The project is called Perform and uses modern technologies and techniques, Scrum among others.
When we took over maintenance of SPK’s current system, they gave an introduction course to Scrum and said it was up to us if we wanted to maintain their application using waterfall or Scrum. As an agile evangelist and ScrumMaster I of course felt the urge to choose Scrum, but was that right?
Until now the entire maintenance period had been quite ad-hoc with lots of Service Desk issues coming in and ad-hoc solutions being needed. (But that’s another story…) This meant there was no real opportunity to think about the development process. But now that we’re taking over as maintenance release team and need to plan more ahead, I had assumed we’d go Scrum. That however, seems quite impossible, even quite unsuitable.
The way new releases are prepared is quite glued to the waterfall development process that has been used until now and as we see it, that cannot be changed. Yet. (I’m not giving up hope.) The customer first gives us a list of open issues that need to be a part of the next release, we estimate the time required, they approve, we build. Then the testing starts… Testing is done in at least 2 phases, system test and acceptance test. We learned that both are done manually and that they’re identical. During the system test phase a person manually goes through all the tests, if all tests pass someone goes through all the tests again but calls it acceptance phase. This hair raising principle is the main reason for not being able to apply Scrum, since it cannt be changed. It may be possible to change it later, but that might take a year and this version of the application is planned to be superseded by Perform in a few years, so it doesn’t really feel like it’s worth the struggle. Just for the experience and sake of Scrum I should try, but probably won’t.
The reason the production and testing procedures are as is, is because of how the application has designed and written. Almost all of the functional code is written in C and embedded SQL. C is hard to fit into Continuous Integration and the embedded SQL is so complex that we dare not even think about mocking/simulation or automation. (A typical SQL task runs for at least 10 hours before any results/errors can be seen.) Even if we did manage to rewrite the code so it was testable with CI, the environment the building (make, nmake) run in and the application environment are so hard-coded that it would take weeks to make it more modular and portable (with portable I mean being able to build and run anywhere without breaking dependencies). (The windows client build process has dependencies that are only built in the Unix server process, but that discussion is off-topic.)
It is quite a shame, but Scrum is not the way to go this time. At least we’ll be able to use Scrum internally while implementing the next release, since Agile/Scrum can always be applied within a waterfall (or other) wrapping.