Keywords

1 Introduction

In 2012 the University of Vienna started the SSP project, a software development project to implement a new service portal to be used by the university’s 93.000 students and 9.000 staff members. In 2014 it became apparent that the project was going nowhere. An important project milestone came nearer. However, the results were practically unusable. Morale was low, trust between business and IT was low, fighting with the main contractor started. The rectorship – the university’s board – and the project’s managers decided they needed nothing short of a complete restart. This time around they decided to use an agile software development process. It was to be the first large project within the complex organization of the university to which agile methods would be applied for real. Could it work this time? To say the sceptics were the majority would be an understatement. But what else should they do?

So they started change2agile, an organizational change project to prepare the IT department and its project partners to switch to an agile development organization. The business departments they worked together with and other stakeholders were invited to participate. The organizational change project itself was run as a Scrum project, with change teams, sprints, reviews, retrospectives etc. After half a year of intense preparation the IT department started four cross-functional Scrum teams, two of which were assigned to the restarted SSP project. To bring in real world experience they hired an external operational project manager and an external agile coach.

More than one year later, the project is on a great track. The relationship between business and IT has reached new levels of trust. The rectorship and managers are very pleased with the project turn around. Enthusiasm, optimism, and fun, missing for so long, are back. Of course, not everything went smoothly. A lot of planned functionality is still missing. Some things still need to be improved. However, we are convinced that together we will succeed. In this experience report we would like to share with you what we learned.

2 Road to Perdition

In this chapter we will describe the different phases of the first attempt at the SSP project from the beginning until the decision to restart in new a setup in April 2014.

Phase 1 – “Ignorance is bliss”

In 2012 the Federal Ministry of Science and Research approved the project. In 2013 the project started with an external company as general contractor. They sent a development team including an operational project manager. The collaboration between business and IT had been difficult. From IT’s point of view, business had inflated expectations on the features that were to be delivered while the contractor did not see what they had gotten into. At the same time, IT and business hoped to solve a lot of put off problems in the project. The moment the contractor realized that they tried to reduce project scope.

Phase 2 – “Fear is the path to the dark side …” Footnote 1

Even though the detailed scope was still being negotiated and the contractor’s analysts were still writing detailed specifications, the developers had to start. As a consequence the project was off to a very uncoordinated start. The process was like this: the analysts talked with business about the requirements, then went to the UI designers and developers, and after that brought their feedback back to business. The requirement feedback loops were endless. At the end the contractor set deadlines for the approval of specifications by business, even though they were not really finished. Project management tried to impose an ever more detailed process of deadlines and deliverables. While this was meant to clarify everyone’s responsibility it had the opposite effect – it lead to each party blaming the other. Everyone was driven by fear.

Phase 3 – Acceptance Tests or “You shall not pass” Footnote 2

The team members’ good mood and motivation disappeared over these disputes. 9 months into project this development cumulated when the target date for the first release was not met because the acceptance test was not successful. It became clear that this mode of working did not yield any useful results. The release date was postponed twice. Yet the resulting software still could not be accepted by business.

Phase 4 – “Nobody has any intention of building a wall” Footnote 3

At this point project goals did not matter anymore. The team members blamed each other for the failure to meet the release dates. As a consequence project management imposed more process and rules, documented in multi-page flow diagrams. By now no one even remotely believed the project could be turned around by a joint effort.

Phase 5 – The War of Roses

At that point in time, the whole project team stopped working on the product. Letters were sent back and forth between the rectorship and the contractor, trying to find a way out. There was none. From now on discussions moved to the legal level. 16 months into the project the partners agreed to cancel the contract. Overall, more than 1500 pages of specification and thousands of lines of codes were written. We spent hours in emergency meetings, the contractor changed their project managers 3 times. But none of the modules passed the acceptance tests. When the contract was terminated, none of our goals was achieved.

Phase 6 – Returning to meaningful life

Finally the last stage of grief began. Morale hit rock bottom. Both departments involved in the project met to lick their wounds. Lessons learned were identified and various ways were discussed how the project could be turned around. Many could not believe this was even possible. The following things were clear: IT and business had to find a way to work together more closely and take full responsibility for the project. No one ever wanted to depend on a single external contractor anymore. And finally: the restart should be agile.

3 The Restart: change2agile

Two years earlier the IT department had invited some other business units to experiment with agile methods in a smaller project. The experiences with the SSP project reinforced those ideas, both in the project departments and the rectorship. So the IT department decided to switch all software development to Scrum. Before the SSP project could be restarted, the project team members had to prepare for the new agile process.

What did we do when?

After two restart workshops, one in the IT department, and another one together with the business units, an organizational development project was started in June 2014 – named change2agile (c2a). People of all relevant departments united and set up three cross-department teams to define the new agile working process. To gain practical experience in it we decided to run the change project as a Scrum project. As the IT department is also servicing other business units and they would be affected, we invited them to join the change process.

