3

Agile Methodologies

INTRODUCTION

Frameworks and processes that are based on Agile manifestoes are called Agile methodologies or Agile methods.

VARIANCE IN AGILE METHODS AND APPROACHES

In this chapter, we will discuss the most popular Agile methodologies and will discuss the situations where each of these is most relevant.

Examples of Agile methodologies are:

  1. Scrum
  2. Extreme programming (XP)
  3. Test-driven development (TDD)
  4. Feature-driven development (FDD)
  5. Kanban methodology
  6. Dynamic system development method (DSDM)
  7. Crystal methods
  8. Agile unified process (AUP)
  9. Lean software development
APPLYING NEW AGILE PRACTICES

Note: The PMI-ACP exam is based on the concepts of Agile and not on a particular Agile methodology. But we should know the purpose of each methodology and the context under which each of the methodologies is being used. For the PMI ACP exam, the most important methodologies to know are Scrum, XP, Kanban, and Lean. There may be only a few questions from the other methodologies. So, we will discuss Scrum, XP, Kanban, and Lean in more detail in this chapter, and some highlights of the other methodologies will be given.

SCRUM

Scrum is the most widely used framework of Agile. The term ‘Scrum’ is associated with the sport, rugby, which means “to restart the game after a short infringement when the players pack closely together head down trying to get possession of the ball”.

Scrum is characterized by short time-boxed iterative cycle, adjustable scope, customer satisfaction through quick turnaround time, responding to change quickly, customer collaboration throughout the project.

Figure 3.1 explains the flow in the Scrum framework. The incremental product development is achieved in small time-boxed iterative cycles called sprint. The duration of sprints are fixed, i.e. sprints are time-boxed. Even if all the features in the sprint backlog are not completed, a sprint is marked as completed if the sprint duration is over. The remaining work (if any) is moved back to the product backlog and re-prioritized to be taken up in the future sprints. Normally the requirements are kept unchanged inside the sprints. So, the main steps of scrum are:

image

Figure 3.1 Scrum project execution

  1. Step 1 : Collect product features (product backlog)
  2. Step 2 : Get the product features (backlog) in order according to priority
  3. Step 3 : Plan the number of releases
  4. Step 4 : Plan the number of sprints in each release
  5. Step 5: Sprint Planning Session - Part 1: Clarify the requirements
  6. Step 6: Sprint Planning Session - Part 2: Estimate individual tasks
  7. Step 7: Create work environment for executing the Sprint
  8. Step 8: Execute Sprint
  9. Step 9: Conduct stand-up meeting to track the Sprint
  10. Step 10: Conduct a Sprint review and Sprint retrospection at the end of Sprint
  11. Step 11: Go to Step 5 if there are more Sprints in the release
  12. Step 12 : Conduct release retrospection at the end of the release Scrum
  13. Step 13 : Go to Step 3 and 4 if there are more releases to execute

Scrum framework has three main concepts: Scrum Roles that define roles and responsibilities of the Scrum team members; Scrum Ceremonies – the meetings and group co-ordinations that help improving the communication; and Scrum Artifacts – the minimum set of artifacts that the scrum team should maintain to properly structure the work.

Scrum Roles are based on an imaginary story of a chicken and a pig who wanted to open a restaurant together. The chicken suggested that they could open a Ham and Eggs restaurant. But then the pig didn’t agree as he mentioned ‘in that case I would be COMMITTED but you would only be INVOLVED’. Only the people who are committed to the project’s delivery are considered as part of the Scrum team. Everyone else who may be involved in the project but is not committed directly are NOT part of the Scrum team. For example, a tester who is involved in testing the product is part of the Scrum team, but a delivery manager who oversees the project and provides help if any resource-related issue arises is not considered as part of the Scrum team. The three main Scrum roles are – the product owner, the Scrum master and the team.

Product owner (PO): This person is the bridge between the end users and the development team. The product owner has the primary responsibility of translating the product vision to user requirements and of ensuring that the project’s objectives are met by the end product. This role is critical to the project’s benefit realization and meeting the final goal largely depends on the product owner’s ability to create, prioritize, and verify the requirements. The product owner

Scrum master: This person is responsible for making sure that the scrum values and principles are followed in the team and more importantly is responsible for helping the team in removing the roadblocks in order to achieve the scrum goals. As the project manager’s role in the traditional sense (that is performing planning, monitoring, and tracking activities) is not present in the Scrum framework, this person works as the bridge between the team and the management. The Scrum master

  • represents management to the project
  • responsible for enacting Scrum values and practices
  • removes or helps in removing impediments
  • ensures that the team is fully functional and productive
  • enables close cooperation across all roles and functions
  • shields the team from external interferences

Often the Scrum master role is played part time by one member of the project team. The most important characteristic of the Scrum master is that he/she should be a good communicator and is trusted by all the members of the team.

