Agile Scrum Methodologies Tutorial

2.1 Agile methodologies

Welcome to lesson-2 of Simplilearn’s Agile-Scrum training program. In this Chapter, we shall introduce a number of Agile methodologies, before we dig into the Scrum methodology. The idea behind doing this is to make sure that you are aware of best practices from a wide variety of methodologies. There is no RIGHT or WRONG way of doing Agile or Scrum, you should feel free to mix and match practices that make sense to you. Let us first look into the agenda in the next slide.

2.2 Agenda

Let us now look at the agenda for this Chapter. We start off with a quick overview of the more popular Agile methodologies. Then we look at some features of the following. -Crystal -Extreme Programming -DSDM -Feature-Driven-Development -Agile Unified Process -Scrum (a brief preview before we dig deeper in the subsequent chapters) - Now, we will proceed to the next slide to start with the Agile methodologies. -

2.3 Agile Methodologies

Let us take a look at some of the Agile methodologies that are prevalent in the industry today. Some of the Agile methodologies are known to advocate a very simple and flexible process. These are classified under the light-weight portion and include methodologies like Scrum, Crystal and Extreme Programming. Some other approaches are slightly more “prescriptive” in their practices and are hence classified as fuller approaches, but they are also Agile – in the sense that they also advocate incremental and iterative development. These include methodologies like DSDM, Agile Unified Process or AUP and Feature-Driven Development or FDD. So within the Agile umbrella, there are a number of methodologies and practices that are available to you to choose your own specific Agile flavor. Let us move on to the next slide which talks about the Crystal.

2.4 Crystal

The Crystal family of methodologies was invented by Alistair Cockburn (pronounced as Co-burn). Cockburn believes that software development is a game of innovation that is played by team members collaborating with each other. There are two main elements to Crystal – the collaboration and the innovation. Innovation is about both the product itself and also about the process. The process should be light-weight and heavily tailored to what makes sense for the particular team. To provide an analogy, Cockburn often cites the three stages of learning from martial arts coaching. Shu (or follow) is when somebody is trying to learn a new technique. At this point, the emphasis is on getting information, interpreting it and trying to put it into practice. Ha (or break) is when (after having practiced it enough) you try to discover the limitations to a technique or try to “extend” a technique. Ri (or leave) is when you go beyond merely following a specific technique, but you try and come up with your own technique which works best in your circumstances. This may involve inventing new techniques or blending from available techniques. In the next section, we will discuss about the seven properties of projects in Crystal.

2.5 7 Project Properties in Crystal

Crystal methodologies look at projects from many different dimensions. One of those dimensions is to try and understand the “properties” of a project that can make it successful. These properties are explained as follows. -Frequent delivery: This means Crystal projects should try to complete features as quickly as possible and deliver for pilot. - -Reflective improvement: This means Crystal projects should allow scope for frequent reflection (about the code or the process) to discover what is not working well and how it can be improved. - -Close Communication: Cockburn has very strong views about the role of communication in projects. One of his theories is that communication has to be “Osmotic”, i.e. team members should not only be as close to each other as possible to be able to have face-to-face dialogue, but there should also be opportunities to learn by “over-hearing”. They can choose to ignore whatever they over-hear (literally by being present near the conversation or by being copied on emails) or they may choose to act upon it. But you must create opportunities to improve communication between team members. -Personal Safety: This asks the question whether you make it safe for team members to fail occasionally (if they take a chance or make an honest mistake) and whether they feel safe to be able to voice disagreements. - -Focus: Excessive and disorganized multi-tasking is a big productivity sink. Projects should be able to always identify clearly the two or three most important things for the team. - -Easy access to expert users: The value of the system is realized only when the end users start using it or when their needs are reflected in the system. The team must therefore always be able to ask questions and get information from the end users, who will tell them what they really expect from the system. - -Technical environment: There is no replacement for good software engineering practices like configuration management, frequent integration and automated testing. A project must invest time and energy in ensuring that the technical environment is geared towards making it successful. -Next, we will talk about the samples of Crystal.

2.6 Samples of Crystal

