The Agile methodology and its frameworks

Revision as of 12:55, 17 September 2016

Project management is the application of knowledge, skills, tools and techniques to project activities to meet the project requirement. ^[1] Traditionally, in order to manage a project, the sequential methods were largely used. According to these models, all the stages in a product’s life cycle are sequential. In opposition to these methodologies, the agile movement took place. The agile manifesto, published in 2001, summarizes the main principles of the Agile movement: individuals and interactions over processes and tools, customer collaboration over contract negotiation, responding to change over following a plan, working software over comprehensive documentation. Moreover, simplicity, which is the art of maximizing the amount of work not-done, is valued as an essential aspect. ^[2]

Many frameworks are linked to the agile movement. This article introduces and compares three of these agile processes: scrum, kanban and extreme programming.

Scrum is a framework based on a set of values, principles and practices.^[3] It is based on empiricism and it uses an iterative and incremental approach for risk control and predictability optimization. Scrum is based on three pillars: transparency, inspection and adaptation. ^[4]

Kanban is a project management techniques based on Toyota’s just-in-time scheduling method.^[5] This framework support the project work and facilitate the focus on delivering value to the customer.

Extreme programming (XP) is one of the agile processes and it focuses on delivering to the customer only what is needed. It is based on four core values - communication, simplicity, feedback and courage - and is implemented with 12 practices: planning, small releases, metaphor, simple design, testing, refactoring, pair programming, collective ownership, continuous integration, 40-hour week, on-site customer, coding standards. ^[6]

Introduction to the Agile movement

Background

In the spring of 2000, some Extreme programming adepts met and discussed about several “Light” methodologies. During 2000, a variety of articles about “Light” and “Lightweight” processes were written and started to spread. The first meeting in 2000 represented a sort of incubator for the second meeting. On February 2001, seventeen experts from different contexts - extreme programming, scrum, DSDM (dynamic system development method), adaptive, software development, crystal… - signed the Manifesto for Agile Software Development. The aim of this project was the creation of an alternative method to develop software, different from the documentation driven and heavyweight process that was commonly used. ^[7]

Principles

The agile methodologies help companies to react to unpredictable events through an incremental and iterative process and empirical feedback.^[8] It provides a way to measure the performance of a project throughout the development lifecycle through regular cadences of work, called sprints or iterations. At the end of each phase, the teams should be able to present a potentially shippable product increment and every aspect of the development is revisited.^[9]

Agile project management must involve not only the product development processes, but also the entire business. A lack of proper support from the business stakeholders would probably lead to the failure of the project.^[10]

-performance measurement: from the iron triangle of project management, also called triple constraints of project management, (Budget, Scope, Schedule) to the Agile triangle (Value, Quality, Constraints) ^[11]

Application

Scrum

Whereas in the waterfall development the activities are in sequence and a task cannot be performed until the previous one is not finished, the scrum method is based on an iterative process. Pictures 1 and 2 depict the different processes according to the two distinct methods.

The Scrum is an incremental method for product development and uses length-fixed phases, called sprints, that usually last one or two weeks and that represent one iteration. At the end of each iteration, the teams should deliver a potentially shippable product. ^[12]

The employees involved are organized in small teams which are cross- functional and self- organizing. The size of the teams is limited, the optimal number is approximately seven people.

According to this methodology, the Scrum team consists of three roles: the product owner, the development team and the scrum master. The product owner is in charge of maximizing the value of the product and the work of the development team. This process may differ, depending on the company, the scrum teams and the people. More precisely, the product owner is responsible for the management of the product backlog, which includes the following activities: listing all the product backlog items, ordering the items of the product backlog in order to facilitate the achievement of the goals, optimising the work performed by the development team, ensuring visibility, transparency and clearness of the product backlog, making sure the development team understands the items in the product backlog.

The development team is formed by experts with the role of developing the Increment that is released at the end of each sprint. These participants are the only one who can decide and manage the way to deliver their own work, which means that the teams are self-organizing. Another characteristic inìs the cross-functionality: it is decisive that the members have different backgrounds, skills and knowledge, in order to develop a complete Increment. All the team members are at the same level and no sub-groups can be formed. The different participants may have their own area of expertise but all of them are responsible for the group outcome.

The scrum master is engaged in ensuring that the scrum theory and principles are fully understood and that everyone is behaving and working in compliance to them. Moreover, he has the role to identify the not really helpful interactions and processes and to correct them.

The scrum methodology includes some events in order to ensure regularity. The sprint is a time frame lasting one month or less and, once it has started, it is not possible to modify its length. The conclusion of this phase is characterized by the delivery of a potentially releasable product Increment and the beginning of a new sprint is immediately following. If the sprint is too long, complexity and unpredictability increase.

Sprint planning is another fundamental phase for the scrum: the entire team is engaged in establishing a work plan for the sprint. The maximum duration for the planning of a one-month long spring is eight hours. During this session, the final delivery is outlined and the work needed to achieve this is decided by the development team through the choice of the product backlog items. Finally, all the team member select a sprint goal.

