The Agile methodology and its frameworks

Revision as of 20:56, 26 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]

These three tools represent an important support for project management as they provide a valid guidance for the application of the Agile methodology in different contexts.

After a short introduction regarding the Agile movement, each tool will be discussed both theoretically and in the context of a business example of real case; they will be compared and critically evaluated.

Introduction to the Agile movement

Background

In the spring of 2000, some Extreme programming adepts met and discussed about several “Light” methodologies. During the same year, in 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, at the beginning of the following year, when the Agile movement was officially created. 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 traditional iron triangle of project management, also called triple constraints of project management, is formed by scope, schedule and budget which represent the criteria for performance measurement. On the contrary, according to the Agile principles, success can be assessed through the value (to the customer), quality (in order to continue delivering value to the customer) and constraints (scope, schedule and cost). ^[8]These three elements constitute the Agile triangle, shown in picture 1.

Picture 1: the traditional iron triangle and the agile triangle

The agile methodologies help companies to react to unpredictable events through an incremental and iterative process and empirical feedback.^[9] 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.^[10]

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.^[11]

Application

Scrum

The tool

Scrum is an incremental method, as shown in picture 2, 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] Scrum is a very structured methodology and includes several rules, such as fixed roles for the team members and typical meetings to gather the employees.

Picture 2: The mechanism of iterations

Teams and roles

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.

Events

The scrum methodology mandates four types of meetings: sprint, sprint planning, daily scrum, sprint review.

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.

Moreover, 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]

Business example

Scrum can be used in various different industries and fields, and not only in software development. A research conducted in a company, operating in the automation industry and that adopted this methodology, shows many positive results after the implementation: Scrum has improved the visibility of the status of the project and accelerate the management of changes. It has also improved team communication and knowledge management and increased commitment to the goals. ^[14] In particular, the application of scrum helped solving the following issues:

• Big projects lead to high risks: through the introduction of sprints, planning and control activities are easier to manage.
• Difficult communication between different sites: the use of roles (e.g. scrum master, product owner…) enabled a more efficient communication between sites and within the same site.
• Difficult data management: handling the correct flow of documentation, excel sheets and data is complicated. However, through the utilisation of tools like the product backlog, all the required information can be easily found.
• Lack of visibility of the project’s progress: the adoption of Sprints allowed the visualization of the status of the project.

Kanban

The word Kanban has its origin in Asia, and the translation is “signboard” from Japanese and “looking at the board” from Chinese. Originally, Kanban was a tool to control inventory developed by Taiichi Ohno and linked with the concept of Just-In-Time production. In project management, it is a system that allows visual control over the project and consists of two main elements, the Kanban board and the Kanban cards. The Kanban board is divided into columns: the minimum number is three, corresponding to input queue, working and done. The Kanban cards usually contain the activity that has to be performed and indicate the priority of the task through a different colour or type of card.^[15]

The tool

The kanban methodology can be customised and practically applied through five steps ^[16] , shown in figure XX.

Picture 2: Five steps to implement Kanban

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.

Picture 3: An example of routine activities about improvement of products and infrastructures

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.

Once the routine steps are identified, a Kanban board should be created. Picture XX shows an example: it is formed by the columns Backlog, Specify, Implement and Validate.

Picture 4: An example of a Kanban board

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. For the Kanban, 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.

Business example

Siemens Health Services, a company that provides IT solutions to hospitals and physicians, implemented Kanban and gained relevant and sustainable improvements in terms of predictability, efficiency and quality. The main obtained benefits were the following:

• Higher visibility of the project big picture
• Through the use of Kanban and the cumulative flow diagram, the management team balanced the different steps of the process: they discovered that the throughput in the developing phase was higher than the one in testing, so they decided to include a higher test automation
• Identified waste, variability and bottlenecks
• Creation of a more collaborative environment and higher engagement of the teams
• Decreased cycle time through the limitation of WIP and increased throughput; once the cycle time became more predictable, they improved the accuracy of release forecasts ^[17]

