Agile Development @ DocuWare

In 2011, DocuWare changed its whole product development process. Since 2012, we have worked in an agile manner, using SCRUM and Kanban methods. DocuWare Version 6 was the first software produced under the new process.

I would like to share some insights on the process and the benefits we have seen so far.

What is our process? In brief:

  • We now have two fixed release dates per year. Our six-month release is spread into eight fixed Sprints, each three weeks long.
  • At the beginning of a Sprint we plan the work. Then we code and the results are tested. Potential bugs are fixed. At the end of the Sprint the results are presented to Product management and technically evaluated based on a very strict Definition of Done.
  • We have several development teams, spread over two countries. Each of them works on different topics.
  • One or two Quality Assurance testers are dedicated to each team and are even sitting in the same room as the developers. During specific Hardening Sprints, which come after every three normal Sprints, we produce an overall integrated version and concentrate on bug-fixing and optimizations. After the Hardening we use that version for an update to our own DocuWare in-house installation.
  • Translations are done as we go, so that all DocuWare language versions are ready at the same time.
  • The Product department plans in advance. Product Owners, associated with specific teams, fill a so-called Backlog for the team, get estimates from the team and plan the Sprints and Releases based on that information. Product Owners discuss and coordinate the plans among themselves.
  • The team Scrum Master ensures that the team can be productive and efficient in addition to his technical coordination function.
  • Central elements like the Architecture board or Infrastructure board are used to coordinate inside development.
  • The development teams are thematically grouped, and each have their product Owner and tester. Some teams like CoreServices and Setup mainly service other teams.
  • The teams can add technical topics to the backlog.

The benefits:

  • We reached a high level of transparency where we can see planning and execution status in detail and can also track some parameters. We also reached a high level of discipline in information provisioning and tracking.
  • We get running software after three weeks instead of several months. Results can be checked by the product department and change requests can be handled immediately.
  • Since testers are testing results inside the Sprints, quality is much improved. Bugs are fixed as they come up.
  • There is a clear split of responsibilities between definition-oriented Product Owner and the technological execution with quality check by the team.
  • Introduced retrospectives and daily meetings helped a lot in the team-forming process. Teams really work as teams, with a high level of knowledge, task, and interest sharing.

Additionally, we invested a lot into our development infrastructure and build procedure to support the agile process. We currently produce a Continuous Integration version of our software every 20 minutes. All nightly builds also execute Unit Tests. After the successful nightly build, a lot of automated deployment and integration tests are running. Every morning the results are checked and actions taken. All these measures, as well as the early testing during the Sprints, have increased the software quality.

The whole process is based on the Microsoft Team Foundation server and uses the Scrum Tool UrbanTurtle, as well as many other tools.

Summary: The change was well implemented and is stable and successful. Overall, the methods combined reduce waste and increase efficiency, ultimately resulting in higher customer satisfaction and more lead generations.

I welcome your feedback or questions. What is your experience with agile development?



Instant Updates

Subscribe to the Modern Digital Business blog and get instant email notifications when a new article is published.


Show all topics