Agile Software Development

In 2001, the term Agile as it applies to software development, came from a meeting of representatives from various software development companies who wanted to see an alternative to document driven software processes. What emerged from this meeting was the Agile Software Development Manifesto.

Bob Martin, one of the Agile founders, said at the initial meeting:

Excerpt from the Manifesto website:

The Agile movement is not anti-methodology, in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never maintained and rarely used tomes. We plan but recognize the limits of planning in a turbulent environment. Those who would brand proponents of XP or SCRUM or any of the other Agile Methodologies as "hackers" are ignorant of both the methodologies and the original definition of the term hacker.

It's important to understand that Agile is not a thing: it’s a mindset that drives an approach to developing software in a different way to traditional methods. It doesn’t involve a singular approach but is more a framework in which work is accomplished with clear guidelines and principles. The common practice is to integrate new code changes continuously as the project is still being built. It involves a continual process of verification and validation at every stage. It’s flexible which means changes to the software being developed are made easily and seamlessly integrated.

What is Agile?

Mark Shead gives an interesting explanation of what Agile is and what it is not, according to the Agile Manifesto. Watch to get a good grasp on the principles and values of Agile as it relates to software development.

Rapid Software Development

Rapid development and delivery are often the most important requirement for a new software system. Businesses operate in a fast–changing environment and it is practically impossible to produce a set of stable software requirements do to those fast-changing expectations of the markets they operate in. Software must evolve quickly to reflect changing business needs.

There are two main methods of software development:

1. Plan-driven
2. Agile

Plan-driven development is essential for some types of system but does not meet these business needs. These include software development models such as The Waterfall Method, Boehm’s Spiral Model and The V Model. Agile principles aim at rapid software development.

Remember a software process model is an abstract representation of the software development process and should link all the elements of the cycle together. The goal of a development process model is to provide guidance and help coordinate tasks to achieve a result as effectively as possible.

The Agile software development was specifically designed to meet the rapidly changing environment by embracing the idea of incremental development and developing the actual final product. In Agile development, design and implementation are considered central activities in the development process and iteration occurs across other activities such as requirements gathering and testing. In contrast to with conventional development models where one phase is completed in order to move to the next phase, Agile development has an extra level of flexibility.

Agile Development means:

• Program specification, design and implementation are interleaved
• The system is developed as a series of versions or increments with stakeholders involved in version specification and evaluation
• Frequent delivery of new versions for evaluation
• Extensive tool support (e.g., automated testing tools) used to support development.
• Minimal documentation – focus on working code

The two diagrams show the flow of information difference between traditional plan-driven development and agile development:

Plan-driven development

• A plan-driven approach to software engineering is based around separate development stages with the outputs to be produced at each of these stages planned in advance.
• Not necessarily waterfall model – plan-driven, incremental development is possible
• Iteration occurs within activities.

Agile development

• Specification, design, implementation, and testing are inter-leaved and the outputs from the development process are decided through a process of negotiation during the software development process.

What to consider when choosing between plan-driven vs agile methods:

Choosing plan-driven vs agile development

1. Most projects use elements of both plan-driven and agile processes depending on
   1. a detailed specification and design before moving to implementation
   2. an incremental delivery strategy with rapid feedback realistic
   3. a small-medium size system being developed
      1. Agile is most effective with a small team
2. Does it require a lot of analysis before implementation?
   1. e.g., real-time system with complex timing requirements
3. Most projects use elements of both plan-driven and agile processes depending on
   1. expected time of development and if system maintainers need design docs
   2. team members
      1. Agile said to need higher skill level to support developers making design decisions while coding.

The Agile model was primarily designed to help a project to adapt to change quickly. Its main aim is to facilitate quick project completion and to achieve this aim, ability is required. Activities that are non-essential are removed and anything that is considered a waste of time and effort is avoided.

Agile modelling refers to a group of processes (frameworks) to help achieve its aims:

• Crystal
• Feature-driven development
• Scrum
• Extreme programming (XP)
• Lean development
• Unified process
• Dynamic Software Development Method (DSDM)