Extreme programming

Extreme programming is one of the agile processes and its first program started in 1996. It is based on the idea of delivering what the customer currently needs instead of working on all the possible features that will be needed in the future. Extreme programmers constantly sustain communication with the customer, keep their design simple, get feedback through the regular and frequent testing phase. Picture XX shows some simple rules for implementing extreme programming.

//Add a picture with the rules//

The tool

Extreme programming is based on twelve core practices that guide programmers in the right way for implementation:

1. Metaphor - a story guides the team telling how the system works. The metaphor is substituting the usual traditional models and procedures.
2. Planning game - the end users define the characteristics of the output through a story. The programmers prioritise the tasks depending on their complexity, importance and time required. They plan to process the most complex one at the beginning in order to mitigate the risks.
3. Small releases - the customer is regularly and continuously informed and involved in the process through small releases, delivered every two to three weeks.
4. Simple design - the programmers deliver exactly what the customer currently needs. Simple design also decreases complexity.
5. Testing - testing is continuously performed, from both the customer and programmers side.
6. Refactoring - the system is restructured in order to remove duplication, simplify the code and improve the flexibility without changing the way the code works.
7. Pair-programming - two programmers are working side by side in order to provide feedback and discuss each other’s work.
8. Collective ownership - Every programmer is allowed to change any other code from another programmer. Some studies showed that the implementation of this method decreases the number of bugs in the system.
9. Continuous integration - The code is integrated and tested very often, after a few hours or a day maximum. In this way, all the potential problems and responsible can be quickly identified.
10. Forty-hours workweeks - it is strongly recommended that programmers work 40 hours per week. If necessary, they can exceptionally work overtime, but it would not be accepted for two weeks in a row.
11. On-site customer - a customer representative is working with the team and is available to answer questions about the system and solve issues.
12. Coding standards - it is necessary that all the programmers in the team adopt the same standards. These standards can also be written in collaboration with the team in order to find the more suitable ones.

Business example

Extreme programming technique can be conveniently applied in many contexts. For instance, Knublauch et al. presented the development of a clinical multi-agent system through the use of extreme programming. An agent is an “encapsulated computer system that is situated in some environment and is capable of flexible and autonomous action in order to meet the objective of its principal” ^[18]; in the area of clinical information system, the agents can be useful sending critical patients’ data to the doctor at the right time.

The application of extreme programming was decisive for different reasons:

• The use of coding standards facilitated shifts of the implementation tasks between people;
• Simple designed helped maintaining the design stable during the project;
• The application of continuous integration and small releases eliminated almost completely the integration problems;
• Communication problems and misunderstandings linked to the different languages doctors and programmers have, were solved through the metaphor (in this case, a transposition of clinical concepts into engineering processes).

Comparison

The three methodologies can be compared in several aspects.

Control:

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. Kanban approach limits chaos by establishing a maximum WIP in each phase. Extreme programmers adhere to a precise set of defined standards, decided among the team members.

Rules:

Scrum methodology imposes many rules about the team meetings and roles, but leaves the development team the freedom to choose how to perform the task. Extreme programming includes a lot of standard procedures, while Kanban is less prescriptive.

Resources:

Kanban can be adopted by co-located teams - the proximity to the Kanban board is of the utmost importance - and when the items in the backlog are frequently changing. The limitation of WIP is convenient in case of limited resources or when an input from each team member is required in each item. Co-location is important for Scrum, but it represents a fundamental prerequisite for Extreme Programming, due to the pair programming and the involvement of the customer in the process.

Time:

Kanban keeps track, analyzes and optimises the cycle time through continuous improvement. Scrum aims at improving the output and velocity of the team in the following sprints. For this reason, Scrum may be more suitable for scaling in large organizations.

Meetings:

Scrum mandates the sprint planning meeting, daily stand up, sprint review, sprint retrospective. Also Kanban and Extreme Programming require a daily stand up meeting.