Cockburn recognized the need for having multiple flavors of Crystal to suit different types of projects. In the Crystal terminology, these are called “Samples”. Crystal Orange works when the team is 30-50 people and each person has a clear job description. Crystal Clear is suggested when there is a small team, of 3-10 people who can be co-located. In between Orange and Clear, you may have Crystal Yellow or Orange Web (for web development). Each sample is backed up by references that spell out practices which have been tried out and which may work out. Ultimately the message Cockburn would like to give about Crystal is that any methodology is only as good or bad as you want it to be. The team essentially chooses a “starter methodology” and then tailors it through reflective improvement to best suit its particular situation. We will now go through Feature-Driven-Development, in the next slide.

2.7 Feature Driven Development

Feature-Driven-Development is a methodology that was invented in 1999 by Jeff DeLuca and Peter Coad while working on a large project. The methodology has 4 primary components: -4 Core values -Six roles -Five processes -Project tracking methodology Let us start with the core values. The 4 core values of FDD are as follows. -It is essential to have a “system” (i.e. a process) for building systems (products, applications) -Simple processes are better -The process steps must be such that every team member can easily see the value that they add (conversely if they do NOT see value, then it is not a good process!) -Good processes should move into the background, i.e. they should become part of habit or culture. Then they should get followed automatically and you do not even have to police or audit for compliance. In the next slide, we will learn about the Roles in FDD.

2.8 Roles in FDD

There are six primary roles in Feature-Driven-Development. Let us look at these. -Project Manager: He is the “administrative head” of the team. He essentially coordinates and orchestrates the activities on the team and maintains the “system” and processes of the project. - -Chief Architect: He drives the technical decisions within the team. He runs design workshops, drives technical roadmap and resolves technical issues for the team. - -Development Manager: He manages the development team and drives day-to-day development. Bear in mind that development here means all coding as well as testing – anything that is needed to get the job done. This role is sometimes combined with Project Manager or Chief Architect. - -Chief Programmers: Experienced developers, who lead small development teams. They are supposed to be hands-on and do work on development themselves. - -Class Owners: These are the individual developers who design, code, test and document features. They are called Class Owners because FDD advocates a strong object model and code ownership driven by the object model. - -Domain experts: These could be end users, client, sponsor, etc. They provide the end-user requirements, needs and clarifications that the team needs. Other supporting roles that may be useful in a FDD team could be as follows. -Domain manager -Release manager -Language guru -Build engineer -Toolsmith -System administrator -Testers -Deployers -Technical writers, etc. Let us now look into the figure which talks about the Processes in FDD in the next slide.

2.9 Processes in FDD

Let us understand the processes in a Feature-Driven-Development project. The processes that are required at a “project” level are: -Develop an overall model -Build a features list (aka requirements) -Plan by feature Then there are processes that are required at a “feature” level and get repeated for every feature. -Design by feature -Build by feature We will now understand the project tracking in FDD.

2.10 Project tracking in FDD

The tracking process within a project must take into consideration the project level and feature-level processes and the time assigned to complete them. Obviously the amount of time it takes will vary from project to project, but some ratios can be considered as “normal”. -Developing an overall model takes about 10% of the overall project effort up-front and another 4% on an on-going basis to make tweaks to the model as we make progress. -Building a feature list takes 4% initial effort and another 1% ongoing effort. -Planning by feature takes 2% initial effort and 2% on-going effort for changes to the plan. -The design and build portion of the project is where about 77% of the time is spent. - The next figure will help us to learn about Project tracking methodology.

2.11 Project tracking methodology

Here, we take a look at a typical project tracking sheet for a FDD project. As you might notice, all the tracking is done at a “feature” level. Larger features may be broken down into smaller features – the level of granularity being governed by how closely you wish to track the feature. At a feature level, you may want to track progress, defects or whatever else that you wish to keep tabs on. In the next slide we will discuss on FDD Usage Guidelines.

2.12 FDD usage guidelines

Let us now understand some of the guidelines regarding when FDD should be used and when it should not be. FDD is useful when: -The teams are between 10-250 developers -When there is a good set of talented resources -When the project is supported by a good object model FDD should NOT be used when: -There are less than 10 team members -Team is still on a learning curve or not familiar with object oriented programming concepts -When there is no “support” from the other stakeholders. - Now, we will talk about the Dynamic Systems Development Methodology (DSDM).

2.13 Dynamic Systems Development Methodology DSDM