Agile modelling is a combination of both iterative and incremental process models. It still requires planning, such as gathering requirements, analyzing the requirements so that tasks can be divided among those with the best skills, design, coding, and unit testing before acceptance testing. All these are done in a timeframe known as a ‘time-box’. The time-box is the maximum amount of time needed to complete and deliver an iteration to the client.

Agile modelling processes are discussed in more detail later in this topic.

What characterizes agile software development?

Iterative software development shortens the software development life cycle considerably by working in small increments. These are generally called sprints.

Sprints are typically 1 – 4 weeks long but have also been known to happen over an online weekend meet where developers are gathering from different locations around the world. Delivering production quality code every sprint requires a team to work at an accelerated pace. Coding, quality verification and validation must be done at each and every sprint, so, if the team is not set up properly the results can fall short of expectations.

Agile Methods

Dissatisfaction with the overheads involved in software design methods of the 1980s and 1990s led to the creation of agile methods. These methods:

• Focus on the code rather than the design
• Are based on an iterative approach to software development
• Are intended to deliver working software quickly and evolve this quickly to meet changing requirements.

The aim of agile methods is to reduce overheads in the software process (e.g., by limiting documentation) and to be able to respond quickly to changing requirements without excessive rework.

Agile manifesto: “We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:”

Individuals and interactions	Over processes and tools
Working software	Over comprehensive documentation
Customer collaboration	Over bounded contract negotiation
Responding to change	Over following a set plan

"That is, while there is value in the items on the right, we value the items on the left more.”

The principles of agile methods are explained in the table:

Principle	Description
Involving the customer	Customers should be closely involved through the development process. They provide system requirements and are able to test and evaluate iterations of the new system in real time situations.
Incremental delivery	The software is developed in increments with the customer having supplied the requirements for each increment.
People, not processes	The skills of the development team are recognised and exploited to get the best possible outcome for the customer. Team members should be left to develop their own ways of working without prescriptive processes to slow them down or inhibit their creativity.
Embrace change	Expect the system requirements to change, so design the system to accommodate changes with ease.
Maintain simplicity	The software being developed, and the development process should focus on simplicity and wherever possible work actively to eliminate complexity from the system.

The application of the Agile method is primarily focused on product development where a software company is developing a small or medium-sized product for sale. Virtually all software products and apps are now developed using an agile approach

Organisations have custom systems development needs, want developers that are comfortable with having clear commitment from the customer to become involved in the development process and where there are few external rules and regulations that affect the software are also popular Agile participants.

You can read the 12 principles behind the Agile Manifesto. You can also download a PDF copy.

Problems that may arise with Agile methods

Most organizations spend more on maintaining existing software than they do on new software development. So, if agile methods are to be successful, they must support maintenance as well as original development.

Key problems are:

• The informality of Agile development is incompatible with the legal approach to contract definition that is commonly used in large companies.
• Agile methods are most appropriate for new software development rather than software maintenance. Yet the majority of software costs in large companies come from maintaining their existing software systems.
• Agile methods are designed for small co-located teams, yet much software development now involves worldwide distributed teams.
• In some cases, due to lack of formal documents, it creates confusion and important decisions taken during different phases can be misinterpreted at any time by different team members.
• Maintenance of the developed project can be compromised due to the absence of proper documentation.

Agile development relies on the development team knowing and understanding what has to be done. For long-lifetime systems, this is a real problem as the original developers will not always work on the system.

Adaptive, iterative projects are more complex to control and plan than more traditional linear methods.

John Hunt in Agile Software Construction suggests that in linear models, the developer’s life is simpler. No design begins until the proper analysis is completed therefore no implementation starts until all the design in finished. This means everyone in the development should know exactly what needs to be done and what their role in the development required of them. This makes the role of the developer much easier.

There are aspects that can be put up against this stance, for example errors in design, important aspects of planning being missed or the length of time it takes to develop the system fully means it’s no longer fit for purpose and already needs updating. But from a management perspective the traditional approach may be clearer and easier to follow.

