Skip to main content

Dealing with administration

Last post 03:49 pm February 12, 2016 by Andrzej Zińczuk
4 replies
11:30 am August 7, 2015

Hello readers,

A few years ago there has been an IT department in our company which was doing
product development,
product support (bugfixing, administration of our "livesystem cluster") and
administration of our IT infrastructure e.g. email, wiki, telephone, computers and so on.

We then convinced our CEO to introduce scrum. Our intention was to separate development and operative work (support, administration), so that developers could work without interruption. He was very interested and agreed.

One of his terms for his approval was to take care of every aspect of the old IT department.

We now work in two scrum teams with 2 PO and 2 SM. Everything went better than expected, except one thing. We just don't know how to deal with the administration of our IT infrastructure. On the one hand Issues tend to distract our developers, on the other hand almost every developer does not want to do those basic administration tasks.

I would like to know, how do you guys deal with this. This must be a topic in companies which are developing software and using IT infrastructure (and I assume that would be nearly every company in the world :) )

If I get some answers, I tell you how we deal with it and give you some details about our struggle. But I would like to hear some open minded approaches first.

With regards,
Tobi


02:42 am August 8, 2015

Your situation is common to startup or small organizations.

Per my experiences, during the Sprint Planning, DT always reserve capacity for infra and ad hoc tasks.
These infra and ad hoc tasks will be group to a virtual Sprint Backlog Item listed at the bottom of To-Do-List of ongoing Sprint.

To ensure the quality of development tasks and substance pace, a WIP limitation is defined.
During Daily Scrum, DT pull tasks from To-Do-List per their own skill. There should be tasks of the virtual Sprint Backlog Item moved from to-do to work-in-process.

As a scrum master. coach the team that the tasks in the To-Do-List is owned by THE TEAM.

Another hand, if the IT support or ad hoc tasks were due to products developed by DT, a DevOps concept should be delivered to DT.


08:27 am August 8, 2015

It's important to consider the scalability of the model you adopt. Reserving sprint capacity can be viable in-the-small, but it's unlikely to prove sustainable once an organization grows.

You said that "almost" every developer doesn't want to do basic administration tasks. Are there some that do? Could they form the nucleus of an admin team? There's nothing to stop such teams from working in a lean or agile fashion. Remember that these practices are not constrained to development matters, and they should integrate with the wider organization in terms of value delivery.


03:54 am August 13, 2015

Hey guys,
thank you for your answers.

Two of our 11 developers feel committed to administration tasks, one in each team. They work as part of the teams on their own tasks. I know, this sounds stupid. The main argument for not leaving their teams is, that they do not want to loose track to the stuff the other guys are developing.

I think we kind of work like Ching-Pei Li suggests: every team buffers some time (one developer per sprint) for administration. I would love to form an admin-team, but this idea must be wanted by the team and the people within. And the committed to admintasks-guys wont leave their team. see argument above.

Greeting,
Tobi


03:49 pm February 12, 2016

Interesting topic, having dedicated admin team might sound great and it make have disadvantages. Everything depend on type of those infrastructure activites. If they are connected with product teams deliver - I believe it should stay in teams. At scale some of duties like keeping infrastructure and tools live might be good product for dedicated team serving own organisation.


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

Please note that the first and last name from your Scrum.org 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. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org 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 Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.