Titel Ersatzvortrag:

SCRUM – Vorteile/Nachteile – eine Gegenüberstellung

Session:
Projekt- und Anforderungsmanagement mit Scrum

Datum und Uhrzeit:

Montag, 3. Mai 2010 von 10:00 bis 10:40 Uhr

Referenten:

Thomas Schlereth Jahrgang 1969, ist Geschäftsführer der Can Do GmbH in München, die Projekt Management Software der neuesten Generation anbietet. Bereits 1994 gründete er das Beratungshaus Columbus Consulting, das sich auf die Einführung von Projektmanagementwerkzeugen bei großen Unternehmen spezalisierte. Daraus entstand 2000 die Can Do AG die eine eigene Entwicklung begann. Hier war Schlereth als Vorstand für die methodische Ausgestaltung der Softwarelösung zuständig. Thomas Schlereth hat eine Vielzahl von Publikationen veröffentlicht. Darunter Bücher zu den Themen Projektmanagement, Unternehmensführung und computergestützte Projektmanagementsysteme. Er hielt Vorträge an Universitäten und bei Veranstaltungen der Deutschen Gesellschaft für Projektmanagement (GPM) und des Project Management Institutes (PMI). 2007 und 2008 hat man Herr Schlereth und der Can Do GmH mit ihrem Produkt „Can Do project intelligence“ den deutsche Innovationspreis verliehen. 2008 gewann die Can Do GmbH den bayrischen Exportpreis. Thomas Schlereth ist Datenverarbeitungskaufmann und Wirtschaftsinformatiker und seit mehr als 15 Jahren im Projektmanagement aktiv. Herr Schlereth wurde 2009 in den Senat des Bundesverbands für Wirtschaftsförderung und Aussenhandel berufen.

Titel:

Agile-Scrum Planning

(Ross Inglish)

Session:
Projekt- und Anforderungsmanagement mit Scrum

Datum und Uhrzeit:

Montag, 3. Mai 2010 von 10:00 bis 10:40 Uhr

Beschreibung:
The purpose of this presentation is to describe the differences between the traditional “Waterfall” and Agile-Scrum methodologies with regard to the development of new software products. The examples are based on over 15 years of “real-world” software development experience by the author, as well as, an overview of what worked and what didn’t work.

1. Waterfall Cycle Methodology
The so called Waterfall methodology has been advanced and used by most organizations since the mid 80’s. It is rich in a priori analysis and documentation. It usually entails very distinct levels of separation of responsibilities between the analysts, programmers, testers and customer/end-users. This is not necessarily always the case, especially with very small organizations; however, the processes; customer requirements’, analysis, programming, testing and release usually follow a very sequential pattern.
The main purpose of the waterfall method is to gather as much knowledge upfront about “what” the product is to be and which risks might constrain its over-all development. One major criticism of these processes is that they usually consume a relative large amount of time with regards to the total projected duration of the product development plan. Usually these processes neither increase total product knowledge nor identify enough substantial risks proportional to the amount of time invested. The major problems that often surface only during implementation of the actual programming phase are impossible to document in the analysis phase. Another more worry some problem is that the “what”, the product to be built, is not the same “what” that the end users really want, or as it is sometimes referred to as the “Big Bang” at the end of the production cycle. After performing all the detailed analysis of user requirements and satisfying all identified risks, the one risk that was not removed was the risk of user or even market (in the case of a new software product), rejection. Perhaps so much time had elapsed since the initial requirements were taken that they were no longer valid when the product was released. This so called “Big Bang” at the end of the production cycle is a very real concern which cannot be easily mitigated because of the inherent nature of the waterfall methodology. There have been many suggestions on how to improve the process, however, the core problems with the waterfall methodology, decentralized processes, lack of effective communication, etc., are difficult to over-come in larger organizations.
It must be noted that many criticisms of this methodology focus on the organizational intra-departmental rigidity of the implementation. With a small team, comprised of analysts, designers and programmers who all have adequate communication between the members and a common product overview it is possible to successfully develop a software product following the waterfall methodology.

2. Agile-Scrum Methodologies
Although the use of Agile methodologies for software development has been advocated for almost 10 years the basic lack of understanding and skepticism of the tenets of Agile by many programmers and managers has hampered their implementation in larger organizations. The goal of Agile is to break down the organizational impediments that constrain self managing teams. This is anathema to the “command & control” mentality in many large organizations. This is one reason why organizations with a dedicated, competent IT department find it impossible to develop software that is required within the organization. Instead they are forced to rely on smaller, “leaner” third party companies for their software needs.
In the waterfall method, knowledge about the product and the accounting of the risks are determined (where possible) upfront at the beginning of the product development. Agile confronts the problem of product knowledge acquisition and risk avoidance by limiting the development to more or less strict time iterations or time boxes, where the goal at the end of each time box is a workable piece of software. In this way product knowledge and associated risks are dealt with over a smaller scope of the total product. This has the benefit of avoiding unnecessary analysis which may not have been required and focusing directly on the immediate knowledge and risks associated with the development at hand.
The new comer in the Agile arsenal of productivity tools is Scrum. Scrum encourages the creation of self-managing teams, whose members should be co-located. Open verbal communication between all team members and disciplines that are involved in the product development is a major tenant of Scrum.
One of the principles of Agile-Scrum is the emphasis on the “How” and not the “What” in product development or in other words the planning process and not the plan. Another major tenant of Agile-Scrum is how it deals with the inevitable change in product requirements. Scrum embraces change as a natural part of the planning process. This is in complete contrast to the traditional waterfall methodology which abhors change after the initial analysis of requirements.

Referenten:

Ross Inglish is currently responsible for International Customer Support for Can Do GmbH. Served over 10 years as civilian Computer Systems Analyst and Information Management Officer (IMO) with the 18th Military Intelligence Battalion, 66th Military Intelligence Group, Intelligence and Security Command (INSCOM).  This involved coordinating both civilian contractors and military personnel on various programming projects. Joined Can Do  in 2001 as one of the original java developers of the project management software, “can do project intelligence”which won the German Innovation Prize in 2007 and 2008 and the Bayern Export Prize in 2008.