Source Seek have a detail explanation of Agile development and is a great way to begin this module learning. If you wait after the first video has finished, you can look forward to watching Part 2 to complete the explanation using a real-world example.

Explain briefly how the principles underlying agile methods lead to an accelerated development and delivery of software.

An agile team works off a backlog of requirements that are often referred to as user stories. (We will cover user stories in more details further along in this topic.) The backlog is prioritized so the most important user stories (or client needs) are at the top of the list. The product owner owns the backlog and adds changes and reprioritizes use stories based on the customer’s needs. When this is not clearly defined it slows the quality and consistency of each sprint down.

When refining the backlog, there are key considerations:

1. Refining user stories is often a long-lead activity. User interfaces, screen designs and customer solutions all take time and energy to create. Products owners may refine user stories 2 -3 sprints in advance. They account for design iterations as well as customer reviews.
2. A user story is not refined unless the teams say it is. The team needs to review the user story and agree it’s ready to be worked on. If a team has not seen the user story until a day prior to a sprint, it is not good practice.
3. User stories further down the backlog can remain ambiguous. It can be a waste of time refining lower-level priority items. Stay focused on the most important and urgent.

One of the first steps a team sets up when starting a new project is set up the build, test and deployment pipeline. Use automated processes to avoid slow time intensive manual deployment.

Note: Clients needs is referred to as user stories in some software definitions.

Key continuous integration and delivery activities are:

• Unit testing
• Build automation
• Branch and build policies
• Deploy to an environment.

Technical Debt

Just like personal finances it’s easier to stay out of debt than dig yourself out of it. Technical debt includes anything the team includes anything the team must do to deliver quality code and keep it running in production e.g., bugs, errors, performance issues, accessibility etc.

Staying agile is about learning from experiences and learning from them, whether it is due to failures and errors or in response to success. Agile development process provides more learning opportunities than conventional development cycles. Each sprint, there is more to learn and challenge yourself with and leads to huge growth and development

Before continuing, take some time to watch this video which explains the differences between a linear approach to software development versus the agile approach to development.

Let’s look at the Agile Development techniques a bit closer.

Crystal

This methodology is one of the lightweight and flexible approaches to software development. It is made up of several agile processes and is known as a family of methods. They focus mainly on people and their interaction.

Alistair Cockburn when developing the family, observed that small teams of software developers could build and deliver projects without much paperwork or reporting, whereas the larger teams need lots of paperwork, lots of updates and continual communication processes. The size of the project determined the complexity of the project. He found that the suitability of the Crystal method depends on three dimensions:

1. Team size
2. Criticality
3. Priority of the project

There are different factors to take into consideration before using this method. Watch the video to help you understand how the Crystal process fits into the Agile practice, and in which circumstances it is best applied. Watch this video to find out more.

Feature-driven development (FDD)

One solution used to control the complexity that is inherent in agile incremental projects is to use and apply a feature-centric process to the development. This aims to provide a way for key questions to be asked.

• What must we do next to add value for the client?
• How are we progressing against time and budgets?
• What issues and risks does the project face?
• How can these issues be address or mitigated?
• What should we do next?

The feature-driven process does this while still retaining the principles behind the agile movement. This feature-centric approach refers to development processes that want to focus on merging the requirements with the planning and work. By doing this what the user wants can be planned for, used as the basis of the work allocation and have it monitored.

Stages of feature-driven development that shape the model:

• Gather Data
• Develop overall model
• Build a features list

Then…

1. Plan by feature
2. Design by feature
3. Build by feature

It is anticipated that a feature should be delivered every 2-10 days.

Kanban

Kanban is a Japanese term that means signboard or billboard. Taiichi Ohno is credited with the development of Kanban at Toyota Motor Group to improve manufacturing efficiency. Kanban shares many of the same goals as software development such as wanting to increase workflow throughout a project. Using the Kanban principles can help improve efficiency and deliver value on to clients faster.