Team: This is the group of people who are executing the actual tasks of the project like design, development, testing, etc. Some of the key characteristics of an ideal Scrum team are

  • Typically consists of 8–12 people. As the key Agile feature is a high level of communication among the team members, the team size is restricted to keep the number of communication channels under control.
  • Cross-functional team: programmers, testers, user experience designers, etc. This means that the team has all the skills required for the project available within the team.
  • Members should ideally work full time, perhaps with a few exceptions (e.g. database administrator, network support people).
  • Teams are self-organizing: ideally, no titles, but rarely a possibility.
  • Responsible for the quality
  • Estimates the complexity
  • Committed to developing functionality

Scrum ceremonies are designed based on the principle that all the team members should be aware of who is doing what, know about the challenges in the project, and work together to improve the way the project is run. The important Scrum ceremonies are Sprint planning, Sprint review, Sprint retrospective, and daily Scrum meeting.

Sprint planning: The preparation for a Sprint starts with the Sprint planning meeting. The input to the Sprint planning meeting is the prioritized product backlog, and the output is the Sprint backlog, which has task estimation and assignment for each backlog item that is decided to be taken up in the current Sprint for implementation. The team selects items from the product backlog they can commit to for completing. Once the Sprint backlog is created, the tasks are identified, and each is estimated (1–16 hours) collaboratively by the team. A high-level design may also be considered while discussing the task-level estimates and assignments.

Normally the Sprint planning meetings are broken into two sessions. Refer to Figure 3.3 for the structure of a Sprint planning meeting. During the first session, the product owner explains the scope of the requirements in the product backlog, and the team gets clarification about what is involved in the implementation of each of these requirements. Based on the team’s capacity (called velocity) and the story point estimate of the user stories in the product backlog, the team will create the first cut Sprint backlog that they will aim to implement during the current Sprint. During the second session, the team tries to find out the tasks for implementing each requirement and also estimate those tasks in hours. The tasks should be small enough (1–16 hours) so that those can be correctly estimated and assigned. Then based on the total number of available days in the Sprint and total number of resources, the team finds out if all the user stories planned for the Sprint during the previous session can be accommodated. Also, the team members sign up for the tasks based on the familiarity and interest areas. At the end of the Sprint planning meeting, a well-defined Sprint backlog is created.

Sprint review: This is the most important meeting conducted at the end of the Sprint where the team presents what it accomplished during the Sprint. This typically takes the form of a demo of new features or underlying architecture. The idea is to show the incremental product or design and get feedback from the users for future enhancement. The ‘Done’ness of the user stories are determined during this review meeting. It is important to understand that this review is mainly focused on showing the actual product, and thus the use of too much of slides/presentation is discouraged. A ‘2-hour preparation time rule’ signifies that the team should showcase whatever they have achieved during the Sprint without spending time for preparation. The whole team participates in this review, and it is important that the product owner and the end users take part as well. It is ok to invite the people outside the team as well, but the discussions mainly happen within the core group.

Sprint retrospective: Agile framework has a continuous improvement mechanism built within it. As Scrum is running in short iteration cycles, it is easy to take the opportunity to fine tune the processes followed in the Sprint so that the overall scrum effectiveness increases. Sprint retrospective is the team meeting held at the end of the Sprint to discuss what went well, what did not go well, and what improvements can be brought into the way the team is working. So, the Sprint review is about the product improvement, and Sprint retrospection is about process improvement.

See Chapter ‘Planning, Monitoring, and Adapting’ for details on Sprint retrospective.

Daily scrum meeting/daily stand up: It is very important to make sure that all the team members are aware of the progress each member is making and also they get to know or let others know about any possible roadblock that may hamper the progress of the Sprint. Daily standup call is a short duration time-boxed call involving all team members where the members update each other about the progress, planned activity, and roadblocks. So, the focus of the meeting is to discuss three main points from each – what did you do yesterday? What will you do today? Is anything in your way?

See more details about daily stand up in Chapter ‘Communication’.

Introspective: In Sprint retrospective the main focus is on the immediately completed Sprint. But there is also a need to look at the system level and find out the tools, processes, and rules that are set up for the whole project are providing the intended level of benefit or are still relevant for the project. This is done through introspective meetings. As we can understand, this is not required for every Sprint or release, but can happen at a lesser frequency. Normally introspective meetings are time boxed to 3 hours, and the first 2 hours are spent in discussing the overall process, tools, rules, and analyzing their benefits or suitability. The last 1 hour is used to create the implementation plan for the suggested changes.

Introspection provides the scope for continuous improvement at the system level, while retrospectives and daily standups incorporate continuous improvement at more granular levels subsequently.

Scrum artifacts are the items that help in maintaining the scrum goal and the final output. Mainly four artifacts are maintained in Scrum projects.

Product backlog: A product backlog contains the requirements that are nothing but a list of all desired work on the project. This is ideally expressed such that each item has value to the users or customers of the product. One important aspect of product backlog is that the backlog items are prioritized by the product owner and can be reprioritized at regular intervals.

