One of the Agile manifesto's preferences is for people and collaboration over tools and processes. For example, having a 2 minute face-to-face conversation is preferred over sending an email. This is an admirable foundation for the philosophy, but what happens if the environment, technology or tools you must use on a project get in the way of collaborating and being agile?
My current project is customizing a Siebel installation as the organization's CRM solution, and so we have to deal with Siebel's technology. I have to admit i have never worked with this technology stack before, and so I am relying on the solution architect, team leaders etc for their views on this, which I respect.
The issue comes when it is time to deliver new code to the test environment. Development and unit testing happens in a separate dev environment, then released to the SIT testing environment for system testing. This is the first step in the delivery chain, so each release to SIT becomes part of a collated release to UAT, etc.
Releases can take the form of an SRF, a Repository update, Static data, Workflows, etc. The problem is that these releases are time consuming and have to be made under a release management process, which involves two other teams (release management, environments) and creating interim documentation (release notes). Because of this, releases cannot be ad-hoc or flexible, and have to be scheduled. This was exacerbated by the release and environment teams being unwilling to perform more than 2 releases per week.
Unfortunately, the team has morphed this into the need for a release plan - scheduling to finish user stories for a certain release date - and so a lot of planning day is consumed by trying to fit user stories into the release schedule so that a tester has enough time to test it. And what does that look like - mini waterfalls in a sprint!
This has some obvious (to me) drawbacks, in that a missed release date could delay a user story by two days! even for a 2 minute bug fix, so quick turns around times to improve through feedback were non-existent.
In terms of Scrum, it meant that the team were always focused on delivering to the release plan, rather than having the flexibility to deliver when ready (they were even admonished for delivering a story early, as it was not in the release plan!). Also, since no work could be delivered after the last release, there was a premature end to the sprint which increased the likely hood of stories 'carrying over' to the next sprint, against agile principles. It was estimated that around 10% of capacity was wasted because of waiting time or lost time.
Finally, I also had the impression that some of the team, including the release manager, were deliberately using this as an excuse not to be agile as they didn't want to change.
Unfortunately, in dealing with this situation, I had to wait until the release manager was replaced to get any movement in this area. When that happened, I immediately went to daily releases - which although not the ideal, helped a lot.
It meant that I could downplay the importance of the release schedule, and so get back to a more flexible approach to taking on and delivering work, and it meant that we could have releases up to the end of the sprint, so using all available capacity. I would have preferred to have dropped the idea of a release schedule completely, but this bit of team culture was ingrained pretty deep and the teams elected to keep it. Our new release manager also helped a lot, as her whole approach was one of helping to deliver, and being flexible but controlled.
The ideal situation of continuous integration is not always possible: The limitations of older technologies, together with old-style ways of working, can severely impede a team from realizing its full agile potential. But by approximating to CI, and having the will to be flexible, can improve the situation - we were able to reclaim the 10% capacity, and greatly improve the pressure on testing.
My current project is customizing a Siebel installation as the organization's CRM solution, and so we have to deal with Siebel's technology. I have to admit i have never worked with this technology stack before, and so I am relying on the solution architect, team leaders etc for their views on this, which I respect.
The issue comes when it is time to deliver new code to the test environment. Development and unit testing happens in a separate dev environment, then released to the SIT testing environment for system testing. This is the first step in the delivery chain, so each release to SIT becomes part of a collated release to UAT, etc.
Releases can take the form of an SRF, a Repository update, Static data, Workflows, etc. The problem is that these releases are time consuming and have to be made under a release management process, which involves two other teams (release management, environments) and creating interim documentation (release notes). Because of this, releases cannot be ad-hoc or flexible, and have to be scheduled. This was exacerbated by the release and environment teams being unwilling to perform more than 2 releases per week.
Unfortunately, the team has morphed this into the need for a release plan - scheduling to finish user stories for a certain release date - and so a lot of planning day is consumed by trying to fit user stories into the release schedule so that a tester has enough time to test it. And what does that look like - mini waterfalls in a sprint!
This has some obvious (to me) drawbacks, in that a missed release date could delay a user story by two days! even for a 2 minute bug fix, so quick turns around times to improve through feedback were non-existent.
In terms of Scrum, it meant that the team were always focused on delivering to the release plan, rather than having the flexibility to deliver when ready (they were even admonished for delivering a story early, as it was not in the release plan!). Also, since no work could be delivered after the last release, there was a premature end to the sprint which increased the likely hood of stories 'carrying over' to the next sprint, against agile principles. It was estimated that around 10% of capacity was wasted because of waiting time or lost time.
Finally, I also had the impression that some of the team, including the release manager, were deliberately using this as an excuse not to be agile as they didn't want to change.
Unfortunately, in dealing with this situation, I had to wait until the release manager was replaced to get any movement in this area. When that happened, I immediately went to daily releases - which although not the ideal, helped a lot.
It meant that I could downplay the importance of the release schedule, and so get back to a more flexible approach to taking on and delivering work, and it meant that we could have releases up to the end of the sprint, so using all available capacity. I would have preferred to have dropped the idea of a release schedule completely, but this bit of team culture was ingrained pretty deep and the teams elected to keep it. Our new release manager also helped a lot, as her whole approach was one of helping to deliver, and being flexible but controlled.
The ideal situation of continuous integration is not always possible: The limitations of older technologies, together with old-style ways of working, can severely impede a team from realizing its full agile potential. But by approximating to CI, and having the will to be flexible, can improve the situation - we were able to reclaim the 10% capacity, and greatly improve the pressure on testing.