Kanban principles:

1. Pull Model
   • Helps teams focus on an agreed-upon level of quality. Does not push more work onto teams that are already working at capacity.
2. Visualise work
   • It is easier to understand the current status of a task when progress is presented visually.
3. Limit work in progress
   • Limiting the number of backlog items a team is working on at any one time actually helps increase focus.
4. Continuous improvement
   • Using the Kanban board provides a dynamic view of the state of a project. The team can experiment with different processes and evaluate the impact on the flow of work more easily.

Kanban boards may be a software application or a physical board with cards to move around. Typical column titles are to do, doing and done.

Lean development

Originally developed by Mary and Tom Poppendieck, this is an iterative software development method that owes a lot of its practices to the lean enterprise development and lean production in organisations such as Toyota. Toyota was declared the most valuable automotive company in 2017 according to Forbes. They learned directly from the Ford production line in Detroit but originated their own production system based on continuous improvement processes. It one of the most agile methodologies.

Lean development works on the following principles:

Eliminating waste, intensifying learning, choosing as late as permissible, delivering as fast a possible, strengthening the team, building integrity, and seeing the whole. It focuses on effectiveness of the group skills and their speed and productivity.

Unified Process Model (UPM)

Note: UPM is a meta-model. It defines processes and their components. A tool based on UPM would be a tool for process authoring and customizing. The actual enactment of processes, the planning and executing within a project even if it uses a process described with UPM is not in the scope of this model.

Here we discuss the Unified Process.

A software development system can be described as a series of cycles. When a cycle ends a new release (version) of the system is made available to customers. The Unified process using the same principle. A phase is simply the span of time between two milestones. Milestones are points at which managers make important decisions about a project., such as what else is required, what’s working and what’s not, budget and schedule.

This process consists of 4 phases:

• Inception: Establish the case for the viability of the proposed system
• Elaboration: Establish the ability to build the new system given all the constraints.
• Construction: Build system capable of operating successfully in beta customer environments
• Transition: Roll out the fully functional system to customers.

Dynamic Software Development Method (DSDM)

Originating from the UK, Dynamic Systems Development Method (DSDM) is a way of developing application systems that serve the needs of the business. DSDM is a method with a process kept at a high level so it may be tailored for any technical or business environment. It has no prescribed techniques but suggests pathways for implementation of both structured and object-oriented approaches. It is based on nine principles.

1. Active user involvement is imperative.
2. DSDM teams must be empowered to make decisions.
3. The focus is on frequent delivery of products.
4. Fitness for business purpose is the essential criterion for acceptance of deliverables.
5. Iterative and incremental development is necessary to converge on an accurate business solution.
6. All changes during development are reversible.
7. Requirements are baselined at a high level.
8. Testing is integrated throughout the lifecycle.
9. A collaborative and cooperative approach between all stakeholders is essential.

It is anticipated that the users will be more likely to take ownership of the system, and the risk of building the wrong system is reduced and more likely to meet the users’ real business requirements. The users of the system will be better trained, and the implementation is likely to go smoothly.

Extreme Programming (XP)

Extreme programming is one of the most important software development frameworks of the agile models. It is used to be more responsive to customer requirements and improve software quality. It relies on taking the best practices in design development projects and pushing them to extreme levels.

Extreme Programming (XP) takes an ‘extreme’ approach to iterative development.

• New versions may be built several times per day.
• Increments are delivered to customers every 2 weeks.
• All tests must be run for every build and the build is only accepted if tests run successfully.

XP and Agile Principles:

• Incremental development is supported through small, frequent system releases.
• Customer involvement means full-time customer engagement with the team.
• People, not processes through pair programming, collective ownership and a process that avoids long working hours.
• Change supported through regular system releases.
• Maintaining simplicity through constant refactoring of code.

The diagram shows the XP development release cycle. Notice it’s a fully circular process that remains active until the development is implemented and complete, then continues into maintenance and updates as changes are required.

