What Agile Methodology to use for Continuous Delivery? Part II

In part II of ‘What Agile Methodology to use for Continuous Delivery?”, you can read about how to move beyond structure to examine the rituals for a successful team or digital delivery.

When following a Kanban or CD approach, what happens with demos and showcases?

These are hugely valuable and a great way to get early feedback. There are several options, one is to demo from a branch prior to merging – typically in the Complete or Scheduled for deployment states. The other is to use feature toggles, and to deploy the code to production, and to demo to the business in production. This requires a very mature testing and design approach, to ensure what is implemented can operate safely in the production context from day one. In either case, demos are a good thing and should be encouraged. For Kanban and CD approaches, weekly, short, sharp demos and reviews of work done and work planned can be very effective.

The other thing sometimes skipped from Kanban methodologies are planning and retrospective sessions. Many of the rituals from SCRUM are hugely valuable in any agile delivery context. Regular planning and retrospective sessions (2 weekly) are very valuable for the team to learn from what has been completed and to help the wider team see what is coming up.

Back to the original question – what methodology should we be using?

If we are doing fortnightly sprints, and regular release cycles, then SCRUM or FDD are great agile methodologies to use.

If we are doing continuous delivery, with releases daily (or even many releases each day), then Kanban can be very helpful.

If you are doing a waterfall project ….. well I won’t answer that here …..

The key here is an active decision is being made by the team to determine how they will operate as a unit (not an unconscious/passive decision making process). It is not good enough to assume everyone knows how the team will operate (we all know there are many definitions of SCRUM, and Agile and XYX Methodology). As a team, we need to come together and agree our terms (like the definition of Done in SCRUM) and agree the methodology that will be used to deliver the outcome the business is looking for.

Spotify has a great mantra “Rules are a good start….but break them when necessary”, it is useful to remember when determining what methodology to use. And it is also OK to vary the methodology – SCRUM is like a menu in a restaurant, offering a lot of options, and you would never eat every dish in a restaurant in one sitting – you pick and choose those that make sense for the situation. We should strive to make informed choices and communicate these choices and the reasons why these choices were made. And if/when things change, not be afraid to review these decisions and change them.

I have been on projects that started as a SCRUM project, then after the first few regular, scheduled, releases (MVP), we changed to Kanban and began delivering three times a week…. then daily. This was OK because this decision was actively made by the team and communicated across the wider business and we said why we made this change for the benefit of the company – which was being able to be more responsive and to get more effective feedback from our users.