Sprint backlog: A subset of the product backlog (a group of requirements) that is taken up for implementation within a Sprint is called Sprint backlog. There can be an intermediate backlog prepared between product backlog and Sprint backlog called the release backlog. The relation of these three types of backlogs are depicted in Figure 3.4. Changes to the Sprint backlog are kept to a minimum within a Sprint as too much change in the backlog can hamper the team’s focus on the final outcome of the Sprint.

See Chapter ‘Agile Analysis and Design’ for more details on product backlog and Sprint backlog.

Incremental product: Scrum expects that at the end of each Sprint there will be a potentially shippable product ready with some feature enhancement over the last version. This incremental product is the main output of the Sprint execution. It is important to understand that during an early development cycle there may not be a fully working product, and it may very well be an increment on the product architecture that becomes the outcome of a Sprint. Moreover, potentially shippable does not mean that the product will be released to the end users. That may follow the normal release cycle. It is more of a business validation whether the incremental development done by the project team meets the customer’s stated requirement. Definition of Done (DoD) is the criteria the customer sets for validating the incremental products and are checked during the Sprint review meeting.

Burn-down charts: Agile projects emphasize on making the progress of the project visible to all stakeholders in an easy way. Contrary to the traditional projects that track the work done, Agile projects focus more on work remaining. One of the powerful visual dashboards that are used in Agile projects is called the burn chart. There are different options like burn-up chart, burn-down chart, cumulative burn-down chart, etc. based on the way of representation. Also, based on the span of representation, these charts can be at the Sprint or release level.

See Chapter ‘Planning, Monitoring, and Adapting’ for details on burn charts used for tracking Agile projects.

So, consists of three phases, namely, pregame, development phase and post game. Sprint planning happens in pregame phase. Actual sprint execution happens in the development phase. Integration, retrospection happens in the post game phase.

Few points to remember about Scrum are:

  1. A product backlog is a list of all known requirements
  2. A sprint backlog is a list of all known requirements which the team is going to work in the current sprint
  3. A period of work is called sprint (It is actually the current phase of the project) and it is usually time-boxed
  4. Daily stand-up meetings happen with the Scrum team
  5. A burn-down chart, burn-up chart helps to track progress of the sprint
  6. An incremental product is delivered to the customer at the end of each sprint
  7. A Scrum master is a facilitator and leader and he is responsible for teaching others how to use the Scrum process to deal with every new complexity encountered during a project.
  8. Story point is the metric used for estimation
  9. Concept of velocity is used to measure the productivity of the team

Scrum Challenges

  1. Resistance and unlearning required for team members for working on Scrum, especially resources who are used to waterfall.
  2. Managing expectations from clients—the clients may assume that any requirements change at any time can be easily accommodated in Scrum projects.
  3. Adhering to standards—expectations on detailed documentation.
  4. Code brittleness—In Scrum, the same piece of code is re-factored multiple times after it is deployed to implement future requirements. This continuous refactoring may make the code brittle and thereby impact the code quality.
EXTREME PROGRAMMING (XP)

I recently came across a project where the customer changes the requirements more often than expected (almost every day) and also the domain and technology tool used was a new one for the company. Customer changes the requirement even after the entire coding gets over, but the customer wanted everything quickly. The environments outside the project were in total chaos and there was total uncertainty. I felt this project is a good candidate for extreme project programming.

In the following scenarios XP works best:

  1. Requirements changing almost every day
  2. Total chaos in the project environment
  3. Customer wants everything fast
  4. Handling with new domain/technology
  5. Total uncertainty in everything
  6. Small projects that are more easily managed through informal methods

Extreme Programming is an Agile development methodology that was created by Kent Beck in the 1990s.

Extreme programming methodology is built on four guiding values—communication, simplicity, feedback and courage. XP programming has a key focus on improving the communication—it may be among the developers or between developers and customer. The concept of the onsite customer (discussed later in this chapter) as well as pair programming is the way to improve the communication. XP relies on simple design and coding models. The code will be easily refactorable if it is kept simple. The small iterations in XP ensure the continuous feedback cycles. Thus, the customer gets what he/she wants. It inspires courage among the team members because the customer and the developers are working closely, and any bad news should be shared without fear. XP is designed for small collocated teams and tries to ensure quality and productivity as high as possible.

The following 2 principles form the basis of the XP methodology:

Planning Game: Only the immediate iteration is only planned so that we don’t plan too far, which has too many unknowns. The three steps involved in the planning game are exploration, planning and steering. In the exploration phase, the customer defines the requirement for the system and the developers estimate the effort. Requirements are captured in the form of User Story. Based on this analysis in the planning phase, both these parties negotiate on the finalized features to be implemented within the project scope. In the steering phase, the plan gets updated as more knowledge regarding the development and business are acquired.

image

Figure 3.5 Planning Game

Simple design: The programmers should always ask themselves if there is any simpler way to implement the functionality. The best possible design approach which is the most simple one should be chosen for implementation. This ensures that only the customer-required features are implemented and also it is easy to add incremental functionalities later on this code.