XP is set up for smaller groups of programmers, normally between 2 – 12 people. Larger projects of up to 30 have also been known to be successful. Inexperienced programmers can be part of a team, but it should be noted that on projects of high risk, programmers experienced in the XP processes should make up the majority of a team. The XP programmers’ team is also made up of managers and clients all working together closely. Keeping a conversation current, negotiating scope and schedules, and testing is imperative.

Good practice

Practice	Description
Code review	Detects and corrects errors efficiently. Suggests pair programming with coding and reviewing of code by switching works between them every hour.
Testing	Helps remove errors and improves reliability. Uses test driven development (TDD) to continually write and execute test cases. Test cases are written before any code is written.
Incremental development	Incremental development so customer feedback is gained and based on each increment. Development team delivers increments every few days after each iteration.
Simplicity	Keeping it simple makes it easier to develop good quality software as well as test and debug it.
Design	Quality design is imperative to develop good quality software. Designing should be done daily.
Integration testing	Helps identify bugs at the interfaces of different functionalities. Extreme programming suggests developers achieve continuous integration by building and performing integration testing several times a day.

The core of XP is a set of interconnected practices and principles. Where these have traditionally been done in isolation of each other, in XP these are interconnected and done in conjunction to help eliminate risks in the project.

XP principles

Principles	Description
Coding	Coding in the XP model is slightly different in that it includes drawing diagrams (modelling) that will be transformed into coding, scripting web-based systems and choosing among several alternative solutions.
Testing	Gives high important to testing and considers it the primary factor to develop fault-free software.
Listening	Carefully listen to customers. They need to understand the functionality of the system the customer requires in order to produce a working product.
Designing	Suitable design is important to eliminate complex dependencies within a system.
Feedback	Feedback from customers is integral to this model. Frequent contact makes the development effective.
Simplicity	XP Model is to develop a simple system that works efficiently in the present time rather than build something that takes a lot longer to develop and may never be used. Focus is on specific features and immediate needs.

Some key practices of XP

Sitting together:

• Communication is one of the 5-values of XP.
• Face to face conversations without communication barriers.
• Whole team works together.
• Cross functional groups of developers work towards the same outcomes.

Pair Programming:

Developers work in pairs:

• Pairs change so everyone works together.
• Fosters of code and spreads knowledge across the team.
  • Reduce problem when key developers leave.
  • No one person blamed for bugs.
• Informal review process
• Encourages refactoring:
  • Whole team gets benefit of clean code.

Stories:

• User stories describe what the product should do in terms of users and clients.
• Short descriptors of what users want to be able to do.
• Used for planning and reminders of the project requirements.

Continuous Integration:

• Code changes are immediately tested when added to larger code base.
• Catch and fix integration issues sooner.

Testing:

XP testing features:

• Test-first development.
• Incremental test development from scenarios.
• User involvement in test development and validation.
• Automated test harnesses are used to run all component tests each time that a new release is built.

Test first development:

• Writing tests before code clarifies the requirements to be implemented.
• Tests are written as programs rather than data so that they can be executed automatically. The test includes a check that it has executed correctly.
• All previous and new tests are run automatically when new functionality is added, thus checking that the new functionality has not introduced errors.

The Agile Alliance gives this explanation of the test-first programming practice:

Instead of following the normal path of:
develop code -> write tests -> run tests

The practice of Test-First Programming follows the path of:
Write failing automated test -> Run failing test -> develop code to make test pass -> run test -> repeat

As with Continuous Integration, Test-First Programming reduces the feedback cycle for developers to identify and resolve issues, thereby decreasing the number of bugs that get introduced into production.

Note: There are videos and podcasts that cover project experiences and, industry panels and initiatives on the agile alliance website that you may want to view to expand your understanding of Extreme Programming.

XP and change

Moving to an agile development style as an organisation brings change and can impact on a traditional organisations culture. There is a clear difference between agile methods and tools and the philosophies that enable effective delivery of change ‘with agility.’ The agile philosophy doesn’t rely on agile tools, but agile tools are not effective unless accompanied by an agile philosophy and a supportive organisational culture.