These three methods adhere to the Agile principles but can be applied in different contexts: Kanban is suitable when the items in the backlog are frequently changing and efficiency can be increased through the limitation of WIP, maintaining the existing roles and responsibilities at the same time. Scrum can be adopted by teams that devote their time to a project or product, and that need to be really structured in order to increase productivity, while having the freedom to choose how to engineer the processes. Extreme programming is deeply focused on delivering a high-quality output to the customer through a set of core engineering practices that guarantee simplicity but also customer satisfaction.

Limitations

Agile frameworks are applicable only in certain contexts: for instance, not for a construction of a car or a plane, but it is suitable for software development and in many other contexts. Scrum, Kanban and Extreme programming are extremely useful to manage a project, but their application includes some limitations, here sorted according to the different tools.

Scrum:

• Prioritization of short-term solutions
• Lack of future vision: developing large scale companies in a highly regulated environment (e.g. healthcare) need to provide accurate release forecasts
• Lack of visibility
• Non conformance of large feature in one sprint ^[19]

Kanban:

• There could be bottlenecks due to the absence of regular deadlines
• Not enough control over the release
• Big features are not split into smaller ones so it might take long time to be developed
• Training and education must be carefully managed ^[20]

Extreme programming:

• Deep customer involvement: while the client engagement can assure that the delivery matches the expectations and needs, in some cases it could be difficult to require the total devotion of the customer to the project
• Lack of proper documentation, that can create critical situations in case of new programmers

Annotated bibliography

• Agile Project Management: Creating Innovative Projects, Highsmith Jim, 2009

Jim Highsmith has a long experience as project manager, IT manager, product manager and software developer. He is one of the founders of the Agile Alliance and a co-author of the Agile manifesto.

In the first part of “Agile Project Management: Creating Innovative Projects”, he clearly defines and describes the Agile methodology and compares it to the traditional waterfall method for project management. Then, he deeply analyses the principles contained in the Manifesto (individuals and interactions over processes and tools, customer collaboration over contract negotiation, responding to change over following a plan, working software over comprehensive documentation).

• Critical chain project management, Leach, L. P., Artech House, 2014

In the first chapters, Lawrence P. Leach discusses the motivations that can lead a project manager change his way of planning and delivering a project. A relevant part of the book is committed to the description of Kanban and its applications. First, he briefly illustrates its origins; then, he shows the use and the main features of the Kanban board with the support of examples. He also applies some of the Kanban principles to Critical chain project management. Finally, he guides the application of the methodology with easy and practical steps, both for single - project and multiproject organizations.

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. ↑ Agile Project Management: Creating Innovative Projects, Highsmith Jim, 2009
9. ↑ http://agilemethodology.org/
10. ↑ http://agilemethodology.org/
11. ↑ Making Sense of Agile Project Management: Balancing Control and Ability, G. Cobb, Charles, 2010
12. ↑ http://scrumreferencecard.com/scrum-reference-card/
13. ↑ The Scrum Guide, Schwaber and Sutherland, 2011
14. ↑ Patterns for Distributed Scrum - A Case Study, Välimäki, A., Kääriäinen, J.,
15. ↑ Critical chain project management, Leach, L. P., Artech House, 2014
16. ↑ Agile Project Management with Kanban, Brechner Eric,
17. ↑ Kanban at Scale - A Siemens Success Story, Vallet, B., 2014
18. ↑ Agile Development of a Clinical Multi-Agent System: An Extreme Programming Case Study, Knublauch et al., 2002
19. ↑ Developer-driven big-bang process transition from Scrum to Kanban, Nikitina, N., Kajko-Mattson, M., International Conference on Software and Systems Process, 2011
20. ↑ Developer-driven big-bang process transition from Scrum to Kanban, Nikitina, N., Kajko-Mattson, M., International Conference on Software and Systems Process, 2011