Challenge:

I am the leader of a small IT operations and development team consisting of six members. Since we  are responsible for both operations and development, it is hard to plan development steps ahead,  because a lot of the time all plans change when some unexpected problems in operations need to be  handled first. We use a ticket handling system and try to solve occurring problems as soon as  possible. Nevertheless, we all feel the need for more reliable planning, since it is frustrating and  disencouraging when software development does not seem to happen at all; and for most of the  team members, that is the fun part of their work, while operations is more of a responsibility.

Selection:

Since we already put a lot of thought into that problem, but did not have a great idea how to solve it,  I wanted to try the Learning Launch approach. In a learning launch (see  https://ideas.darden.virginia.edu/the-learning-launch-how-to-grow-your-business-with-the- scientific-method for a short summary oft he method), a fast and cheap implementation of one or  more experiments or prototypes is used to test an idea or an assumption. The key idea is to learn and  reshape the experiment or prototype based on the results until it fits. In contrast to a lot of  discussion we already had, this sounded like a promising approach where all team members could try  and afterwards rate different solutions and find out what works and what does not.

Application:

Since the team is already small, it did not make much sense to test only with a smaller number of  team members. The goal was to gather different ideas how to organize our daily and weekly work to  make sure that there is enough time for software development. We soon agreed that in general two  days per week for each team member would be great. We came up with three different approaches:

-  2 fixed programming days: we reserve two days a week (we chose Tuesday and Thursday) for  programming work only; only truly critical tickets would be handled, everything else should  be postponed to the next day

-  Fixed programming time each day: we reserve three hours per day (10:00 – 13.00) for  programming work only.

-  2 programming days for everyone, but distributed over the week, so that at least 2 team  members handle incoming tickets.

We tested these three approaches, each for one week.

Insight:

The Learning Launch approach was really effective in trying the different ideas. Due to the short  duration of a week per test, everybody was really motivated to try it and to stick to the rules.

During the process, it became clear that we needed a better management of organizing incoming  tickets. A lot of time was spent with the selection and agreement on who, how and when handled  and solved a ticket.

Although the three-hours-per-day was somehow the easiest to stick to, most team members felt that  the time slot was too short to really get something done. The idea of 2-fixed-programming-days  showed the great team spirit that occurs when all team members work together. Nevertheless, it  was difficult to observe the rules of “only programming”, especially with external meetings and other  interruptions. The last approach was a bit difficult to implement, since certain team members  working on the same project should be able to work together, but it worked surprisingly well. All

team members reported, that it made a big difference that they did not have to monitor tickets and  felt really free to do their work.

In the end, we implemented a forth version: one fixed programming day (where only one team  member has to monitor the tickets) and the rest of the week the programming and ticket handling  days are distributed.

