Applying agile in a mostly operations/support environment

Question

I have read numerous Project Management SE questions on this subject, as well as done a fair share of Googling. I am aware that different incarnations of this question have been addressed before, but I have not found something that provides me a clear answer.

I am the PM in a 20-person team, including some remote resources. We develop or maintain about 10 applications. About half the team works on most of the applications, which are stable and have no real product owner or roadmap except for production fixes or improvements that the team comes up with internally. The other half works on one or two applications that are highly impacted and require modification when the company comes out with a new product every few months. Those one or two applications also have production fixes and improvements that the team comes up with internally. (We're basically at liberty to modify them however we want, as long as the business continues to be supported.) I'm new to the team so I don't know yet how much those applications can be future-proofed to mitigate the sudden urgent modifications. There is some overlap between the two sub-teams but the applications are sufficiently different that resources are not completely interchangeable.

The team has been trying to adopt scrum for a few months prior to my arrival, but with practically no product owners, no cohesive long-term vision for the applications as a whole, and little interdependence among the breakfixes, I don't know if scrum is the right way to go. I've read about combining kanban with scrum but can't seem to wrap my head around it. Scrumban sounds nice but it is so much newer and less mature that I am hesitant to adopt it. What would be the best way to manage this team so the load is level across all resources, we work at a sustainable pace, and we have a somewhat-defined goal to guide our development efforts?

Answer 1

Based on past experiences, I would agree with the other posts above and recommend starting with a flow-based approach like a kanban board for the ongoing support apps, and maybe look at Scrum for the ones in heavier ongoing/feature development. I would also recommend starting with a board that matches your actual step by step flow and not an idealized flow, even if it looks really wonky - it will be a key part of the transparency you gain from kanban. I also think that transparency will immediately give you and the team discussion points for how to better organize into sub-teams, etc.

However, I don't agree that you need a designated Product Owner, particularly for the ongoing support stuff, and especially if the team is already showing product ownership. Over the last few years I've come to realize/support distributed product ownership as a very healthy thing; similar to a good Scrum Master aiming to make themselves obsolete by showing a team how to fully embrace and thrive with kaizen, a good (single) PO should aim to make themselves obsolete through radiation incredibly strong vision and providing ongoing alignment tools that everyone can adopt and move forward with.

That being said, it is much harder to do on a vision-is-everything product vs. something in maintenance, but it should still be a long-term goal. :)

Answer 2

Scrum is not Agile. :) It is one way to do agile, it doesn't fit all situations.

Based on what you've described, a straight Kanban approach is going to work much better for you. When supporting a live service, when you need to make a change, it is often something that needs to be changed "yesterday". Waiting for the next sprint to add it to the backlog is not going to cut it.

Why Kanban? - Kanban does not have iterations. Work is controlled by work in progress or "WIP". - Kanban doesn't have a set planning meeting. You plan as it is needed. - Kanban still has a rank ordered backlog. - New items can be added to the backlog at any time and can be added to the to of the queue, thus allowing urgent issues to get priority. - Work is controlled by the WIP. If you've got six developers, then your "Doing" column probably shouldn't have a WIP of more than 3. This controls your cycle time and ensures issues get worked quickly.

Some notes: - It is still important to practice good user story creation, even on urgent items. Making sure you review acceptance tests in detail can make the difference between fixing a bug once and fixing it three times. - Practicing good XP practices like TDD are going to help you a lot. It will shorten cycle times, reduce rework and improve quality.

Answer 3

Kanban for maintenance and Scrum for development

What would be the best way to manage this team so the load is level across all resources, we work at a sustainable pace, and we have a somewhat-defined goal to guide our development efforts?

If I were you I will start with the following straw man proposal and refine it from there:

About half the team works on most of the applications, which are stable and have no real product owner or roadmap except for production fixes or improvements that the team comes up with internally.

For the team doing maintenance work Kanban is a better fit. You may need the following states:

• To Do
• In Progress
• Under Verification
• Awaiting Deployment
• Deployed
• Verified in Prod

And you can consider 3 swim lanes as follows:

• High Severity Production Bugs
• Other Bugs
• Enhancements

The other half works on one or two applications that are highly impacted and require modification when the company comes out with a new product every few months. Those one or two applications also have production fixes and improvements that the team comes up with internally.

For the team doing mainly development work Scrum is likely to be a better fit.

You can designate one person as the Scrum Master and another person as the Product Owner. These need not be full time roles. This Scrum Master can also manage the Kanban Board, help set WIP limits, make tweaks based on the Cumulative Flow Chart and help resolve impediments for the other team as well.

If the size of this Scrum team exceeds the Scrum Guide limit (see relevant extract below) consider splitting into two teams.

Having more than nine members requires too much coordination... The Product Owner and Scrum Master roles are not included in this count unless they are also executing the work of the Sprint Backlog.

Try to keep the teams relatively stable because teams take time to gel and become productive. However, you can make occasional adjustments based on projected workload.

Answer 4

There are a few aspects in your situation that you need to consider before deciding on best process for in your situation:

1. You said that you do not have identified product owners, and long-term vision for the applications. You need to create a vision and plan for the application whether you use agile or waterfall method for managing the development – you should work with the stakeholders, especially the sponsor, to identify product owners and define the plan. In scrum, being an iterative process, you need to define in detail at least enough features for the team to work on during the next sprint. You should also have a number of features loosely defined for future sprints.

2. You indicated that you have a 20-person team. An optimal size of a scrum development team is 3 to 9 persons. If you choose to use scrum, you should consider create multiple scum teams that could work on separate applications, or separate features from the backlog.

3. The scrum development team should conduct testing of the completed features during the sprint and fix any defects before the iterations of the application is released at the end of the sprint. But, for defects defected after the sprint iteration is released, you need to work with the product owner to determine whether the defect can be added to the current or future sprint, or whether the defect is critical enough to need an immediate resolution, which may often be the case. For these urgent defects, you would need a different process, outside of the strict scrum process, to handle urgent defects. Kanban may be a good fit for urgent bug fixes and for doing a triage on any defects detected after the iteration release. You may dedicating some resources to focus on these defects, but to ensure that these resources have broad understanding of your applications and since few people want to always work of fixing defects only, you should probably consider rotating the resources between development and defect fixing.

4. The difference between Kanban and Scrum is that Kanban is a continuous-flow ‘pull’ process, which scrum is actually a hybrid between a ‘pull’ and a ‘push’ process. A ‘pull’ process completely demand-driven and therefore a ‘pull’ process, as such Kanban, is a great for customer service requests where the turnaround time is paramount.