Refactoring: One main pitfall of the quick small releases is that the design and codes created during iteration focus on the immediate requirement and not on the full system. Thus, there is always a possibility of patchy and messy code getting generated after few iterations are completed. Refactoring is a process where the quality of the system is improved by changing the code after few iterations for consistency and maintainability, but making sure that it does not change the behavior or functionality of the system.

Pair programming: A powerful concept used in XP which aims at improving the product quality by introducing an extra pair of eyes while doing the development is called pair programming. Here two developers will work together using one computer to create the design, code and unit testing. The philosophy behind this approach is ‘two heads are better than one’. This ensures that this two developers are continuously reviewing their work jointly and making sure that the best possible solution is created, and the test cases cover all the scenarios of the system.

Continuous integration: XP methodology goes to the extent of integrating the newly developed codes with the existing one even daily. This ensures that there is always a running version of the product and ensures small release cycles.

Collective code ownership: This concept promotes the idea that all developers own all the codes rather than just part of the system. This makes the refactoring easier and builds a sense of responsibility among the team members.

Coding standards: For the small and quick coding cycles, it is necessary that all the developers follow some standards in terms of naming convention, writing style, exception handling, etc. This will make sure less effort is needed during the refactoring as the developers need not try to decipher other programmer’s code and also reduces the need for internal commenting.

Onsite customer: Improved customer collaboration is one of the basic values of XP. The onsite customer presence ensures the continuous collaboration of the team and the customer and the continuous feedback by the customer. This makes sure what is required by the customer is actually getting developed, and there is a minimum waste due to expectation mismatch.

Focus on testing and automation: XP stresses on the test first approach (See next section Test-driven Development). This gives the developers a goal. The focus on unit testing is to ensure the quality of the product. As XP relies on small iterations, investing on the automated testing is essential.

System metaphor: A common set of terminologies used for the system are called the system metaphor. This ensures easy communication among the project team members and with the customer and improves communication.

Sustainable pace (40-Hour work week): Team is the focus of the XP methodology. Thus, it makes sure that team works 8 hours per day for 5 days a week making a 40-hour week. Continuous overtime by the team actually reveals a problem, and it is not a long-term solution.

Small releases: Similar to other Agile methodologies, XP also focuses on small incremental releases to end user for getting frequent feedback and providing early customer ROI. This also enables the team to improve the processes in the project and provides the customer required confidence on the progress of the project.

Though XP is a powerful and popular concept in software development, there are few issues that have been highlighted like less documentation produced during development and the scalability due to its focus on small collocated team.

TEST-DRIVEN DEVELOPMENT (TDD)

TDD is a specific engineering practice from XP, which is a way of writing code and creating the design by making those pass the test scenarios. It actually recommends writing the automated unit test first before writing the code. The test will not compile itself at the first instance, so write the basic minimal code in order to make it compile. Run the test and see it fails because we did not implement the full code. Write the full code and make it pass. Refactor for clarity and repeat. This increases the speed and also improves the quality. ‘3 A’ model (Arrange, Act, Assert) is the principle behind TDD. Following are the steps in TDD model (Refer Figure 3.6):

  1. Write a single test
  2. Compile the test. It will not compile because the code is not written
  3. Implement the just enough code to enable the test to compile
  4. Run the test and see it fail because no content there inside
  5. Implement just enough code to see the test pass
  6. Run the test and see it passes
  7. Refactor the code for clarity
  8. Repeat the process
image

Figure 3.6 TTD

FEATURE-DRIVEN DEVELOPMENT (FDD)

FDD is a very simple methodology and consists of only five processes (Figure 3.7), namely, develop an overall model of the system, build the features list, plan by feature, design by feature and build by feature.

The features to be built are small aspects of client valued functionality that can be expressed in the form of <action> <result> <object>. FDD refers individual code ownership and seeks to avoid refactoring by concentrating on domain knowledge.

FDD also defines the following six roles.

 

  • Project Manager
  • Chief Architect
  • Development Manager
  • Chief Programmers
  • Class Owners (aka Developers)
  • Domain Experts
Kanban Method

Kanban means ‘signboard’. In early 1940s, the concept of Kanban was introduced by Japanese car manufacturers to ensure that the work in progress items (WIP) match with the capacity of the team, which helps in reducing the inventory and flexible planning and increasing productivity and transparency in the whole process. The Kanban framework later becomes a powerful tool in Lean methodology which focuses on Just In Time delivery and limiting the work queue. The main principles of Kanban are as below:

Reduce cycle time: The time gap between when the work on an item starts and when it is delivered to the end users is called the cycle time. This is the key metric followed in the Kanban framework. So, a Kanban team does not work on fixed time-boxed iterations like in Scrum, but they take up one item from the top priority list of the product backlog, develop and deliver it, and then move to the next priority items. The team consciously avoids working on too many items in parallel because shifting focus continuously on multiple items reduces the team’s efficiency. The product backlog can be reprioritized or changed at any time because the team is not working on too many items at a time. This gives tremendous flexibility to the customer compared to other frameworks like Scrum where the requirements are frozen for the duration of the Sprint.