• Conventional/traditional view says it’s worth spending time and effort anticipating changes as this reduces costs later in life cycle.
• XP’s view is that XP uses refactoring to constantly improve code. This makes changes easier when thy have to be implemented.

While agile projects can exist within a framework of reviews, approval processes are frequently as odds with the agile philosophy. Decisions can move more slowly than the agile delivery teams want to work with, and this can crate downtime and frustration. Heavily controlled projects stifle the agile processes. Agile in an ever-evolving process what requires a broad acceptance of ambiguity and the unknown.

There is also a breaking down of power and responsibility as the project breaks down into tasks as actions that are undertaken in as little as 10 minutes them put forward for testing, verification, and validation. Agile approach favours innovation that is realised through people (the team) collaboration.

Traditionally software development was completed before any testing was done. This often meant programs did not work, had bugs and gremlins that needed to be fixed which added more time to the end of a project. Some of those bugs, errors and gremlins are still present in software that we use today. Test-driven development helps eliminate these out-of-date processes and results.

Watch the video from Select Business solutions to learn more.

User Stories

In XP, a customer or user is part of the XP team and is responsible for making decisions on requirements. These user requirements are expressed as user stories or scenarios. They are written on cards and the development team break them down into implementation tasks. These tasks are the basis of schedule and cost estimates. The customer chooses the stories for inclusion in the next release based on their priorities and the schedule estimates.

An effective way to experience a user story is to write it down and factor in all the different aspects of the user experience and needs. What does the user need for a program to be successful?

The following example gives a practitioner prescribing medicine as an example of a user story that needs a program developed. Prescribing medicine story

The next step is to break down the process into task card examples for prescribing medicine.

User stories are broken down into tasks.

Watch the video which gives more insight into user stories in the XP process.

Practical Task

Now see if you can complete the process from the beginning to end. Read the scenario then follow the instructions below to create a user story, tasks, and actions for the EatFit company.

Scenario

Our customer is a company named EatFit. The company is trying to develop a nutrition tracking app, which clients can use to track their daily nutrition in terms of calories, protein, fat and carbobydrates. This app caters for two kinds of users, EatFit customers and EatFit professionals.

The Requirements list is:

1. Track nutrition by meal.
2. Take nutrition data for all food products based on users gender, age, height, and weight.
3. Post a disclaimer on all suggestion outputs that is based on New Zealand health recommendations.
4. Achieve minimum of 80% adoption among EatFit customers within one year of product launch.
5. Collect data to track frequency and patterns of usage of all features.
6. First release of the app targeted for two months from the start of the project.
7. User must log in to access to personal data.

Instructions

