How do you choose the right agile methodology for your team to meet your business objectives? Read Part I of our two-part blog about agile methodologies for a Continuous Delivery solution.

So your project is kicking off, and someone says “Quick, set up a Jira board for this project ….” So you open Jira, click on “New Project” and low and behold you are asked what type of project you want:  Kanban, SCRUM, Agility, Basic … and the list goes on.

The truth of the matter is that this decision needs to be made long before launching the Jira app, and should be made with the team. It’s a function of how the team is structured and how the business will operate.

If we are doing a SCRUM project, i.e we have a set of user stories, a groomed backlog, two weekly development sprints with showcases, and regular deployments, SCRUM is a great choice.

If you are doing more of a continuous delivery (CD) project, with deployments into production daily (or multiple times per day), is SCRUM the right agile methodology choice any more? SCRUM starts to fall down with continuous delivery projects – it no longer makes sense to have an end of sprint showcase to the product owner, demoing recently developed functionality, if it was deployed to production last week. Users would have been using it and providing feedback on what they think about it for over a week already.  CD projects are frequently much more suited to a Kanban style or BAU (Business as usual) flow – where features are identified, specified, designed, built and delivered in more of a continuous flow, rather than in batches we call sprints.

So what is the difference between SCRUM and Kanban? Let’s start with a simplified SCRUM process:

• The product owner or business analyst will create a user story/feature
• The story/feature will be expanded with some design and some acceptance criteria (grooming backlog)
• The story/feature will be put into the backlog and the priority agreed between the team and the product owner (taking into account complexity and dependencies) (backlog prioritization)
• The story will be sized and assigned to the sprint (sizing)
• The developer(s) will pick up the story/feature, review it in the sprint planning and if the story/feature is well understood with sufficient requirements, design etc, then it will be accepted into the sprint (sprint planning)
• The team will build the tests to meet the acceptance criteria
• The team will implement the feature so all tests pass (assuming automated testing)
• The team will showcase the feature to the product owner, including the test results- who will be ecstatic by the results and the story/feature will be included in the next release
• The team will have a retrospective, learn from difficulties, celebrate success and begin planning the next sprint ….

Yes, this is a simplified view of SCRUM,  but this needs to be kept quite short…

Let’s now consider a Kanban scenario – and in this case, I am describing what I have used and know to work, not what is typically defined as Kanban with only 3 states (ToDo, In progress, Done). I typically have many more states to provide visibility to the team and the business as to what is happening:

• The product owner or BA will create a ticket for a feature (using the story structure for tickets can be helpful when specifying requirements but not mandatory as in SCRUM)
• The feature will be put on the requirements backlog (needing to be reviewed, and high-level design work to be carried out)
• The feature will be expanded with design and acceptance criteria and moved on to the “requirements complete” state
• The tickets are also sided at this point by the team, allowing the product owner to make an informed decision when putting in the work queue
• The feature will then be able to be moved to the “Selected for development” state and put in the work queue in the appropriate place.
• Developers then select the next ticket from the “Selected for development” queue and start work on this. Note, if there is nothing in this state/queue, the developers should not be randomly selecting tickets from the board, because it is the product owners responsibility (supported by project management and business analysts) to ensure there are tasks ready for the team to work on. If the queue is empty, it means the business does not want any changes at the moment (there may be a legitimate reason for this)
• When development is complete, including all acceptance criteria passing the automated tests and checked by the QA representative, the ticket can be moved to the “Complete” state
• The “Scheduled for deployment” state is not always needed, but is a useful mechanism for indicating the product owner is ready for the feature to be released – this is typically the signal to merge the code into the master branch.
• As the deployment is completed, the ticket is moved to the “Deployed” – this is a useful state to see what was recently deployed, usually after a short period like 24-48 hours tickets can be moved to the Done state – but this is useful for the team and the business (and the support team) to see what has been recently deployed.

NOTE: There is no showcase of “completed features” prior to the code being deployed, as the feature is completed, it continues to move toward deployment.

I might need to explain this, my Kanban board is in effect two Kanban boards in one. The first is to manage the flow of requirements to the point where there is enough requirements to begin the development (including high-level design and sizing by the team). This stops a huge amount of time being lost/wasted by developers picking up and starting tickets that are not sufficiently complete or thought through to be worked on. The second half of the board is the developer’s board, that has tickets ready to be worked on (the groomed backlog in SCRUM) and the work in progress states.

Another thing to note around continuous delivery approaches (and by extension the Kanban process) is it almost always requires fully automated testing to be in place because releases are always being made as soon as a ticket is completed. This also means every feature should be implemented using feature toggles. There would need to be a very considered reason why a feature was not being implemented using a feature toggle in a continuous delivery methodology.

The requirements sub-board

New Features	Working on requirements	On hold, Needs more analysis	Requirements complete	Selected for development

The development board

In Progress	Complete	Scheduled for deployment	Deployed	Done

Read Part II of ‘What Agile Methodology to use for Continuous Delivery’ here, to find out about how to move beyond structure to examine the rituals for a successful team or digital delivery.

By Nick Langstone, Software Development Manager at ClearPoint.