Iterative teaching – 2 iterations

Lecture Notes

Orit Hazzan & Yael Dubinsky

Week 1 - Introduction

In this lecture the course overview is presented and its main objectives are outlined. The rationale for the course structure, in both the lecture column and the studio column, is also explained to the students.

With respect to agile development, the Agile manifesto in presented and its implication of the nature of agile software development environments is elaborated. It is emphasized that the course is neither a programming course nor a technical oriented course (no IDEs, for example, are presented); rather, the course looks at a new paradigm of software development – agile software development – trying to convey the idea that, in fact, technical problems related to software development have been already overcome and that the focus should be placed now on the management of human aspects of software development processes. As the Agile Manifesto highlights – this is one of the core ideas of agile software development processes.

Week 2 – Forming Teams

This week is dedicated to one of the main ideas of agile software development environments. It discusses how teams function in agile software development environments and how agile teams achieve their targets by different techniques. The technique highlighted in this lecture is a role scheme, according to which each team members has an additional role in the team in addition of being a software developer. As it turns out, such a role scheme enhances creativity, responsibility, accountability, diversity, and measure collection. Further, such a role scheme fosters the message that each team member has what to contribute to the software development process and that the mutual contribution of each individual in the team creates a whole which is greater than its parts. Other ways by which agile teams achieve their targets, such as measures, are discussed in future lessons.

Week 3 - Planning

It is a very well known fact that many software projects are not delivered on time and run out of budget. This lesson focuses on planning and explains how, by adopting several practices, agile software development environments enable to overcome this characteristic problem of software development processes. The core idea of this lesson is short releases, supported by tight time management and sustainable pace. In practice, it implies that after having a global picture of what is to be developed, each planning session addresses a very short period of time (one or two weeks) on a very detailed level (including time estimation in hour resolution) in which we make sure not to overcommitted and to develop the software in a sustainable pace. In this lesson, the agile planning process is outlined and the way it helps overcome the specific problems is software project planning is analyzed.

Week 4 - Customer

This lecture focuses on one of the main changes that the agile approach introduces into software development environments in general and developer conception in particular. Specifically, this talk examines the customer role in agile software development processes. As it turns out, the customer role in agile software development environments is central and is based on an on-going communication between the customer and the developers, both with respect to the requirements as well as with respect to the way their implementation is checked. This communication is established with the aid of several practices, one of which – the planning game – has been mentioned in the previous lesson. Another practice that fosters customer-developer communication is the metaphor – a means that bridges the gap (if exist) between the customer and the developers worldviews. As it turns out, not only the customer role is supported by several practices, it also fosters by itself other features of agile software development, such as knowledge sharing.

Week 5 - Measures

One management mechanism of agile software development processes is measures. This implies that the entire software development process is controlled and monitored by a set of measures, some of them are determined by the team and some – with customer collaboration. These measures should be as simple as possible to enable their actual measurement as well as their interpretation by the different players in the development process for the sake of process improvement. As agile software development requires constant feedback from the different ingredients of the software development environments (people and code), only several measures should be taken; however, they should be taken on a daily- or iteration- basis to allow them to reflect back, as often as possible, on the process progress. As agile software developments are ready for changes, it is possible that these measures are altered from one project to another as well as between different iterations of the same project. One general rule, however, which is derived directly from the Agile manifesto, should be remembered: these measures should support and assist the individuals involved in the software development process and should not be taken for other purposes.

Week 6 – Testing

Testing is another way by which agile software development environments control the development processes and reduce risk. The introduction of heavy testing early in the development process, during the entire software development process, ensures that the team, as well as the customer, be sure at each step that the software developed so far is correct and bug-less, both from the technical perspective as well as from the functional perspective. This perspective implies a change in team structure in several ways. For example, this process implies that testers are an integral part of the team; not a separate team that gets input from the development people and outputs back bugs to be corrected by the developers. Further, it implies that the regular tension between testers and developers is reduced. Furthermore, testers' low status, that can be identified in many software organizations, is eliminated within such a process. These changes reflect once again the important attributed to people in agile software development processes.

Week 7 - Refactoring

In this lecture the role of refactoring is highlighted from the cognitive perspective. Refactoring will be presented as a cognitive tool that supports gradual knowledge construction with respect to code design and readability. The importance of refactoring is derived from several reasons, three of them are presented here. First, it is well known that software comprehension is hard task. In many cases developers can't cope successfully with code that has been written by others and even by themselves. By allowing an on-going improvement in the code readability, without adding functionality, during the actual code development process, refactoring increases code readability. Second, even in cases where it is acknowledged that there is a need to improve code readability, when specific time is no allocated for this purpose, refactoring is tended to be skipped. Agile development processes, by their tight and ordered planning process mentioned above, further legitimate refactoring by allocating time for this activity of code improvement. Third, with respect to code design, in many cases the code design is not similar to the design that has been shaped originally. Refactoring enables us to address this gap between the code and its design on a regular basis. Similar to testing, the fact that refactoring is specifically integrated into the development process, highlights, this time from the cognitive perspective, the importance attributed to the developers in agile software development process. Once again, and in a similar way to other agile practices, refactoring is not an isolated element: on the one hand, it supports other agile ideas, on the other – it is supported and enhanced by other practices.