DSDM is arguably the first incremental and iterative methodology to become popular. It was first published by the DSDM consortium in 1994. A revised version christened as Atern was launched in 2007. DSDM has a large community of followers and is especially popular in the UK. Some of the basic concepts in Atern are as follows. -Involvement of the end users in the development process ensures that the right product gets built -In a typical project, the requirements do evolve but the timescale tends to be fixed -The sooner you deliver, the faster you start getting the pay-back -DSDM believes in the 80/20 rule, i.e. 80% of the value in a project comes from only 20% of the features. Hence it is important to put the important features in early -Nothing is built perfectly the first time. Hence it is natural and proper that we deliver something early and continue to refine it over a period of time. - We will understand about Planning in DSDM Atern, in the next slide.

2.14 Planning in DSDM Atern

In the traditional project management approach, a typical product manager would ask for a certain set of features and ask the team to estimate the time and cost for those. Quality is not mentioned specifically and then depends upon the inter-play between scope, cost and time. DSDM believes in fixing the time and cost up-front and putting the onus on the customer to prioritize features that can be accommodated during this time. This is very important, because it ensures that the customers will put a lot of thought behind what features they ask for in that limited time and cost window. Another important feature of planning in DSDM is that quality is considered as non-negotiable. Let us now discuss on DSDM principles and techniques.

2.15 DSDM Principles and techniques

There are 8 principles and 5 techniques that are core to the DSDM methodology. Let us try to understand these. Principles: -Focus on the business need that is driving the project -Deliver on time. The sanctity of the “time-box” has to be maintained. -Collaborate as a team while building the features and collaborate with the stakeholders of the project -Never compromise on quality. In the DSDM philosophy, quality is non-negotiable. -Build incrementally, but make sure that as you go on building, the foundation is always firm. -Develop iteratively. Whatever you build, try to get feedback and learn from the feedback as well as from your own experiences. -Communicate continuously and clearly. Clear communication with the project stakeholders is important. -Demonstrate control and have good tracking mechanisms at all times. Techniques: The five core techniques are; -Iterative development, -Time-boxing – this means fixing the time available up-front and then planning based on what can be done within that time-box. -MoSCoW prioritization. This is a prioritization framework wherein the features have to be tagged as Must, Should, Could or Won’t depending upon where they are placed. -Facilitated workshops: These are useful for requirement elaboration, design storming, etc. -Modeling: DSDM advocates a lot of emphasis on modeling the system and staying true to the model.

2.16 eXtreme Programming

Extreme programming is described as a system of practices that are evolved by a community of software developers to solve the problem of quickly delivering quality software and then evolving it to meet the business needs. Notice the emphasis on the word “evolving”, which recognizes the fact that software development is indeed an evolutionary activity. Extreme programming is called extreme because of its tendency to take things to the extreme. For example: -If testing is good, then let everybody test all the time -If code reviews are good, then review all the time -If design is good, re-factor all the time -If integration is good, integrate all the time -If simplicity is good, do the simplest thing that might possibly work -If short iterations are good, make them as short as possible. - -Next, we will learn about XP values.

2.17 XP Values

XP values are the foundational philosophies on which the methodology is based. The 4 core values of XP are as follows. -Communication: Communication among the team as well as between the team and the customer is important. -Simplicity: XP places a lot of emphasis on keeping things simple. This means avoiding over-engineering and trying to unlock value quickly by delivering something (even if it is rudimentary in nature). -Feedback: Feedback helps to keep the team moving in the right direction and on the other end it reassures the customer that the team is building the right product. -Courage: Courage is required to follow the right processes and practices. Developers in XP take courage from the fact that their practices are going to guarantee basic hygiene on the project.

2.18 XP Practices

