I would like to expose a team which merged continuous integration and continuous deployment with scrum cadences.

Review of Scrummy Things

Here is a little refresher on what texbook scrum cadence looks like (it pays to be the daughter of Judy Neher, CST)

I have greyed out the scrum cadences which are affected by continuous working habits. I will touch on each of these.

Review of Continuous Things

It is important to understand some definitions before we begin…

Continuous Integration

This can best be described by what it is not. It is not the situation where a developer disappears for two weeks, and reappears with an entire feature's worth of code. In contrast, continuous integration is the process by which you commit small, often, and visibly (a.k.a. dogpile on master).

Continuous Delivery

This is the process by which you only ever write production-ready code.

Continuous Deployment

Code, once pushed, follows a continuous path to the production environment.

My team does all of these things. For the purpose of this post, I am aggregating all of these into the term continuous development.

The Product Vision

Scrum relies on a thing called “the vision”. This thing is what the team hopes to make. Stakeholders create a road map to this vision, and the team product owner breaks it into manageable chunks. Those chunks take the form of the team’s backlog items.

Continuous development hijacks this solid vision and turns it fluid. The catalyst for this melting process is the quick feedback loop born of continuous development. When the time between feedback from a product owner’s mouth to production is under an hour, things like requirements become more fluid than rigid, provided the developer has a constant dialog with the product owner.

As a wonderful consequence of that quick feedback cycle, stakeholders are able to see and poke through things that are still in development, assuming the project has some sort of toggling infrastructure for unfinished features. Stakeholders are able to take this information, talk to customers, and formulate new features based on the feedback they receive. As a result, the overall vision is constantly adapting to meet the needs of the customer.

Planning Sprint Boundaries

Disclaimer: This particular output of continuous development will likely depend on the team’s stakeholders. As it happens, my team is blessed with very understanding clients.

Continuousness is a funny thing when you try to bind it to sprint boundaries. The team will find itself in one of two situations, either (1) the team is working ahead of schedule and will pull in things from the following sprint or (2) the team is behind schedule and the in progress backlog items will roll over to next sprint.

Rarely there are any complaints about the first case, save the product owner, who might have to work a little faster at filling the backlog.

In the second case, let’s say by the end of the sprint an item is 90% developed. Sprint boundaries use an unforgiving binary: either the work is done, or it isn’t. This doesn’t highlight the item’s 90% value added because it is already being tested, viewed by stakeholders, and shown to beta users for feedback.

Conflating the scrum need for commitments with development’s need to remain fluid, my team chose to lock down Potentially Shippable Increment (1 PSI = 4 sprints) commitments instead of locking down sprint commitments. We commit to demoable items at the PSI level, and as a result, only have difficult conversations with stakeholders if the PSI is in jeopardy. The sprint boundaries then become a safe time for developers to pull or push items as necessary.

Product Increment Reviews

Continuous development strips away any cadence you may have on reviewing the team’s potentially shippable products. Deploying changes frequently provides the product owner the opportunity to constantly view, review, and provide feedback on items in development. The developer will be sucked into this cycle of addressing product owner reviews and recycling them.

By the time the item gets to any scrum “review” cadence, it has been reviewed and re-reviewed by the product owner many times. Since the developer is intimately involved with this process, the review would be a quick thumbs up. You don’t need to book a room for a thumbs up.

Conclusion

Continuous development and scrum actually work really well together. Combining both practices demands a bit of creativity, however.