Going from dedicated project-funded efforts using Agile and Scrum methodologies, such as Sprint Planning, Backlog Refinement, Sprint Close Demos, etc., to a production support process leveraging the DevOps (Development and Operations) model requires a transition path to be successful.
People, Processes, and Technology need to shift along with this change in the Software Development Lifecycle (SDLC) mandated by management.
Commitment v. “Pulling from the Backlog” Mindset
Agile Teams Leveraging Scrum Ceremonies
At the foundation of Agile with the application of Scrum ceremonies is a commitment from the team and individuals on the team to implement User Stories within an agreed cadence, a Sprint (e.g., two weeks). The product owner and the implementation team articulate what is required to implement the story, produce a collective, relative effort estimate in the form of Story Points, and agree to complete the set of user stories within a given sprint cadence. For each user story, the “Definition of Done” is clearly articulated in the form of “Acceptance Criteria”, and this criteria is used as a guidepost for software development and quality assurance.
As an Agile, Scrum team, you may view your product backlog differently than you would in a DevOps, Development, and Operational model. Scrum teams are focused on the day-to-day work toward implementing user stories and making progress on user stories and Bugs to fulfill their commitments for the current Sprint. Scrum teams are typically focused on implementing work items or removing blockers and may discuss these activities each day during a Daily Scrum or “Daily Standup.”
DevOps – Pull from the Backlog
Unlike Scrum teams, who set up sessions to measure progress in a particular cadence, e.g., two-week sprints with Sprint Planning and Sprint Close sessions, DevOps team members pull from the backlog as their bandwidth becomes available. The [Business] Product Owner and the DevOps team may have some regular or ADHOC sessions for Backlog Grooming / Refinement to ensure the user stories are ready for implementation and prioritized appropriately.
The Product Owner and DevOps team periodically perform Backlog Refinement sessions to make sure the prioritized User Stories have all of the necessary elements to implement the user story. During these Product Backlog Refinement sessions, team members perform a relative effort estimation of each user story. How long will it take to implement the user story? Each team member may indicate how much effort they feel will be needed to implement the product backlog item (a.k.a. User Story). See articles on poker planning, a collective, relative, effort estimation process/tool that standardize how to perform these estimations.
When one of the DevOps team members has the bandwidth to take on one of the stories, they pull it off the backlog and move it to the Board for implementation. [Kanban] Boards have an agreed workflow to allow DevOps team members to move items through the agreed software development lifecycle (SDLC).
Production Critical Alerts Take Precedence
In this process, there is no commitment or agreement when the team member will finish their work on the user story, i.e., complete by Sprint Close cadence. Story Points, or Product Backlog, Size Estimation give the individual and the team an indication of how long the Product Backlog Item (PBI) might take to implement. Unfortunately, the (Development / Operations) DevOps team member’s responsibility stretches beyond “new” work from the Product Backlog. Operations duties, such as reacting to critical application monitoring alerts from the production environment, may take higher precedence.
Where Am I?!?
DevOps team members may have frequent disruptions in their work from production issues and have their heads spinning, switching back and forth from implementing PBIs to handling ADHOC issues from production applications. The Kanban board is one way to get everyone back on the same page with the changes in progress. At a glance, we can visualize the progress of implementing user stories, bugs, and associated tasks on the Kanban board.
Anatomy of a Great Kanban Board
Moving from a Scrum team to a DevOps team, you may, as an individual, be looking at the Kanban board from time to time, such as when you have bandwidth available to work on Bugs or Product Owner prioritized User Stories. The following does not assume your project team transitioned to a DevOps model or a separate DevOps team took over,
Columns Match your DevOps, SDLC Workflow
Regardless of who is doing the work, how the work is being done moving forward is essential to map out the software development lifecycle (SDLC) under DevOps constraints. The DevOps team will establish the states for each work item as they apply to the DevOps team. For example, there may not be QA team members, but there would be a testing process to verify the implementation of a Bug fix or User Story.
However, in a Scrum team going from “Dev Complete” to “Testing Complete” may require a “Release Management” phase, i.e. promoting code from DEV to TEST environments. On a Scrum team, between “Dev Complete” and “Testing Complete”, there may have been a phase to run a cursory or “smoke test” before going to “QA Approved.” This alternate DevOps SDLC process may not require a smoke test anymore due to the team’s composition. Long story short, it’s essential to get your process agreed to and implemented on the DevOps team Kanban board. Each column has a state, and the idea is to move Product Backlog Items (PBIs) from left to right and terminate at the “Closed” status.
Identifying and Removing Blockers
It’s all about keeping the momentum forward. If we cannot work on a Bug or User Story because we are Blocked for any reason, that is time wasted without progress. As a team, we should always be on the lookout for Blocking Issues that prevent our teammates or us from moving forward. Once identified, we aggressively look for ways to unblock ourselves or our teammates. The Kanban Board typically has a “Blocked” status column, so it’s very visible to the team once the PBI is indicated to be Blocked. Of course, the “Blocked” identification and remediation process is not limited to DevOps or Scrum teams.
The HOV Lane for Critical Production Issues
In some cases, changes to production code or configuration need to be dealt with by the DevOps team. These production issues that require “priority treatment”, e.g. Severity = Critical, may go in a “swimlane” on the Kanban board, which clearly articulates these Product Backlog Items (PBIs) are the top priority for the team (see figure above).
Definition of Done – Acceptance Criteria
As in Scrum ceremonies, the “Definition of Done” should be clearly articulated in the PBIs (i.e. user stories and Bugs). Sometimes the Definition of Done fits well in the “Acceptance Criteria” field of the PBI, i.e. these are the following things that need to appear in the code or surface on the UI to be accepted as “Closed” or “Done”.
Work in Progress (WIP) Limits
On some teams, there is a concern about “workflow blockage” at any given state in the SDLC process. For example, there could be 20 PBIs in the “In Progress” state for three DevOps team members. This could be identified as excessive and trying to do too much simultaneously. It also may contribute to confusion on the current state of any given work item. Some Kanban Board tools allow you to apply WIP limits so you cannot add more work items to a given status on the board. It also could be done using a standard paper Kanban board.
Product Documentation
If two separate teams are transitioning the work, documentation may be vital in the successful transition and ongoing product maintenance. Many agile teams are lighter on documentation and trust the product speaks for itself. Best case, user stories have been created that cover the team producing/updating a functional specification doc and a wireframe collection. The most probable situation is we have a pristine set of Features and associated User Stories. Each of the User Stories clearly articulates a description and, most importantly, “Acceptance Criteria.” that may be used for the development and validation of the functionality of the system. User Stories can be derived for knowledge transfer documentation.
Always Room to Improve – Retrospective
Although a Retrospective session is typically attributed to a Scrum ceremony, you don’t have to be engaged in Scrum activities to perform a retrospective. Depending upon the DevOps Team composition, it could be a collective, grassroots suggestion, or the team DevOps manager can recommend and facilitate the session. It would be better if a team peer fulfills the role of facilitator, and some retrospective tools allow anonymous feedback.
Good luck on your journey, and if you have any questions, please reach out.