Overlapping skillset: A team with overlapping skill sets helps in reducing the cycle time because if a single person holds a particular skill set, then that person may become the bottleneck in the workflow. By reducing the number of work in progress items, Kanban can make the workflow very transparent to all the stakeholders so that the bottlenecks in the process, either due to person dependency or infrastructure dependency, are surfaced very early.

Visual dashboards: Kanban has a high focus on continuous improvement. For ensuring that the team focuses on improvement, Kanban makes the current performance visible through the use of two key reports – control charts and cumulative flow diagrams. These diagrams are discussed in more detail in later chapters, but the main use of these diagrams in Kanban is to identify the issues early in the lifecycle and limit the work queue for optimizing the cycle time. A Kanban board (Figure 3.8) provides the visual input about how many items are moving within the workflow and which stage those are at.

Continuous development: This principle is one step ahead of the continuous integration principle. The customer does not have to wait for the release cycles to get the new features, but the team is flexible enough to deliver functionalities continuously as it is focusing on a limited number of items at a time and completing those before taking up more items. This gives great flexibility to the customers to remain competitive in the marketplace throughout the development cycle.

So, as discussed, limiting the WIP items is a key focus for Kanban. In Figure 3.8, WIP (2) indicates that maximum 2 items are allowed to be in WIP at any stage indicating work in progress limit. If any step reaches its limit, then the preceding step must halt so that the bottleneck can be cleared first. For example, if the testing team reaches the WIP team, then the development should stop sending the code as there is no point in producing more code as it won’t reach the end customer without testing. This can reveal a potential bottleneck in the team that it needs more experienced testers to improve the cycle time or may be the testing environment is very slow, which becomes visible through this. Kanban focuses on the continuous flow of work rather than wasting time on time-boxed tasks.

Rules for using Kanban effectively are as follows:

  1. Start with a plan. The PFEP (Plan for Every Part) is the cornerstone of the Kanban implementation.
  2. Order only what is needed.
  3. Make only what is ordered.
  4. Kanban is official. No items are made or moved without a Kanban.
  5. Quality is of the top order. Defective parts and incorrect amounts are never sent to the next process.

See more content about the Kanban Board in Chapter 5 of this book.

AGILE UNIFIED PROCESS (AUP)

This is the simpler version of the rational unified process (RUP). It is summarized by Scot Ambler as ‘serial in large, iterative in small, delivering incremental release over time’. Inception, elaboration, construction, transition are the four phases of AUP and is risk-driven which contains various optional artifacts.

DYNAMIC SYSTEMS DEVELOPMENT METHOD (DSDM)

It combines the project management life cycle and product development life cycle. Pre-project, project life cycle and post project are the phases of DSDM. Project life cycle phase is broken into five parts, namely, feasibility, foundation, exploration, engineering and development. Roles of DSDM team are developers, testers, technical coordinators, ambassador users and the visionary. Visionary is the person who actually initiated the project and knows about the whole project.

CRYSTAL METHODS

Colour principle is used to denote the set of standards to employ. Maroon is for heavy projects followed by red, orange and yellow and crystal clear (lightest). The above colour grid is used to define the process to be employed.

LEAN SOFTWARE DEVELOPMENT

Lean 5S Tool for Improvement

5S tool (Figure 3.9) is a foundation tool for continuous improvement in lean. 5S are called housekeeping standards. As per the lean principle 95% of the lead time is non-value adding.

Lean Software Development is adopted from Toyota Production System which combines the principles of lean manufacturing and Lean IT principles. The seven principles that form the Lean system are:

  • Elimination of waste (discussed in Chapter 10)
  • Create knowledge—the learning from each phase of the project should be propagated to the whole team and take necessary action based on the learning. For example, if there is a high number of a defect found after the release, then the learning in the unit testing needs to be more stringent which is a learning that needs to be propagated to the team.
  • Quality is in-built—one of the ways of building the quality is refactoring. The customer must see the quality in the delivered system.
  • Defer commitment—commit only the portion for which you have sufficient visibility. There is no point committing something far off in the future as there may be many changes by the time you reach that point. So, defer your commitment as late as possible. This is the same concept as adaptive planning.
  • Deliver fast—create small release cycles so that the values are delivered faster to the customer.
  • Empower the team—in software development, people are the key. So, take the time to motivate the team and build the team over time.
  • Optimize the whole—see the whole system as an integrated view. There may be different teams working on different parts of the system, but all the team members should have the overview of the whole system and know the purpose of the system. Without this knowledge, the team members can’t produce an effective deliverable.

Agile Hybrid Models