Week 8 – Intermediate Review

This lesson starts the second iteration of the lectures and reviews what we have seen so far in the course and what we will see in the following lectures. The idea is to summarize the ideas presented so far into one comprehensive picture which captures the spirit of agile software development environments and to serve as an introduction to the second iteration of the course in which, on the one hand we delve into more details, while on the other hand we put agility in a wider context. The main idea presented in this lecture is the new paradigm that agile software development introduces into software development processes. Specifically, while before the agile movement emerged it had been accepted that software development processes behave in a similar manner to the development of other (tangible) artifacts and therefore inspires a linear process, the agile approach towards software development inspires a more intertwined process, in which the different typical activities performed during a software development process (design, coding, etc) form a network oriented image. The question that should be naturally asked is, why this different image is needed for the case of software development? Why the linear model of software development process had to be changed in order to cope with the typical problems of software development? To answer these questions, this lesson explores the nature of software, the need to develop software in a unique way and the way agile development provides solutions to the typical characterized problems. For this purpose some of the main agile software development methods are described.

Week 9 - Cognition

In this lesson we revisit agile software development processes from a cognitive perspective. Specifically, we examine the notion of reflection, a process through which we rethink what we have done so far and learn the lessons derived from such an examination. Since any creative process requires such a reflection process, an agile development process does integrate reflection processes in a very systematic way. In this lesson we view several ways by which we can conduct reflections, the benefits we may gain from the performance of reflection, and the potential influence of reflection processes on software development. To illustrate the main ideas and to put the notion of reflection in a more concrete context, we work in this lesson on several case studies.

Week 10 – Forming teams – Reward allocation

In the second week of the semester we discussed how agile software development approaches the creation of teams. In this lesson we visit this topic again, focusing on how agile methods support teamwork and collaboration among teammates. This is done by discussing why in many cases software teammates tend not to collaborate, and how the agile approach fosters collaboration. This is accomplished by viewing agile processes from game theory perspective. For this aim the Prisoner Dilemma framework is discussed and it is shown how an agile software development process eliminates the conflict involved in such situations by ensuring team members cooperation.

Week 11 – Pair Programming

This lesson focuses on pair programming – one of the important features of team work. Its importance is derived from the fact that this practice, which asserts that actual software development should be conducted in pairs, supports the development process form a cognitive, as well as social, perspective. Generally speaking, we may say that pair programming partially replaces code review processes conducted in traditional software development processes. However, it has more merits. First, it helps developers stay focused during the actual development. Second, in each pair programming session each piece of code is reviewed by two programmers. Third, it guides a process during which each piece of code is viewed on two levels of abstraction. Fourth, it fosters knowledge sharing. Despite all these benefits, pair programming raises some resistance, partially because it is misinterpreted. In this lesson we delve into the way pair programming should be carried out, exploring how it contributes to the development process both on the individual level and the team level.

Week 12 – Agility -A management perspective

In the next two weeks we examine agile software development from a wider perspective. In this week we first examine agility from the management perspective and then, next week, we will look on the impact of agility on the organization level.

As just mentioned, in this lecture we examine the concept of agility from the management perspective. It is well known that many software projects do not meet deadlines, and the relevant question to be asked is why this happens in software projects. In this lesson we gather all the principles and practices we have met so far in the course into a managerial framework, and illustrate how agile projects management, supported by different practices, provides an alternative framework for software project management. Further, we show how the agile approach can be applied to any activity related to project management and how it provides all management level, at each moment, a clear overview and an updated status report of the development phase.

Week 13 – Organizational perspective

This lesson continues the previous one and examines agility on the organizational level. As it turns out, the introduction of agility into the organization welcomes other by-product influences. The first one is the openness to changes – a critical element in today's markets. Another influence, directly derived from the openness to changes, is that agile software development processes welcome diversity; therefore, an agile approach has the potential to increased diversity, which, according to existing evidence, further strengthens and promotes the organization.

Another important phenomenon discussed in this lesson is the connection between agile software development and off shoring and global software development.

Week 14 – Summary

In this lesson, in which we close the semester, we put all the ideas together and examine mutual connections between them. For example, we examine how the management perspective is influenced and influences the technical aspects of agile software development; we examine how the expression of agility on the team level is connected to agility on the team and the organization level, etc. Further, we examine the potential influence of agile software development on the software industry and the field of computing in the border sense. We also discuss students' experience in agile software development processes conducted in the studio and check how these performances can be improved.