Extreme programming is well known for its engineering practices. These practices can prove to be valuable in all forms of software development projects. Let us try to understand some of these practices. -Planning game: This is a collaborative approach to planning, where the customer is allowed to steer development based upon the estimates given by the team. This approach relies on keeping the plan flexible. -Small releases: Like all the Agile methodologies, XP relies on making small releases and unlocking value quickly for the customer. -Metaphor: Metaphor means analogies – finding a comparable artifact or concept to relate to. Metaphors are needed to clarify requirements, designs and to come up with plans. -Simple design: Simplicity is greatly emphasized in XP. The focus of the team should be to solve problems using the simplest possible approach. -Testing: Testing early and testing often is important. Extreme programming in fact advocates a test-driven approach to development, where a set of automated tests are written first and only then is the code written. -Refactoring: “Continuous refactoring” is encouraged in Extreme programming. Refactoring is essentially optimizing the code without changing functionality. The optimization could be for simplification, readability, performance improvements, maintainability, or to benefit any non-functional aspect of the code. This essentially means that every code change is an opportunity to optimize and should be utilized to the fullest. Refactoring should not be deferred as it might get missed forever. -Pair programming: Extreme programming teams often rely on two programmers pairing up to share a terminal for working. One of the programmers does active coding and the other one review what is being written from the point of view of correctness, completeness, efficiency, etc. -Collective code ownership: Collective code ownership refers to the fact that each line of code needs to have multiple people familiar with it. This ensures continuity in the work and helps with succession planning. -Continuous integration: Continuous integration means that code is compiled, built and integrated with the mail code line at all times. Each code check-in triggers a build and a bunch of automated tests to make sure that the functionality is working properly and there are no major regressions. -40 hour week: Many software engineers would love this! Extreme programming does not necessarily prohibit working over-time, but it does recommend that if you need to rely on over-time frequently, you need to re-visit your estimation and planning processes. -Onsite customer: In an XP project, the customer is represented by a person who is “onsite” or collocated with the development team. Having the customer onsite is invaluable for the team as they can ask questions, bounce off ideas and get priority decisions in real time. -Coding standards: Working in short bursts and making frequent releases mandates that a certain amount of discipline needs to be followed in the coding practices. One of this is that you need to follow coding standards. The standards should not be merely cosmetic and ideally you should be able to check for standards compliance automatically using static code analyzers. -Open workspace: XP teams would often work in a uniquely designed workspace that is optimized for communication by removing partitions and making the space as open as possible. -Daily schema migration: This means that the code and the schema used is updated and migrated on a daily basis. Nothing is allowed to be kept on the developers machines and in checked out condition. This inculcates discipline in terms of writing code in a way that ensures correctness at all times. Let us now look at the WP benefits, in the next slide.

2.19 XP Benefits

Let us try to summarize why Extreme programming (even though it is extreme) makes sense in a number of situations and the practices are valuable even outside of the methodology. The team gets clear, prioritized requirements at all times. It makes technical decisions and follows best practices to ensure good quality. The team is also highly motivated because the light-weight nature of the process and the fact that they are working in a technical, innovative environment. The team is also not over-worked and hopefully will enjoy a good work-life balance. The customer would end up getting the business value fast as a result of early and frequent deliveries coming through. The customer gets good feedback from the team about how well they are following the requirements and the customer will be able to focus on the business decisions that they need to make. Of course XP encourages a fun way of working and good team environment. We will go through Agile unified process next.

2.20 Agile Unified Process

Agile unified process is based on the rational framework and the rational unified process. Rational Unified Process or RUP is a method for managing object oriented software development projects with the following best practices in mind. -Develop iteratively, the prioritization being driven primarily by risk (risky features first) -Manage requirements closely -Employ component-based architecture and object oriented modeling techniques -Model the software visually (using Unified Modeling Language or other visualization tools) -Continuously verify quality -Control changes Let us continue this topic in the next slide.

2.21 Agile Unified Process AUP

The unique differentiator of the unified process is that it looks at the software development project from three different dimensions. Let us try to understand these. Life-cycle: The life-cycle of a project consists of 4 distinct phases. These are Inception (when an idea is generated), Elaboration (when the idea is translated into a set of requirements), Construction (when the requirements are built and become real) and Transition (when the project is completed and transitioned to a supporting or operational function). Engineering disciplines: During any software development project, there are six engineering disciplines that must come into play. These are Business modeling, Requirements, Analysis and Design, Implementation, Testing and Deployment. Supporting disciplines: There are three important disciplines which under-pin the success of a software development project. These are Environment management, Configuration and change management and Project management. Let us move on to the next slide and look into the diagram which describes Agile unified process – system development.

2.22 Agile Unified Process System Development

This diagram shows the overlap of the engineering disciplines over the life-cycle phases of a software development project. Notice that the engineering activities tend to extend over multiple life-cycle phases. For instance, Business modeling starts off during the Inception phase, extends through the elaboration phase, then tapers down, but there is a finite amount of business modeling activity right till the transition phase. Likewise, each engineering discipline spans across multiple phases. This is both natural and desirable. Also notice that in its pure form, the Rational Unified Process can support both traditional waterfall models (wherein the life-cycle activities would be all sequential) and iterative models wherein development is carried out over multiple iterations. Each of the iterations typically contains a slice of all the different engineering disciplines overlapping to produce some output. For instance, C1, C2, C3 and C4 are iterations in the construction phase. You could very well have just one iteration that covers all the construction activity, or you could develop it iteratively. In the next slide, we will discuss on scrum.