In Agile, incremental codes are developed in iterations that build the whole software in steps. In each iteration, the same code base is touched over and over again. It has been observed for large applications that the lack of good architecture upfront makes the product quality poorer at the end. So, there is a group of large organizations, which believe that moving away completely from the traditional waterfall way of development is not prudent after all. Rather, the new study shows that following a Hybrid approach where the architecture is developed in the waterfall at the beginning and then functionalities are added in iterations yield better architectural stability and end product. Requirements can change throughout the project life cycle in an agile project – but robust architecture platform and framework are important.

The Hybrid approach uses Sprint 0 to build a strong foundation for the project. In Sprint 0, start designing the system architecture and also check the architecture early by creating some features using that architecture. Don’t wait till the architecture is frozen to start the feature development as it may cause large rework on architecture later. Also, finalize the NFR (Non-Functional Requirement) list and address those in the system architecture design and build the re-usable components, which can improve velocity in subsequent sprints. See Figure 3.10 for how Sprint 0 is used before the actual development sprints to create a strong foundation for the project. The duration of Sprint 0 can be larger or smaller than actual sprints based on the project scenario.

image

Figure 3.10 Hybrid Agile Model

Summary

Agile methodology is more people oriented. Agile methodology helps us to increase productivity and reduce risks. This paper discussed popular agile methods that are prevalent in the market such as Extreme Programming (XP), Dynamic System Development Method (DSDM), Scrum, Crystal Methods, Agile Unified Process (AUP), Feature Driven Development (FDD), and Lean software development. From the examination perspective, we need to understand the concepts of these methodologies and the context under which they are applied into a Project.

Chapter 3 Questions and Answers

  • Please set yourself a time clock of 1 hour to take this test
  • Mark your answers using pencil in the answer sheet provided at the end of this question set
  • The correct answers are provided at the end of this question set (after the answer sheet)
  • Give one mark for each correct answer for evaluation purpose
  • There is no negative marking for the wrong answers
  • Practice this test multiple times for better results
  • All the very best!

Question 1. Following are the concepts used in Scrum methodology except:

  • Vision
  • Product backlog
  • Velocity
  • Colour principles

Question 2. Following are the colours used in crystal methodology except:

  • Maroon
  • Black
  • Red
  • Yellow

Question 3. Following are the phases of Scrum methodology

  • Pregame, development phase and post game
  • Pre-project, project life cycle, post project
  • Inceptions, elaboration, construction, transition
  • Initiation, planning, execution

Question 4. Following are the Phases of DSDM methodology

  • Pregame, development phase and post game.
  • Pre-project, project life cycle, post project
  • Inceptions, elaboration, construction, transition
  • Initiation, planning, execution

Question 5. Following are the phases of AUP methodology

  • Pregame, development phase and post game
  • Pre-project, project life cycle, post project
  • Inceptions, elaboration, construction, transition
  • Initiation, planning, execution

Question 6. A list of known requirements in Scrum on which the team is going to work in the current iteration is called

  • Sprint backlog
  • Release backlog
  • Product backlog
  • Functional requirement

Question 7. Sprint planning in Scrum happens in

  • Pregame phase
  • Development phase
  • Post game
  • Inceptions

Question 8. In Scrum methodology, a period of work is called as (choose the one most appropriate)

  • Time-box
  • Sprint
  • Iteration
  • Story point

Question 9. The concept used to increase the team productivity in Scrum methodology is called:

  • Velocity
  • Sprint
  • Iteration
  • Efficiency

Question 10. The concept of high speed, high change, high uncertainties is the characteristics of

  • Scrum
  • Extreme programming
  • Crystal
  • Traditional project management

Question 11. Different types of kanbans are

  • Production kanban, WIP kanban
  • Production kanban, Deposit kanban
  • Production kanban, withdrawal kanban
  • Kanban 1, kanban 2

Question 12. In FDD methodology, the features to be built are small aspects of client valued functionality and that is expressed in the form of

  • <action> <result> <object>
  • <action> <object> <result>
  • <object> <result> <action>
  • <object> <action> <result>

Question 13. In FDD developers are referred as

  • Team
  • Class owners
  • Chief architect
  • Domain experts

Question 14. Choose the LEAN 5S tool in order

  • Sort, shine, straighten, standardize, sustain
  • Sustain, straighten, shine, standardize, sort
  • Sort, straighten, standardize, shine, sustain
  • Sort, straighten, shine, standardize, sustain

Question 15. Project life cycle phase in DSDM is broken into

  • 5 parts
  • 6 parts
  • 3 parts
  • 4 parts

Question 16. Choose the order of projects life cycle parts of DSDM

  • Foundation, feasibility, exploration, engineering and development.
  • Feasibility, foundation, exploration, engineering and development.
  • Feasibility, foundation, engineering, exploration and development.
  • Feasibility, foundation, exploration, development and engineering.

Question 17. Scot Ambler summarized AUP as

  • Serial in large, iterative in small, delivering incremental release over time’.
  • ‘Serial in small, iterative in large, delivering incremental release over time’.
  • ‘Serial in large, iterative in small, delivering documents over time’.
  • ‘Serial in large, iterative in small, delivering product at the end’.

