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

Last post 01:20 pm August 6, 2020
by Pankaj Lal
5 replies
Author
Messages
03:16 pm August 5, 2020

We are moving to scrum. Before this, we had a two-week release cycle (a new version is deployed that customers can actually use). We are now moving to two-week sprints. Sprints give certain flexibility to not release, but we are not buying that idea. After all, what is the purpose of calling something complete, and yet not release it. We had certain process efficiency built into that and we want to continue with this. This is not my question though. This is just the context.

Besides the bi-weekly release cycle, we have some work that cannot be delivered in small chunks. It is technically quite involved and takes months. It has smaller pieces we can call as complete, but in the context of we want to release every two weeks, it is not that complete too. This work is going on at a great pace, it is transparent and everyone is in sync with how and why and how much to be done.

How do we bring such work into agile? Effectively, should all the work of 4 months be logged in that final two-week sprint cycle when it would eventually make it in? It looks very artificial to me.

03:32 pm August 5, 2020

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?

06:27 pm August 5, 2020

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.

07:37 pm August 5, 2020

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.

09:10 pm August 5, 2020

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.

01:20 pm August 6, 2020

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