2.23 Scrum

At this point, let us introduce the Scrum methodology. It is an Agile methodology with specific practices built around small, self-managed teams working towards a software development project. The methodology was founded by Ken Schwaber, Jeff Sutherland and Mike Beedle. The authentic sources for getting Scrum guidelines and white papers are the Scrum Alliance website (www.scrumalliance.org) or Ken Schwaber’s website (www.scrum.org). The term Scrum itself originates from the sport of rugby, where the Scrum is the team huddle just before the beginning of a new “play”. The daily stand-up meetings (one of the Scrum rituals) are sometimes referred to as the Daily Scrums. Many Scrum terms are borrowed from rugby. Scrum is one of the most popular among the various Agile methodologies in vogue. There is significant demand in the industry for Scrum aware and Scrum certified professionals. Let us now proceed to understand some of the certifications out there for Scrum and Agile professionals. Now, we will understand Scrum life-cycle.

2.24 Scrum Life cycle

Let us look at the Scrum life-cycle. The software is built in response to inputs (or requirements) voiced by a wide variety of stakeholders. These could be customers, end users, subject matter experts, developers, etc. It is the job of a person, who plays the Product Owner role to collate all these inputs and turn it into a “backlog” of requirements. The backlog consists of all the things that the team could do for the customer, ranked in priority order. Once you have the backlog, you are ready to start working in Sprints or Iterations. A Sprint is a short duration milestone (typically 1 to 4 weeks long) in which the team takes a sub-set of the product backlog and tries to bring it to a near releasable state by the end of the Sprint. The sub-set of the product backlog that the team commits to complete within a sprint is called the Sprint backlog. During the Sprint, the team works together to produce the next increment of the software and tries to bring it to a level of quality that is near releasable or potentially shippable. Indeed the whole estimation and planning process is based on the philosophy of near releasable code at the end of each Sprint. At the end of the Sprint, there are two important Sprint rituals – the Review and the Retrospective. The review is a meeting that takes stock of what the team has built during the Sprint in the form of a working demo. The retrospective is a “lessons learnt” meeting where the team tries to draw lessons from the past Sprint and use it for planning subsequent Sprints.

2.25 Quiz

Let us quickly test our understanding of this Chapter through this quiz. Which methodology is known for frequent releases, reflective improvement and osmotic communication? A-XP B-Scrum C-Crystal D-None of the above Answer is C: Osmotic communication is a feature of Crystal methodologies. What the correct order of the life-cycle phases is as described in the Rational Unified Process? A-Inception, Elaboration, Construction, Transition B-Transition, Inception, Elaboration, Construction C-Elaboration, Inception, Construction, Transition D-Construction, Transition, Elaboration, Inception Answer is A: The four life-cycle phases are inception, elaboration, construction and transition. What is the ideal team size in Feature-Driven-development? A-10 to250 B-3 to 10 C-7 + or- 2 D-Up to 10 Answer is A: FDD teams can have 10 to 250 team members With which methodology would you associate the 80-20 rule? A-Extreme programming B-DSDM C-Crystal D-Scrum Answer is B: DSDM makes use of the 80-20 principle – that 80% of the value comes from 20% of the features. We thus end this lesson on Agile Methodologies. We hope that this has been a pleasant experience for you. Let us move on to the next lesson. The next part covers lesson three of this course which is about Scrum Roles. Happy learning!

  • Disclaimer
  • PMP, PMI, PMBOK, CAPM, PgMP, PfMP, ACP, PBA, RMP, SP, and OPM3 are registered marks of the Project Management Institute, Inc.

We use cookies on this site for functional and analytical purposes. By using the site, you agree to be cookied and to our Terms of Use. Find out more

Request more information

For individuals
For business
Name*
Email*
Phone Number*
Your Message (Optional)

By proceeding, you agree to our Terms of Use and Privacy Policy

We are looking into your query.
Our consultants will get in touch with you soon.

A Simplilearn representative will get back to you in one business day.

First Name*
Last Name*
Email*
Phone Number*
Company*
Job Title*

By proceeding, you agree to our Terms of Use and Privacy Policy