What type of change stories did we have?

As c2a was a change project the user stories were a little bit different to a normal user story. Here are some examples of our change stories:

  • How should the teams be constituted, so that everyone is happy?

  • How do we organize the release process?

  • Define roles and responsibilities.

  • What should be in a feature team’s user story?

The change stories had acceptance criteria, e.g. “there exists documentation in the Wiki”, “all relevant stakeholders have agreed”. In addition to the Wiki documentation a newsletter was sent to a wider group of stakeholders after each sprint.

How did we organize?

Each of the three Scrum teams included people from IT (software development, streaming department, operations and support) and business departments. Some of the line managers were part of the teams. However, they had no more rights than the other team members. There were two product owners, one from IT and one from the SSP business unit. Three members of IT volunteered to be Scrum Masters. Every team member was allowed to spend 20 % of her/his work time for the change project. The rest of the time people worked on their normal duties in their departments.

Sprints were two weeks long in the beginning, later extended to three weeks. All the teams agreed on using JIRA for tracking c2a’s backlog. There was a weekly Scrum of Scrum. Planning meetings and reviews were held with all three teams together, retrospectives were done in each team separately. The teams organized themselves, some met twice a week, some less regularly, depending on their change stories. The teams used planning poker to estimate story points in order to decide what stories could be done in the upcoming sprint.

What worked well?

The cross-department setup proved to be essential. Communication improved substantially. The time boxes helped focusing on the tasks to define how the projects should be run. It was a good vehicle for the IT and business units to get to know each other and to learn to collaborate. It increased self-confidence in our ability to really execute the switch to agile. It helped to reduce the fear of such a big organizational change. It allowed team members to experience the success they had lacked for so long. It helped avoid surprises. It helped to convince some of the sceptics. We had wanted to take our fate in our own hands and were finally allowed to do it.

Who/what helped?

Line management helped by not interfering, encouraging self-organization and self-responsibility. All groups could participate in all decisions, e.g. the business team members on questions regarding software development. This was unheard of and helped building trust. It showed that transparency is a good thing.

What did not work so well?

Although all departments were invited some of them did not participate enough in the change process in hindsight. Some of the decisions stayed only theoretical and were never put into action, even although some of them would have been useful and were needed, e.g. the Definition of Done was not often followed. The Definition of Ready is still not used. Why? It was not possible to take care of every single aspect when the team started. It turned out to be difficult to put theory into practice immediately. It took some practice and retrospectives to finally get there.

A small group of team members were fundamentally opposed to the agile process. They were sure that moving away from detailed analysis would lead to bad quality and chaos. This resulted in long and exhausting struggles and discussions. Which cost quite some energy. Two of them eventually decided to leave the university.

What did we achieve?

We successfully developed a clear common picture of how the agile process should be lived and practiced. This included a set of definitions and rules. Everything was documented in a wiki. The change2agile team members spread this know-how in their respective units. Also, the change2agile team members decided to recruit external help for the SSP project: an operative project manager and an agile coach. In September 2014 they started working.

On October 27th 2014 four Scrum cross-functional development teams officially started. They were built from members of the IT department’s groups project management, analysis & test, and software development. As a result every team consists of software developers, one to two analysts, one tester and one Scrum Master. The team members still report to their respective line managers. In the first step the group operations & support was kept separate. This was a major milestone in the agile transformation. From then on the SSP project had become a truly agile project. However, it was clear that this actually was just the beginning, the first step in a longer journey.

4 U:SPACE – The Agile Way to SSP

With the most important questions on how to restart, we could begin the next step of the project leading to the release of the new portal, now named U:SPACE.

How are we organized?

Currently the IT department is running five Scrum development teams, two of which are assigned to the SSP project. In addition there are two external teams, one from a software development company and one from the Faculty of Computer Science. In total there are four SSP Scrum Teams. They work in sprints of three weeks starting with planning on Wednesday. The university uses a university management software package based on standard software with extensive customization. This system is the data backend for the new portal. Three freelancers, which are specialists for this system, are part of the IT Scrum teams. They are not based in Vienna but work from Germany. They fly in every three weeks for the refinement meetings. They participate in the other meetings using Skype.

What is special?

The SSP business unit decided to have 10+ product owners (PO) for four teams. The product owners are responsible for different topics and their respective stories. They meet once a week, in the PO board, and try as good as they can to reach an agreement about the user story priorities. In case of an unresolvable conflict the SSP business unit lead decides. This means that a team has more than one PO in a sprint. At the same time, one PO has stories for more than one team. This allows us to concentrate all teams on one bigger epic if needed. This means that POs and teams need to coordinate well to ensure all software parts fit together.

To help coordinate between the POs themselves, the role backlog owner was introduced. One of the product owners fills this role. He is responsible for the JIRA backlog; he moderates the PO boards, but does not have more rights in prioritizing than the other product owners.