• Write user story for the above scenario, with its conditions of satisfaction (from user perspective. User story needs to be developed for both customers.
• First thing you can do is to separate out functional requirements from list and then create user stories for any 2 requirements.
• Suggest four reasons why the productivity rate of programmers working as a pair might be more than half that of two programmers working individually

How did you get on?

• If you were a developer, would you understand the requirements and actions that need to be taken?
• Does the breakdown that you did, have enough succinct information/breakdown for a programmer to complete the tasks with ease?

Agile management is that application of the principles of Agile software development and lean management to various management processes, but particularly software product development and project management. APM is an iterative approach to delivering a project throughout its lifecycle.

• The principal responsibility of software project managers is to manage the project so that the software is delivered on time and within the planned budget for the project.
• The standard approach to project management is plan driven. Managers draw up a plan for the project showing what should be delivered, when it should be delivered and who will work on the development of the project deliverables.
• Agile project management requires a different approach, which is adapted to incremental development and the practices used in agile methods.

It is just as likely to find a Scrum master or product owner as the lead manager for an agile project team. It may also be a shared role with responsibilities divided up between the most experienced team members. Due to the Agile flexibility, there is no right way or wrong way to do this, as every project is different, but it is the Project Managers responsibility to bring the project to a successful conclusion.

Agile Project Managers Role

The APM role can be broken into three categories.

• Team-level roles
  • Act as consultant, allocate personnel, processes and resources
  • Role of coach, advising team how to optimize efficiency
• Enterprise-level roles
  • Act as director/manager of multiple teams and integrating their work with activities outside the scope
  • Role of leader and manager in charge of enterprise level complex projects.
• Hybrid Agile roles
  • Combines agile methods with non-agile techniques (such as waterfall method)
  • Management approach fits best in planning and managing the work with experience in both traditional and agile processes.
  • Meet projects goals within designated timeframes

Difference in SDLC Project management approaches.

Traditional Project Managers	Agile Project Managers
Define the target/objective	Create the project vision
Aim resources at the project	Initiate the project in a broad direction
Launch the project	Adjust and adapt work to accommodate change
Hope target doesn’t move (change)	Reach the target incrementally

Scrum

Scrum is an agile framework that can be adapted to fit your own needs. It focuses on teams delivering customer value early and often in increments. Delivery of increments could be a result of sprints 3 days long or up to one month in length.

The framework is based on the Rugby game where a scrum is a set piece where the two teams are put together to work the ball forward to gain ground in the game. The team works together in one concentrated push to achieve this.

There is a bit of terminology to familiarize yourself with that are related specifically to this framework:

Scrum Team	Definition
Development Team	A self-organising group of software developers which should be no more than 7 people. Responsible for developing the software and other essential project document.
Potentially shippable product increment	The software increment which is the result of a sprint. The idea is that this should be potentially shippable which means its in its finished state and no further work, including testing, is needed to be done to the final product. In practice this is not always achievable, and the software may need to be changed.
Product backlog	This is the to-do list of items that the SCRUM team must tackle. These could be software requirements, architecture, user documentation, user stories or feature definitions.
Product owner	Individual whose job it is to prioritise product features, requirements and continuously review the product backlog to ensure the project meets business and timeline needs.
Scrum	A daily meeting up of the SCRUM team to review progress and prioritise tasks for that day. Usually face to face meeting with the entire team.
SCRUM Master	Person responsible for ensuring processes are followed and will guide the team in the most effective use of the scrum. Also responsible for communicating with the rest of the organisation and ensure the scrum team is not diverted off their tasks.
Sprint	A development iteration – sprints are usually anything from 3 days to 4 weeks long.
Velocity	An estimate of how much product backlog a team can cover in a single sprint. Understanding the team’s velocity helps them estimate what can ideally be covered in a sprint and provides a basis for measuring and improving future performance.

The Scrum sprint cycle

• Assessing the starting point for planning creates the product backlog, which is the list of work to be done on the project.
• The selection phase involves all of the project team who work with the customer to select the features and functionality from the product backlog to be developed during the sprint.
• Once these are agreed, the team organize themselves to develop the software.
• During this stage the team is isolated from the customer and the organization, with all communications channeled through the so-called ‘Scrum master’.
• At the end of the sprint, the work done is reviewed and presented to stakeholders. The next sprint cycle then begins.

Teamwork in Scrum

• The ‘Scrum master’ is a facilitator who arranges daily meetings, tracks the backlog of work to be done, records decisions, measures progress against the backlog and communicates with customers and management outside of the team.
• The whole team attends short daily meetings (Scrums) where all team members share information, describe their progress since the last meeting, problems that have arisen and what is planned for the following day.
  • This means that everyone on the team knows what is going on and, if problems arise, can re-plan short-term work to cope with them.

Benefits

• The product is broken down into a set of manageable and understandable chunks.
• Unstable requirements do not hold up progress.
• The whole team have visibility of everything and consequently team communication is improved.
• Customers see on-time delivery of increments and gain feedback on how the product works.
• Trust between customers and developers is established and a positive culture is created in which everyone expects the project to succeed.

The two videos offered next are an opportunity to learn more about Scrum basics and processes from people who have experience in using the framework.

Reflection

Compare and contrast the scrum approach to project management with conventional plan-based approaches. Which would you prefer to work with and why?