Dealing with administration
A few years ago there has been an IT department in our company which was doing
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.
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.
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.
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.
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.