Being agile in a non agile environment
At the moment, my team consists of ten developers and two product owners. We are developing and supporting over 60 applications plus a dozen services, which is quite a challenge. To make matters worse, the rest of the organization is not yet working according to agile principles and values, which means the internal business departments are not always available for questions during the sprint, do not participate in the daily and do not test stories once they are done. Furthermore, it is often not possible to work continuously on the backlog in order to be able to carry out a subsequent sprint. Accordingly, it was necessary to find a suitable form of organisation in order to cope with these surrounding conditions.
On the one hand, the result is that at least four projects are in development at the same time, whose sprints alternate, shown in the following figure.
That gives the business Units time for testing after a sprint or for specification of new requirements for the next iteration.
On the other hand, a so-called MAIN-Week is always inserted between two sprint blocks. This stands for Maintenance and Innovation. The breakdown is as follows:
Mondays and Fridays are available for maintenance work. With so many productive systems there are always little things to improve here and there — these are no hotfixes. They are of course implemented as soon as they occur.
On Tuesday morning, the reviews of the previous sprints will take place, where the departments are invited to present the results with the entire team. This will be followed by a joint retrospective.
In the afternoon the refinement of a project for the next sprint takes place. Everyone participates to spread the business knowledge among all developers and to get fresh ideas for the implementation. The composition of the teams can also change from sprint to sprint within a project, depending on which skills are currently required in terms of content or technical requirements.
Wednesday is Innovation Day. On this day, small teams of 2–3 people can get together to experiment with new ideas, new technologies or tools. After a maximum of three meetings of that kind, the gained knowledge is to be presented in the way of a Tech-Talk. The entire team then decides whether to continue working on it, drop it or roll out the results to every project. It is time for such a Tech-Talk on Thursday afternoon, after the refinement of the second project of the next sprints was carried out in the morning. A small challenge cup is awarded for the lastest best innovation. In recent months, several innovations have already become standards, such as ArchUnit for unit tests of the architecture. Innovations were also rejected, but this is a good result after three days of investment. A well-filled backlog of topics is always available for the Innovation Day. It is open to everyone to bring in their own new ideas. This planned and ritualized innovation stimulates the courage to explore new things and brings each individual closer to the goal of technical excellence. In addition, it is a lot of fun, promotes team spirit and the gamification with the help of a trophy awakens the ambition to have the trophy on your desk for a few weeks as the winning team.
