Scrum in System Administrator Environment

What about the System Admin team's work makes you believe that Scrum may be a good framework for them? 

Have you looked at Kanban or Scrum w/ Kanban as potential alternatives? 

Thanks for the response Tony,

I'm still parsing through the minutiae of the differences of Scrum, Kanban, or Scrum w/ Kanban, so if you have a matrix where I could quickly compare them I'd be happy to provide an answer.

Regardless of the methodology of Kanban's limit of WIP vs Scrum's sprints, I need to scope how Product Ownership would work for our small teams and varying amounts of work.

I need to scope how Product Ownership would work for our small teams and varying amounts of work.

Do you have a clearly defined product, a way to measure value, and someone willing to be accountable for maximizing that value?

Thanks or the response Simon,

Here is more detail into the specifics. We build databases for processing applications that run validations and automation. The team of 3 work on configuring this product for several clients we process for. This team has a backlog of continuous improvement items to work through, that include quality of life configuration updates, new automation, yearly program improvements, and remediations/configuration bug fixes. In addition, there are new builds that are dropped on us with little notice and tight deadlines. We already have the priority, effort, and description, we just have to scope value/ROI. I think this group is prime for Scrum. I just need to figure out if I should have the lead SysAdmin act as the product owner for all instances or if I should break out into Major Client 1, Major Client 2, and all minor clients. In the latter scenario, we'd run three Scrum teams in the former it would be one.

I'm trying to figure out how to implement it in my environment. I have three teams in my department

Let’s consider the product environment instead. Would the teams you describe each deliver a “Done” increment of working product? If not, what integration dependencies would they have to manage?

To me all of the work you have described sounds very repeatable, predictable (except for when it will fall on you) and not extremely volatile.  I am not sure that Scrum is what you need.  There doesn't seem much of a need to inspect and adapt outside of fitting a lot of tasks together in a schedule.  It seems like a good task scheduling system would be better served for you. But I'm open to being convinced otherwise.  

1. How would you determine your repeatable Sprint length? 

2. What would be your deliverable increments at the end of the Sprints?

3. How would the Product Owner be determining the value that is to be delivered to the stakeholder? Is it variable enough to warrant someone dedicated to doing the discovery for this? 

Those questions are the first to come to mind in your scenario.  Again, I really think you just need a good way of managing/scheduling tasks because I'm not really seeing how Scrum Framework would benefit you.

Whenever I am in the situation that you are describing I always try to fit a solution to a problem rather then a problem to a solution. In other words carefully consider the important things about the problem before trying to find a good solution that fits it.

In this case your problem seems to feature a few key:

• Team 1 Service Desk - Triage issues as they come in, work on the most important, get things done ASAP
• Team 2 Software Development - If similar to most software development teams could easily work with Scrum or Scrum with Kanban or Lean/Kanban
• Team 3 - this caught my eye specifically - "there are new builds that are dropped on us with little notice and tight deadlines" - This implies a need for triage, prioritization and likely shifting plans on a regular basis including possibly during a sprint. If the need for shifting is faster then the sprints are long then you will likely have conflict by using Scrum this way

For this scenario you have two teams that are going to likely need to triage what they are working on and I suspect having them even using one week sprints would result in too much delay for urgent issues. While scrum could be made to work it would likely be a less optimal fit then using Lean/Kanban with swimlanes, Service Level Agreements especially since Lean/Kanban will likely fit in more smoothly with team 1 if they are using ITIL. Team 2 could use Scrum or Scrum with Kanban. They could also use Lean/Kanban if you were trying to find one way of working for all 3 teams to use.

~Jamie N

Ian,

For the majority of the single SysAdmin, they would be able to make configuration changes that would be done ad hoc, since it would be "shippable" right after the config was "Done." So I'm leaning heavily towards Kanban. The 3 member SysAdmin team has a lot of small improvements that need to be integrated into existing systems with no set due date. For this, I am starting to think Kanban would be best. Then, from time to time we have large builds that we'd need to ship before a certain deadline, this is where I think we'd benefit from Scrum. Pulling a member or members from the Kanban team to work on iterative sprints to drive to the releasable product, meeting with the Product Owner and stakeholders to ensure the tenant is up to their specifications.

Daniel,

There are times we're just driving maintenance/updates, which I'm leaning towards Kanban to make sure the PO is involved and the Dev Team doesn't get overwhelmed. For the new builds/configs/major updates, this is where I'm leaning toward Scrum:

1. Go-live dates and the number of check-ins to ensure the product is what the stakeholders are looking for.
2. A functioning database with the ability for data entry employees to put in the data and have the system validate the requirements.
3. ROI on process improvement in FTEs or quality of life upgrades.

At this point, I'm just looking at Agile in general and trying to figure out how my team can best tackle the backlog and deliver on things with deadlines (when they have them). I'm not stuck to Scrum, Kanban, or other methods for this job, just trying to find the right tool.

Thanks for the direct feedback Jamie,



I think that your answer best fits what I was trying to scope.

• The service desk is implemented through Jira Service Desk and we're able to get most of our tasks done within SLAs.
• For the software development team, I will investigate the Kanban variants to see if those fit better than trying to run sprints.
• This team is more trying to retain people with our proprietary system knowledge and streamline processes then increase automation in those systems, until we have a large build come in (which happens 2-3 times a year). I think I could work with the PO to determine how many resources are required to complete the product by the determined deadline and source the SysAdmins, limiting the flow of the continual improvement items.

Both Scrum and Kanban support the concept of release separation. What I mean is that if you were using Scrum you don't necessarily only get one chance to release. You could do multiple releases during a sprint or, provided supported by Definition of Done, you could release to production monthly or some other longer period.

Lean/Kanban supports the same thinking except they word it more like, "Accumulate enough completed work to make a release useful and then release. Higher priority things release more often then business as usual".

The important thing is that in either way of working you could just continue working as normal until you reach the point where a release makes sense and then release it.