In order to maintain alignment and focus, the development team uses a daily scrum, which is a quick (15 minutes) meeting, held at the same time in the same place every day. Its goal is analyzing what has been done since the previous daily scrum and agreeing on a plan for the following 24 hours.

At the end of each sprint, a 4-hours sprint review is organized by the scrum master. A complete understanding of the purpose of the meeting is of the utmost importance as the Increment is evaluated and eventually the product backlog adjusted for the following phases.

After the sprint review and before a new planning, a sprint retrospective can occur. The scrum team should participate and assess the processes and tools, but also people and relationships in the sprint that is just concluded; it continues with a selection of possible improvements and a plan to carry them out.^[13] Example: it has been used for the development of semiconductors, mortgages, wheelchairs.

Kanban

//Theoretical introduction missing//

The kanban methodology can be practically applied through five steps. ^[14]

Step 1: Capture your team’s high-level routine.
A team usually performs a large variety of different works, but the Kanban is especially focused on the improvement of products and infrastructure. An example of a high-level routine for producing improvements is depicted in figure XX. (I’ll create the picture, now I have simply written it down)

Take an item from the backlog -> Specify the work necessary to implement it -> Implement it -> Validate that it works properly -> Deliver it to customers or partners

In order to keep the routine simple, only the steps performed by the team should be included and two sequential steps done by the same person should be merged. In general, very common routine phases are Specify, Implement and Validate.

Step 2: Redecorate your wall.
The word Kanban has its origin in Asia, and the translation is “signboard” from Japanese and “looking at the board” in Chinese. Once the routine steps are identified, a Kanban board should be created. It is formed by the columns Backlog, Specify, Implement and Validate, as shown in picture XX. It represents a support for the team because it helps to track and visualize the progress of the work through the use of note cards.

Step 3: Set limits on chaos.
Limiting chaos is a fundamental issue for project management. In the waterfall method, chaos is controlled by the precise planning of the work ahead, the change-request system and synchronization of the work of the different teams at predetermined milestones. In the Scrum approach, control is established by the sprint planning, the avoidance of changes during the sprint and the work adjustment in collaboration with the customer at the end of each sprint. For the Kanban, the process is easier: the amount of work in progress (WIP) is limited, which means that there is an upper limit for the number of note cards in each phase. This constraint is useful in two ways: it limits the amount of projects that can undergo changes in priorities, requirements or design and it also regulates the pace of all the steps based on the pace of the slowest step. The goal for this step is to keep the lowest WIP level possible, still maintaining the team engaged in its task of delivering value to the customer.

Step 4: Define done.
As shown in figure XX, the steps in the Kanban board, except for backlog, have two columns each. Before a note card is placed on the second column of a step, it must have fulfilled certain requirements decided and discussed together with all the team members. The main reason for the double column in the step is to create clearness about the status of the process (done and ready to start a new step or actually starting a new step) and avoid misunderstandings.

Step 5: Run your daily standup.
Once the team has reached this step, it is ready to use Kanban. When the backlog is full of activities, no planning meetings, no sprints and no deadlines are required. The only typical meetings are the daily standup meetings, where eventually some issues can be discussed (for instance if team members are blocked in their tasks) and the activities are assigned to the different people. It is also an occasion to keep all the members updated about the ongoing activities.

Extreme programming

Comparison

Limitations

Comments

Work in progress. I would like to add a small company example in the scrum paragraph. I still need to add the images, fix the references and the annotated bibliography.

This paragraph will not be included in the article.

Annotated bibliography

References

1. ↑ A Guide to the Project Management Body of Knowledge, Fifth edition, Project Management Institute
2. ↑ http://agilemanifesto.org/
3. ↑ Essential scrum: a practical guide to the most popular agile process, S. Rubin Kenneth, Pearson Education, 2013
4. ↑ The Scrum Guide, Schwaber and Sutherland, 2011
5. ↑ Agile Project Management with Kanban, Brechner Eric, Microsoft Press, 2015
6. ↑ Introduction to agile processes and extreme programming, Newkirk, James, International Conference on Software Engineering, 2002, pp. 695-696
7. ↑ Introduction to agile processes and extreme programming, Newkirk, James, International Conference on Software Engineering, 2002, pp. 695-696
8. ↑ http://agilemethodology.org/
9. ↑ http://agilemethodology.org/
10. ↑ Making Sense of Agile Project Management: Balancing Control and Ability, G. Cobb, Charles, 2010
11. ↑ Agile Project Management: Creating Innovative Projects, Highsmith Jim, 2009
12. ↑ http://scrumreferencecard.com/scrum-reference-card/
13. ↑ The Scrum Guide, Schwaber and Sutherland, 2011
14. ↑ Agile Project Management with Kanban, Brechner Eric,