How do we report?

To bridge the gap to the non-agile departments a unique reporting process was initiated iteratively. The rectorship gets one report with the results from all four teams after every sprint, every three weeks. Project management assisted by the Scrum Masters and Product Owners writes it. It includes a calculation of the achieved business value.

Feedback is very positive. One vice rector expressed that now for the first time she has the feeling to really know the status of project, which gives her peace of mind.

What did we deliver?

In 2015 we put the first version of the portal online. A major new module for modelling the curricula was put into production. New versions of existing applications for students were introduced into the new portal, such as new records of examinations, study overview, course directory. The process for admission to degree programs is now supported online the first time. Students have to visit the admission office less often, which was one major goal of the SSP project. For university teachers a new application for grading exams was introduced. Feedback from them was generally positive.

In December 2015 the rectorship decided to go with a recent high court ruling allowing universities to charge fees for entrance exams in the course of registration. The rector asked the teams if they could create the new function in U:SPACE. It had to be finished by March 1st, 2016. The teams took the challenge. Although it was hard work and time was running out in the end, the teams made it. The most critical success factor was the intense and very good collaboration within and between the teams. All this cumulated in a perfect review presentation. Agility at its best!

What happened to change2agile?

After the successful start of the Scrum teams many of the responsibilities of change2agile shifted to Scrum teams. However, the project members decided not to stop the project in order to address organizational issues concerning all teams. Some of the less important change stories had also not been finished. To account for the new responsibilities, some adaptations were made to the project.

As the number of team members was reduced the project now consists of just one core team. The amount of time reserved for the change project was reduced significantly. The change2agile team is run as a governance team. The team members meet once a month. For each change story a volunteer assembles a smaller ad hoc team of experts to work on the change story. Because the people working on the change stories vary so much, Scrum turned out not to be ideal. Therefore the team members decided to switch to Kanban, which allows us to work on stories over a longer duration than a sprint’s length.

Team Building and Human Factors

As in any collaborative endeavor human factors play a major role. After the restart it took some time to build up trust again. Conflicts about various topics are unavoidable and pose valuable challenges for improving team collaboration. The agile coach is there to help the teams with these and other communication issues, by sharing his observations, giving feedback, clarifying dynamics in the teams’ communication, and suggesting helpful models of communication psychology, such as Friedemann Schulz von Thun’sFootnote 4 four-side model of communication, value and development square, or Kerth’s retrospective prime directives.

All team members and the management agree on the importance of the following values: open communication, business and IT working together on a daily basis, team autonomy and self-organization. The culture of retrospectives was established and improves transparency and honesty on all levels. In June 2015 all project team members met for a two-day team-building workshop. It was run as an Open Space and moderated by the external agile coach. It helped the participants to get to know each other better and discuss topics for which there had not been enough time in the day-to-day project work. Many of those topics led to change2agile backlog items. As feedback was positive management approved a repetition in 2016. Other regular team-building measures organized by the Scrum Masters include sprint drinks, team days, release parties, visits to Vienna’s Christmas fair, and a solemn Christmas party.

A Survey on the Agile Transformation

Between July and October 2014 a survey was conducted among 17 members of four business units regarding their experience and satisfaction with the agile transformation on the one hand and the agile process on the other. The results show a median satisfaction of 7 out of 10 for the agile transformation and a median satisfaction of 8 out of 10 for the agile process at the time of the survey.

Overall, we consider this a great result, with still some room for improvement. In one business unit the results were less positive, especially the satisfaction with the agile transformation. Not surprisingly, this was one of the business units, which did not participate much in change2agile. An important result of the survey was that some areas of improvement were identified. In the meantime many of them have already been dealt with, either by the respective Scrum teams or by the change2agile team. The head of the IT department together with his management team decided to repeat this type of survey at least once a year.

Lessons Learned

We learned that working together between departments is the basis for successfully achieving our goals. This is possible if everyone is respected as an individual with her/his skills and shortcomings, which we found to be a prerequisite for trusting each other. Trust is essential within the project teams, and also to departments not fully involved in the agile process. One key factor is encouraging social contacts beyond the daily business. We learned that for taking on full responsibility for the project instead of solely relying on our external partner, we also need the management’s confidence. Regular delivery of software, regular, transparent reporting, and solving problems within the teams as much as possible are key factors.

In order to achieve our change to agile working it is absolutely essential that our management is fully behind the agile values. They themselves engage in Management 3.0 theory and practice to better support the teams’ self-organization. We still have some problems with the fact that in the past there was a strict separation of roles (analysts, developers, and testers), which makes it difficult to work cross-functionally.

Last but not least, we learned that to successfully introduce agile software development we also needed to develop our organizational structures and process in a fundamental way. Using agile practices for doing that was essential to develop the right mind set. To everyone’s surprise, working in an agile way proofed to be entirely possible in such a huge, old, politically overloaded organization as an university.