Question 18. PFEP in Kanban stands for

  • Part of essential process
  • Process for essential part
  • Plan for essential part
  • Plan for every part

Question 19. A project started following the Kanban methodology. The time gap between when they start working on an item and when they deliver to the end users is called

  • Cycle time
  • Sprint
  • Time box
  • Release

Question 20. A team member recently moved from a Scrum-based project to a Kanban delivery model. He asked the other team members what is the normal time-boxed duration for each development cycle. What will be the response from the team members?

  • Normally 2-4 weeks
  • In Kanban there is no time-box concept, it is driven by the cycle time
  • Depends on the project manager and team availability
  • Each item is estimated at the beginning and the timeline is fixed before work begins

Question 21. Kanban uses the following system

  • Push system
  • Pull system
  • Interactive system
  • Hub and spoke system

Question 22. The number of process and the number of roles in FDD

  • 5, 6
  • 6, 5
  • 4, 6
  • 4, 5

Question 23. Choose the right order of process in FDD

  • Build the features list, develop an overall model of the system, plan by feature, design by feature, build by feature
  • Develop an overall model of the system, build the features list, plan by feature, design by feature, build by feature
  • Develop an overall model of the system, plan by feature, build the features list, design by feature, build by feature
  • Build the features list, plan by feature, design by feature, build by feature and develop an overall model of the system

Question 24. Which methodology recommends writing the automated unit test first before writing the code?

  • FDD
  • TDD
  • AUP
  • DSDM

Question 25. Following is a type of TDD

  • 3A model
  • 3C model
  • 3B model
  • 6P model

Question 26. 3A model of TDD stands for

  • Act, arrange, assert
  • Arrange, act, assert
  • Assert, act, arrange
  • Assert, arrange, act

Question 27. One of the powerful features of the Kanban methodology is Continuous Development. It can be explained as below

  • Team members are under continuous pressure to reduce the development time
  • Same item is developed simultaneously by multiple team members to check consistency
  • Developers are rotated continuously in multiple teams to improve the learning process
  • Team is focusing on the development of a limited number of items at a time and thus the customer can get delivery of new features continuously

Question 28. Which one of the below is one of the 12 principles of XP?

  • Experienced team
  • Strong project management
  • Simple design
  • Flexible timing

Question 29. In the Hybrid Agile Model, what is the role of Sprint 0?

  • To create robust architecture and reusable components
  • To give time for the development team to get up to speed
  • To do some work of Sprint 1 so that the team can relax during Sprint 1
  • To teach the team how a sprint should happen

Question 30. You are a part of the Scrum team for which the implementation is very complex and has scope for future expansion. The architect cautioned that the product’s architecture should be designed very well so that it can handle future enhancement. What would you suggest before starting the development sprints?

  • Scrum is not recommended for this project and should move to waterfall
  • There should be a Sprint 0 planned in which the product architecture is created and then tested with a few sample features
  • There should be two different tracks - one for architecture and another one for feature development
  • More testing should be done

Question 31. In XP one of the main values is feedback. What type of feedback is encouraged in XP?

  • Customer feedback only as they are the main users of the system
  • System only
  • Both from the system (through testing) and the customer
  • Project manager feedback is most important

Question 32. Which one of the below is not a responsibility of the Scrum master?

  • Represents management to the project
  • Responsible for enacting Scrum values and practices
  • Removes or helps in removing impediments
  • Allocates and tracks the tasks of the project

Question 33. All of the followings are the shared values of extreme programming except:

  • Late failure
  • People first
  • Courage
  • Quality of life

Question 34. Number of shared values defined in extreme programming is:

  • 4
  • 5
  • 12
  • 10

Question 35. Following are the critical success factors defined for extreme project except:

  • Keep it simple
  • Leadership by commitment
  • Real-time communication
  • Agile organization

Question 36. Following are the accelerators defined for extreme programming except:

  • Keep it simple
  • Create ownership for results
  • Make change your friend
  • Flexible project model

Question 37. ‘Create ownership for results’ in extreme programming is an

  • Accelerators
  • shared value
  • Critical success factors
  • Business case

Question 38. ‘Result Orientation’ in extreme programming is an

  • Accelerators
  • shared value
  • Critical success factors
  • Business case

Question 39. Vision, product backlog, sprint backlog are related to

  • RUP
  • Scrum
  • AUP
  • DSDM

Question 40. Scrum master is (Choose the most appropriate answer)

  • Facilitator
  • Mentor
  • Teacher
  • Facilitator and leader

Question 41. A team is following the XP methodology. After working for a few iterations they found that the code has become very patchy and brittle. What step should they take to fix this problem?

  • Refactoring
  • Recoding
  • Reviewing
  • Code rewriting

Question 42. A team is trying to decide which Agile methodology they should be using based on the project parameters. They found that the requirements will be changing very often and the solution is not also known and thus need some R&D during implementation. Which methodology will be best suited for them?

  • Scrum
  • XP
  • Kanban
  • FDD

