Skip to main content

Scrum in System Administrator Environment

Last post 11:30 pm January 27, 2020 by James Noble
10 replies
05:21 pm January 27, 2020

Hello Scrum Masters et al,

I was made aware of the PSM certification and passed it within 48 hours. I'm trying to figure out how to implement it in my environment. I have three teams in my department:

  • Service Desk, which will apply ITIL 4 standards
  • Software Development, which I will use standard Scrum sprints based on the product we're delivering
  • System Administration/Software Configuration

For the 3rd team, I'm trying to figure out how to implement agile, and more specifically how to divide up the roles. There are 2 scenarios:

  • 3 SysAdmins and one software
  • 1 SysAdmin with several software

Under the former software, there are several tenants with their respective clients. My inkling is to take the Sr. SysAdmin and have them take Product Owner training and take on the responsibility for the software with its multiple configurations/tenants. Running sprints that scale to the size of the implementation.

For the latter, I would suspect they would be the product owner for all the software they support, then run sprints for each software.

I am open to feedback and potential improvements.


Thank you for your time and attention,


06:11 pm January 27, 2020

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? 

06:27 pm January 27, 2020

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.

06:38 pm January 27, 2020

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?

07:12 pm January 27, 2020

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.

09:28 pm January 27, 2020

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?

09:50 pm January 27, 2020

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.

10:10 pm January 27, 2020

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


10:36 pm January 27, 2020


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.



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.

10:44 pm January 27, 2020

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.

11:30 pm January 27, 2020

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.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.