Long running un-releasable work and sprints that always map to release

Before this, we had a two-week release cycle (a new version is deployed that customers can actually use). 

What challenges did this approach have which made your organization decide to use Scrum?

It has smaller pieces we can call as complete

Can it be moved to Production without causing any issue to what already exists? If it can be released, can it help you get feedback? If yes, then why don't you release?

What challenges did this approach have which made your organization decide to use Scrum?

We are looking to get better at forecasting. We are looking to benefit from some of the data we get if we just follow scrum to build certain predictability in our roadmap.

Can it be moved to Production without causing any issue to what already exists? If it can be released, can it help you get feedback? If yes, then why don't you release?

No, we can't release as this has breaking changes. Some new features come in and compatibility for some of the old features is pending implementation. If we don't feel constrained by scrum, we feel that for this specific problem, this is the better way to architect this.



After posting this, I realized that we can handle these two different kinds of tasks in two different projects. One project that focuses on true deliverables into release. The second one that just focuses on incremental progress on certain items. Both of them can be taken into the sprint and we can manage that. The two projects would have two different kinds of workflows in Jira to deal with the different nature of issue progress.

How do we bring such work into agile?

Each Sprint is a learning experiment, and an opportunity to apply empirical process control. Decide what you want to learn that Sprint, so product value can then be maximized.

If, prior to Scrum, you had the capability to release every 2 weeks, you shouldn't be losing that capability with enacting Scrum. The added events - the Daily Scrum, the Sprint Planning, the Sprint Review, the Sprint Retrospective - may require you to rethink your capacity for work. Likewise, the agile value of working at a sustainable pace, if that's something that you didn't have before, may drive you to rethink how much work is put into that 2 week increment. But rethinking the amount of changes in the product shouldn't stop you from going from idea to delivery in that cadence.

The flexibility of not releasing comes for a number of reasons. Allow me to tell two stories.

The first story is of when I worked in aerospace. We can't release software to end users every 2 weeks, or even every month. The systems I worked on were hardware/software systems. Software had to be installed onto custom hardware that was manufactured on-site. Rather than delivering to end users, we delivered to an integration team which took the software (which was well-tested on simulators) and hardware (which was robustly modeled and then inspected after manufacturing) and integrated the two pieces together. They were able to perform integration tests on the system in a lab and see if we've made the system better. However, in order to be put onto an aircraft, it would need to be sent to the aircraft ground test facility, be tested by the aircraft integrator, then undergo a series of flight tests, and then be rolled out to in-service aircraft. That is a costly effort. However, if they had ground and flight testing scheduled for another purpose, having software that was only a few weeks old with improvements let us piggyback onto other tests, where it was appropriate. The ability to have fresh builds of software frequently is valuable since it lets downstream stakeholders accept it at their convenience.

The second story is from supporting pharmaceutical clients with a SaaS web application. By using feature toggles and keystone interfaces, we are able to hide functionality. First, the functionality can be totally unavailable in production, yet turned on in pre-production environments. This lets clients who are interested in the functionality turn it on, explore it, and give feedback as we're building it. However, even when we're done, they may not be able to use it right away. Depending on what the functionality is and how it impacts their business processes, the client may need to perform user acceptance testing and validation. When the feature is done, we can let them know and give them an environment in which to perform UAT and validation and capture the information that they need to satisfy regulators. However, since internal users and then select external users have been seeing it in demo and pre-production environments, we have a high level of confidence that the stuff that we built would be acceptable to them. Once their validation was complete, the feature flags can be turned on in production and they have a new capability. However, customers that don't want it or can't yet validate it can leave it off.

In both cases, following the model of Scrum provides advantages. Having rapid feedback cycles, even if it's from internal integration and test users or from people exploring in a pre-production environment, is extremely beneficial. These are the inherent problems that agility tries to solve. In environments where there are a lot of unknowns and up-front planning doesn't add much value, finding techniques to be able to deliver an improved product on a rapid cycle can make sure that you're spending time building the thing right and building the right thing.

Thanks, everyone. I think I have some clarity on the topic now. We can take best of both worlds