Question 43. The meaning of Kanban

  • Signs board
  • information board
  • Message board
  • Action board

Question 44. Which agile methodology is being indicated by ‘Customer pulls out what he wants from the supplier. Supplier just supplies what the customer wants’.

  • DSDM
  • AUP
  • Scrum
  • Kanban

Question 45. All of the followings are the characteristics of extreme programming except:

  • Requirements changing almost every day
  • Total chaos in the project environment
  • Customer wants everything fast
  • Total certainty in everything

Question 46. Chickens and Pigs are the characters in

  • DSDM
  • AUP
  • Scrum
  • Kanban

Question 47. Which of the following is not a Scrum cycle activity?

  • Weekly inspection
  • Daily scrum
  • Sprint retrospection
  • Sprint planning

Question 48. Lightest project in crystal is denoted by

  • Maroon
  • Red
  • Orange
  • Crystal clear

Question 49. Which of the following is a role in Scrum?

  • Delivery manager
  • Project manager
  • Scrum master
  • Scrum manager

Question 50. Pair programming is related with

  • DSDM
  • AUP
  • Scrum
  • Extreme programming

Answer Sheet for Chapter 3 Questions

Question Number Answer Question Number Answer
Question 1 Question 26
Question 2 Question 27
Question 3 Question 28
Question 4 Question 29
Question 5 Question 30
Question 6 Question 31
Question 7 Question 32
Question 8 Question 33
Question 9 Question 34
Question 10 Question 35
Question 11 Question 36
Question 12 Question 37
Question 13 Question 38
Question 14 Question 39
Question 15 Question 40
Question 16 Question 41
Question 17 Question 42
Question 18 Question 43
Question 19 Question 44
Question 20 Question 45
Question 21 Question 46
Question 22 Question 47
Question 23 Question 48
Question 24 Question 49
Question 25 Question 50

Answers for Chapter 3 Questions

Question Number Answer Question Number Answer
Question 1 D Question 26 B
Question 2 B Question 27 D
Question 3 A Question 28 C
Question 4 B Question 29 A
Question 5 C Question 30 B
Question 6 A Question 31 C
Question 7 A Question 32 D
Question 8 B Question 33 A
Question 9 A Question 34 D
Question 10 B Question 35 A
Question 11 C Question 36 D
Question 12 A Question 37 A
Question 13 B Question 38 B
Question 14 D Question 39 B
Question 15 A Question 40 D
Question 16 B Question 41 A
Question 17 A Question 42 B
Question 18 D Question 43 A
Question 19 A Question 44 D
Question 20 B Question 45 D
Question 21 B Question 46 C
Question 22 A Question 47 A
Question 23 C Question 48 D
Question 24 B Question 49 D
Question 25 A Question 50 C

Explanations for Chapter 13 Answers

  1. Answer D
  2. Answer B
  3. Answer A
  4. Answer B
  5. Answer C
  6. Answer A
  7. Answer A
  8. Answer B
  9. Answer A
  10. Answer B
  11. Answer C
  12. Answer A
  13. Answer B
  14. Answer D
  15. Answer A
  16. Answer B
  17. Answer A
  18. Answer D
  19. Answer A
  20. Answer B
  21. Answer B
  22. Answer A
  23. Answer C
  24. Answer B
  25. Answer A
  26. Answer B
  27. Answer D
  28. Answer C
  29. Answer A
  30. Answer B
  31. Answer C
  32. Answer D
  33. Answer A
  34. Answer D
  35. Answer A
  36. Answer D
  37. Answer A
  38. Answer B
  39. Answer B
  40. Answer D
  41. Answer A
  42. Answer B
  43. Answer A
  44. Answer D
  45. Answer D
  46. Answer C
  47. Answer A
  48. Answer D
  49. Answer C
  50. Answer D

Key Terms

Scrum Scrum uses standard project management concepts but with different terminology and best Practices. Scrum is the most widely used methodology framework of agile.

Extreme programming Extreme Programming is a method that is based upon agile concepts and the supporting XP principals of rapid development, flexibility, team empowerment and customer based quality management.

Test-driven development (TDD) TDD can be used without Extreme Programming also. It actually recommends writing the automated unit test first before writing the Code. Yes, of course the test will not compile itself at the first instance, so write the basic minimal code in order to make it compile. Run the Test and see it fail because we did not implement the full code. Write the full code and make it pass. Refactor for clarity and repeat. It actually increases the speed and also improves the quality.

Feature-driven development (FDD) FDD is a very simple methodology and consists of only 5 Process (Figure 3.6) namely Develop an Overall model of the System, Build the features list, Plan by feature, design by feature, Build by Feature.

Dynamic systems development method (DSDM) It combines the project management life cycle and Product development life cycle. Pre Project, Project life Cycle, Post Project are the phases of DSDM.

Crystal methods Color principle is used to denote the set of standards to employ. Maroon is for heavy projects followed by Red, Orange, and Yellow and crystal clear (lightest).