Starting Off

Learn about the author's approach to the agile process when starting activities during the case study project.

The project started off with a team of 15 very skilled developers. This starting team had technical knowledge as well as domain knowledge. Its main task was to develop a referential implementation within three months, proving that the newly selected technology was feasible for this restart. The first attempt was mainly regarded as a technical failure because it never resulted in working software. However, this wasn’t the real truth, because, with better organizational management and a better process, these problems would have been solved without any difficulties. The referential implementation that was then developed by the starting team also created the underlying architecture for the system and showed within an executable application that also some business use cases could have been realized.

All this happened while the rest of the team, which contained more than a hundred people, was sitting around. These team members had the task of familiarizing themselves with the domain, although they had already worked on this business domain on the first try. It was obvious that this was not really a task, but a way to keep these people busy. They were also asked to acquaint themselves with the new technology and they all observed the referential implementation grow.

Defining the development quality

The starting team, on the other hand, ensured that everything was visible via the project’s wiki web. This was one of the differences the starting team settled, which was one step toward a new definition of development quality. This quality was defined by:

  • Simplicity: The most important decision was to have as simple an architecture as possible so that it was understandable by everybody on the team. The chief architect in particular forced the decision to not use any technology that wasn’t really needed but was popular at the moment. Instead, whenever somebody came up with a new technological suggestion, they were asked which of the project’s problems it would solve. Most answers were not very convincing and the suggestions declined.
  • Transparency: All the decisions were made transparent. All information about the project was always visible on the internal wiki web, so even people who weren’t a part of the starting team always knew what was going on. Whereas before not everybody knew what was going on, now everybody had the big picture in mind and were aware not only of all decisions but also of their possible influence on these decisions. This way, everybody was conscious of the project’s progress and felt responsible for the project.

Get hands-on with 1200+ tech skills courses.