NCFE Level 2

Certificate in Understanding Coding

CODING LANGUAGE

DRY AND WET CODE

SOFTWARE DEVELOPMENT LIFECYCLE

COMPILED CODE

INTERPRETED CODE

DEBUGGING

Workbook 2
 How to use your learning materials
This course is delivered on a flexible learning basis. This means that most of your study
will take place away from your Assessor/Tutor. It helps to carefully plan your studying
so that you get the most out of your course. We have put together some handy tips for
you below.

Study Guidance

• Try to plan an outline timetable of when and where you will study.
• Try
 to complete your work in a quiet environment where you are unlikely to
be distracted.
• Set realistic goals and deadlines for the various elements of your course.
• Plan
 what you are going to study during each session, and try and achieve
this each time.
• After
 each session, reflect on what you have achieved and plan what you hope to
complete next time.
• Remember
 that not only do you have the support of your Assessor/Tutor, but it is
likely that your family, friends and work colleagues will also be willing to help.

Assessor/Tutor Support

• Your Assessor/Tutor will be available to support and guide you through the
programme. They are experts in your area of study and are experienced in helping
many different types of learners.
• They can help you to improve the standard of work you submit and will give
you useful feedback on areas in which you have excelled, as well as where
you can improve.
• Remember to listen to, or read, their feedback carefully. Ask if you are unsure about
any of the feedback you receive, as your Assessor/Tutor is there to help.
• Make note of any tips they give. Refer to the learning materials, as they contain the
information you need to complete the end-of-unit assessments.
• Look out for areas in which you can improve, and set yourself an action plan to make
sure you complete the required work.
• Take positive feedback on board; this demonstrates you are doing things right and
have a good understanding of the subject area.
• Use the feedback to avoid repeating any mistakes you may have made.

Enjoy your studies

2 © LCG 2021
 NCFE Level 2 Certificate in Understanding
Coding
Workbook 2
Workbook contents

In this workbook, we will start by learning about the process and principles of best practice
in coding, before exploring different methods of testing code and learning the reasons why
testing is important. We will explore the steps of the DevOps process, from integration to
delivery and deployment, and the basic principles of robust coding. We will also examine
the use of communication and project management in coding, including an exploration
of different methods of communication and how to give and receive effective feedback.
Finally, we will look at the main principles of project management and the different
project management techniques used in coding, including Lean and Waterfall project
management, and Agile development.

Contents
This workbook contains three sections: Page
Section 1: Understand the processes and practice of coding 5
Section 2: Understand the importance of communication and project
management in coding 37
Section 3: Extension activities 81

Each section has a corresponding assessment that must be

completed in order to achieve this part of the programme. NCFE Level 2 Certificate in Understanding
Coding

Assessment 2
The assessments for this workbook can be found in: Learner contact details

Name:

Assessment 2 Contact address:

Postcode: Contact number:

Email:

When you have completed this workbook, you should Learner declaration
I confirm that the answers in Assessment 2 were completed by me, represent my own

attempt the assessment. Your Assessor/Tutor will then give

ideas and are my own work.
Learner signature: Assessment date:

you detailed written feedback on your progress. If you need any help in completing these assessments, refer to the
relevant section within Workbook 2, or contact your Assessor/Tutor.

Please tick one of the boxes below to show what your status will be when you complete
this course.

Remember that your assessment answers should be EMP 1 In paid employment for 16 hours or more
per week
EMP 2 In paid employment for less than 16 hours
per week
EMP 4 Self-employed for 16 hours or more per week
GAP 1 Gap year before
starting HE
EDU 1 Traineeship
EDU 2 Apprenticeship

written in your own words. You should not copy answers

EDU 3 Supported Internship
EMP 5 Self-employed for less than 16 hours per week EDU 4 Other FE* (Full-time)
NPE 1 Not in paid employment, looking for work and
EDU 5 Other FE* (Part-time)
available to start work
NPE 2 Not in paid employment, not looking for work EDU 6 HE
and/or not available to start work (including retired) OTH # (please state)

directly from the workbook.

VOL 1 Voluntary work ………………………………

Upon successful completion of this qualification, learners will be awarded the

NCFE Level 2 Certificate in Understanding Coding (QRN: 603/5854/3). This CACHE
branded qualification is certificated by the Awarding Organisation NCFE.

Workbook 2 3
 PLEASE READ!

Every effort has been made to ensure the content of this workbook is accurate at
the time of print/production. As some information can change, we recommend
that you check the latest guidance and advice to ensure your answers are
accurate and current.

4 © LCG 2021
 Section 1: Understand the processes and practice of coding

In this section, we will be learning more about best practices in coding. After
starting with the KISS principle, we will explore some of the disadvantages of writing
complicated code. We will then look at the definitions of the single responsibility
principle, separation of concerns and abstractions before finishing the section with a
description of SOLID principles.

What is meant by the KISS principle

Please read the following as it will help you to answer question 1.

The acronym ‘KISS’ was a design principle that reportedly came into use amongst
design engineers of jet aircraft in the 1960’s and is associated with the U.S. military.
It originally stood for ‘Keep it Simple, Stupid’ but is now usually put a bit more nicely,
‘Keep it Short and Sweet’. It is the principle that simplicity should be a key goal in
program design, and unnecessary complexity should be avoided where possible.

In coding, there are a large number of ways you can decrease complexity, depending
on the language and type of program you are using. These include:
• Keep the scope of variables as small as possible.
• Don’t re-use variables (unless in a loop). Declare the variables you are using, name
them properly, and use them only for what they represent.
• Keep functions as small as possible and make sure they do just one thing.
• Use proper naming for your variables.
• Write DRY (‘Don’t Repeat Yourself’) code.
• Use the principle of YAGNI (‘You Aren’t Gonna Need It’). This means that you should
not code more than you need; write the least amount of code that will make your use
case work.
• Use the SOLID principle (this will be discussed in detail later).

Keeping things simple is actually not always that simple. It requires abstract thinking
and a sound knowledge of the language you’re working with, along with experience. It
may also require you to write out each section of code several times, examining it each
time for ways to make it simpler.

Workbook 2 5
 Section 1: Understand the processes and practice of coding

Knowledge Activity: Here are two different code snippets (sections of code).
Both accomplish the same thing. Which do you think is written to KISS
principles? Why?

public String weekday1(int day) { public String weekday2(int day) {

switch (day) {
if ((day < 1) || (day > 7)) throw new
case 1: InvalidOperationException(“day must
return “Monday”; be in range 1 to 7”);
case 2:
return “Tuesday”; string[] days = {
case 3: “Monday”,
return “Wednesday”; “Tuesday”,
case 4: “Wednesday”,
return “Thursday”; “Thursday”,
case 5: “Friday”,
return “Friday”; “Saturday”,
case 6: “Sunday”
return “Saturday”; };
case 7:
return “Sunday”; return days[day - 1];
default: }

throw new
InvalidOperationException(“day must
be in range 1 to 7”);
}
}

6 © LCG 2021
 Section 1: Understand the processes and practice of coding

The disadvantages of writing complicated code

Please read the following as it will help you to answer question 2.

Most systems work best if they are kept simple. For this reason, there are a number of
disadvantages to writing complicated code. Some of them include:
• Complicated code is longer and takes more time to write. This, in turn, can increase
the costs of a project or cause it to run over budget or over time.
• Complicated code is more prone to bugs, and it takes more time to find the bugs.
• If you have a piece of code that was written in a complicated way, then it is more
difficult for anyone else to correct or modify that code. This is because they will first
need to take the time to understand the code. Code that is easy to understand is
much easier to modify by others.
• Code that is more complex and sophisticated than it needs to be can be thought of
as ‘over-engineered’. While this may not seem like a bad thing, the reality is that this
also makes the code less flexible, so that it cannot easily accommodate any future
changes. This can lead to high costs to make relatively minor changes in the future.
Many developers consider simplicity to be the ultimate sophistication.

What is meant by the single responsibility principle

Please read the following as it will help you to answer question 3.

This principle states that each module, class or function in a computer program should
have responsibility over only a single part of that program’s functionality. Another way
to put this is that each class should only have one reason to change.
The Single Responsibility Principle (SRP) is one of five design principles in the SOLID
design framework, which is used for object-oriented software design.
SRP makes software easier to implement and also prevents unexpected side effects
from future changes. This is because, if you have a class that does several things
(has several responsibilities), then, whenever the code needs to be changed or
updated, these responsibilities will also need to be adjusted, making the code more
complicated.

Workbook 2 7
 Section 1: Understand the processes and practice of coding

Example: SRP
Suppose you have a stock trading application with a Transaction class. This class is
responsible for two actions: buying and selling of stocks.

// Class to handle both Buy and Sell actions

class Transaction {
// Method to Buy, implemented in Transaction class
private void Buy(String stock, int quantity, float price){
}
// Method to Sell, implemented in Transaction class
private void Sell(String stock, int quantity, float price){
}

This may seem simple, but if a change needs to be made in either buying or selling,
then the entire class would need to be changed. In other words, the Transaction class
has multiple responsibilities.

To simplify this, the buying and selling actions can be separated into two separate
classes:

class Transaction{
// Method to Buy, implemented in Buy class
private void Buy(String stock, int quantity, float price){
Buy.execute(stock, quantity, price);
}
// Method to Sell, implemented in Sell class
private void Sell(String stock, int quantity, float price){
Sell.execute(stock, quantity, price);
}
}

8 © LCG 2021
 Section 1: Understand the processes and practice of coding

class Buy{
// Static method, accessible to other classes, to execute Buy action
static void execute(String ticker, int quantity, float price){
// Execute buy action
}
}
class Sell{
// Static method, accessible to other classes, to execute Sell action
static void execute(String ticker, int quantity, float price){
// Execute sell action
}
}

The Transaction class can still perform two separate tasks but is no longer responsible
for their implementation.

What is meant by separation of concerns

Please read the following as it will help you to answer question 4.

In coding, a ‘concern’ is information that affects the code of the program.

Separation of concerns (SoC) is a design principle where the computer program is
separated into distinct sections, with each section addressing a separate concern.
One way to think of this is with a real-world analogy. Think about all of the different
roles, or concerns, there are in a hospital: A&E nurses, clinical nurses, doctors, heart
surgeons, medical assistants, techs, clerical staff, cafeteria workers, cleaners, etc. In
order to run properly, the hospital needs all of these people, and each person does just
their own, very specific job – their concerns are separated. Now, for example, if the
hospital decided to change the way that the A&E nurses worked, that would only affect
the A&E nurses. However, if A&E nurses were also responsible for running the cafeteria
and doing surgery (if the concerns were not separated), then a change to the A&E
nurses would also require a change in the other jobs as well.

Workbook 2 9
 Section 1: Understand the processes and practice of coding

In the same way, SoC breaks program functionality into separate modules that overlap
as little as possible. This allows individual sections to be updated or changed without
also needing to change the rest of the program.
Imagine you have developed a new program. The program works fine, but a few
months later your client would like you to make a change in one part of the program to
add a new feature. If you have used SoC, then it is relatively quick and easy to change
just the part of the code that is associated with the new feature. It should also be
easier to find out which part of the code you need to change.
In addition, the part of the code that you do not have to change is less likely to break
than code that you do change. If your features are mixed up together, you might
change the behaviour of one by accident while trying to change another one.
SoC can be thought of as a way of making program modular, so they can be more
easily updated and fixed.

Knowledge Activity: Describe SoC in your own words.

10 © LCG 2021
 Section 1: Understand the processes and practice of coding

What is meant by abstraction

Please read the following as it will help you to answer question 5.

Abstraction is a key concept in object-oriented programming (OOP) languages. Its main

goal is to handle complexity by hiding unnecessary details from the user. This allows
the user to implement more complex logic on top of the provided abstraction without
understanding or even thinking about all the hidden complexity.
Again, let’s look at an example in the real world. Imagine that you are a coffee drinker
and you have a very complicated coffee machine that makes really good coffee. When
you wake up in the morning, you switch on the coffee machine and the machine makes
the coffee.
You add the beans and water, and choose the setting on the machine for strong or
weak coffee, etc., but in order to make the coffee you don’t need to know exactly how
the coffee machine works internally. Someone else created the coffee machine and it
hides all these details. You just enter a few details (beans, type of coffee) that don’t
require any knowledge about the internal workings of the machine. This is an example
of abstraction.
Abstraction is a description of how a programmer hides all but the relevant data about
an object in order to reduce complexity and increase efficiency.
Objects in an OOP language like Java can provide an abstraction that hides the internal
implementation details. Similar to the coffee machine, you just need to know which
methods of the object are available to call and which input parameters are needed in
order to trigger a specific operation. You don’t need to understand all the details of
how the method is implemented and which kinds of actions it has to perform to create
the expected result.

What is meant by SOLID principles

Please read the following as it will help you to answer question 6.

SOLID is an acronym that describes a collection of five design principles for writing
clear and efficient code. The letters stand for:
• S: Single Responsibility Principle
• O: Open/Closed Principle
• L: Liskov Substitution Principle
• I: Interface Segregation Principle
• D: Dependency Inversion Principle
Workbook 2 11
 Section 1: Understand the processes and practice of coding

Single Responsibility Principle

We have already described this above. Single Responsibility Principle (SRP) states that
every class should have only a single responsibility. This means that there should never
be more than one reason for a class to change.

Open/Closed Principle
In object-oriented programming, the open/closed principle states that entities should
be open for extension, but closed for modification. In other words, code should be
written so that you can add new functionality without changing the existing code. That
prevents situations in which a change to one of your classes also requires you to adapt
all depending classes.

Liskov Substitution Principle

The Liskov Substitution Principle (LSP) states that objects in a program should be
replaceable with instances of their subtypes without breaking the program. In other
words, if S is a subtype of T, then objects of type T can be replaced with objects of type
S without any problems coming up.
Here’s an example using a pseudocode (it looks like a real code, but it’s not). In this
code snippet, we have defined a class (Bird) which can use the fly method. Then we
have extended this class to include a subclass of Duck.

public class Bird{

public void fly(){}
}
public class Duck extends Bird{}

Ducks can fly, so applying the fly method to the subclass Duck is not a problem.
However, suppose we want to extend the Bird class again by adding Ostriches:

public class Ostrich extends Bird{}

12 © LCG 2021
 Section 1: Understand the processes and practice of coding

An ostrich is a bird, but it can’t fly. Here, the Ostrich class is a subclass of Bird, but
it shouldn’t be able to use the fly method, and that means we are breaking the LSP
principle. To fix this, we can write the following:

public class Bird{}

public class FlyingBirds extends Bird{
public void fly(){}
}
public class Duck extends FlyingBirds{}
public class Ostrich extends Bird{}

Here, we have established a new subclass (FlyingBird) that applies the fly method.
Then, we have assigned Duck to the FlyingBird subclass, while assigning ostrich only
to the Bird superclass. Any new birds can now be added either to FlyingBird or Bird
without needing to change the code again.

Interface Segregation Principle

This principle applies to software developers. Put simply, it states that developers
should not be forced to depend on interfaces that they do not use. In other words,
having a number of client-specific interfaces is better than one general-purpose
interface.
An interface is a set of abstractions that an implementing class must follow. In
an interface, the behaviour is defined, but not implemented. For example (using
pseudocode):

interface Dog {
void bark();
}

Workbook 2 13
 Section 1: Understand the processes and practice of coding

Here, the Dog class is defined as having the bark method. The interface can then be
used as a template to implement the bark behaviour:

class Poodle implements Dog {

public void bark(){
// poodle-specific implementation
}
}
The goal of ISP is to reduce the side effects of using larger interfaces by breaking large
application interfaces down into smaller ones. It’s similar to the Single Responsibility
Principle, where each class or interface serves a single purpose. Using a single large
interface makes maintaining the program more difficult because of side effects: a
change in an interface forces programmers to make changes to classes that don’t
implement the interface.

Dependency Inversion Principle

The general idea of this principle is that high-level modules, which provide complex
logic, should be easily reusable and should be unaffected by changes in low-level
modules, which provide utility features. To achieve that, an abstraction is introduced
that decouples the high-level and low-level modules from each other.

The DIP has two parts:

• High-level modules should not depend on low-level modules. Both should depend on
abstractions.
• Abstractions should not depend on details. Details should depend on abstractions.

A real-world example for this may be to think about a car. Suppose the steering wheel
was connected directly to the car tyres. Every time you changed a tyre, you would
also need to make an adjustment to the steering wheel. This is not a good design, so
instead, there is an ‘interface’ between them that takes care of the communication
so they don’t have a direct link. We can say that the steering wheel acts like a high-
level module that handles complex logic, while the wheels are low-level modules that
provide utility features.

14 © LCG 2021
 Section 1: Understand the processes and practice of coding

Knowledge Activity: Imagine you are explaining SOLID to someone with no

coding experience. How would you do it?

What is meant by testing code?

Please read the following as it will help you to answer question 7.

Software or code testing is a very important part of the code development process.
Unless you test the code you write, you do not know if it works and you can’t easily find
errors.
There are different types of tests that can be performed but the goal of all of them is
to make sure that the code or program does what it is supposed to do and to find and
correct any errors. The type of test that will be used depends on exactly what is being
tested for. For example, is just a small section of code being tested, or is an entire
platform being tested? Different testing techniques will be needed in each case.
Tests can even be simple true-false statements that programmers place in their code.
A test checks for a certain condition, and if the condition is not met, stops your code
and alerts you to the problem.
Because there are so many different ways to test code, all software testing uses
some strategy to select the best or most appropriate tests for the available time and
resources.

Workbook 2 15
15
 Section 1: Understand the processes and practice of coding

Why is it important to test code?

Please read the following as it will help you to answer question 8.

Testing is a vital part of the development process. This is because:

• Tests can help identify problems early on.
• Testing can help ensure that any new features or modifications that are made won’t
break the existing code.
• When refactoring or removing redundant code, tests can ensure that the changes do
not affect the way the code works.
• Until you execute the code, you don’t know for certain if it will work.
• Tests can help you understand changes in your system’s performance and raise a flag
if something degrades significantly.

Here are some additional reasons why testing code is important:

Save money
Software development consists of many stages, and if bugs are caught in the earlier
stages, it usually costs much less to fix them than if they are caught at the end. This is
especially true when using tests such as Unit tests, which are designed to test smaller
sections of code. It is much easier and faster to find and fix issues in small sections of
code than in a large completed project.
Testing also allows you to resolve small issues before they turn into bigger issues –
which will take more time and effort to fix. On top of this, the maintenance costs of the
completed project will be lower if more bugs are caught before release. It is much more
expensive to repair code after the client has implemented it – the client may even
need to shut down their business for a time to allow you to fix the code. In contrast,
testing will help you to catch these types of serious problems before they can cause
expensive damage.

Security
Testing helps to ensure that the product is safe to use – this is an important element
in convincing people to purchase your product or app. Some types of testing are
designed to catch vulnerabilities in the code, allowing you to market the code as
secure and reliable.
Sometimes even the smallest security issues have brought huge problems to
businesses around the world, so it should always be important to assure top-notch
quality products to customers.

16 © LCG 2021
 Section 1: Understand the processes and practice of coding

Product quality
Testing can help ensure software works as planned and meets the project
requirements. For example, if you are developing an app, you want to make sure
before release that the graphics are aligned properly, the main functionality works, the
app is compatible with a range of devices, the menus are intuitive, etc. Often, after
developers fix one set of issues, other issues may appear unexpectedly somewhere
else, so it’s important to find and resolve those issues before the app is released to the
public.
Testing companies and testers usually have many tools available to cover as many
testing scenarios as possible.

Customer satisfaction
Customer trust is not easy to earn, especially if your product is glitching and functioning
only part of the time. By investing in testing at different stages in the product
development lifecycle, developers can ensure they are delivering high-quality product.

Requirements
Depending on who you are developing software for, and what it will be used for, testing
may be required by your client. This may be especially true for program that will be
used by government agencies, who want to make sure that any product they are paying
for works properly. There may also be industry-specific requirements for testing.

Workbook 2 17
 Section 1: Understand the processes and practice of coding

Methods of testing code

Please read the following as it will help you to answer question 9.

There are a huge number of tests that can be performed on code. On most projects,
several types of test will be performed at different times. Which test is used and when
can depend on the type of project and the goals of that project. For example, the
code for a small app with limited functionality will need different tests from a large
e-commerce platform.

Functional vs. non-functional testing

Test types can be broken down into functional and non-functional testing. Functional
testing involves testing the application against the business requirements. These types
of test are designed to make sure that each part of the software behaves as expected.
These testing methods include:
• unit testing
• integration testing
• system testing
• acceptance testing

Non-functional testing methods focus on how easy it is to use the software and
includes:
• performance testing
• security testing
• usability testing
• compatibility testing

Unit testing
Unit testing is the process of testing individual components of a program at the code
level to make sure these are functional and work as they were designed to. Developers
will often write and run unit tests before the software or feature is handed over to
the test team. Unit testing can be conducted manually but is often done using an
automated process to speed up delivery cycles and expand test coverage.
Unit testing make debugging easier because finding issues earlier means they take
less time to fix than if they were discovered later in the testing process.

18 © LCG 2021
 Section 1: Understand the processes and practice of coding

Integration testing
After each unit is tested, it is integrated with other units to create modules or
components that are designed to perform specific tasks or activities. These are then
tested as a group to ensure larger segments of an application behave as expected.
These tests are often framed by user scenarios, such as logging into an application or
opening files. Integrated tests can be conducted by either developers or independent
testers and usually involve a combination of automated functional and manual tests.

System testing
System testing is used to evaluate the completed and integrated system, as a whole, to
ensure it meets the specified requirements. The functionality of the software is tested
from end-to-end and is usually conducted by a separate testing team. This is done
before the product is put into production.
System testing is a type of testing called black box testing. Black box testing examines
the functionality of an application without examining its internal structures or workings.

Acceptance testing
Acceptance testing is generally the last phase of functional testing and is used to
assess whether or not the final version of the software is ready for delivery. It includes
ensuring that the product is in compliance with all of the original requirements and that
it meets the end user’s needs.
Acceptance testing is conducted by a separate testing team, which tests the product
both internally and externally. It may also include beta testing by end users, getting
feedback from potential customers, and testing by the quality and assurance team.

Performance testing
This is a non-functional testing technique used to determine how an application will
behave under different conditions. It can be broken down into four types:
• Load testing – this puts increasing amounts of simulated demand on the software to
make sure it can handle what it’s designed to handle.
• Stress testing – this is used to gauge how software will respond at or beyond its peak
load and find its failure point. The idea is to overload the application on purpose until
it breaks by applying both realistic and unrealistic load scenarios.
• Endurance testing/soak testing – this is used to analyse the behaviour of an
application over longer amounts of time. The goal is to understand how the system
will behave under sustained use.
• Spike testing – this type of test is used to find out how software will respond to spikes
in activity or demand.

Workbook 2 19
 Section 1: Understand the processes and practice of coding

Security testing
This testing technique is used to find vulnerabilities, loopholes and security risks in
the system that could result in unauthorised access. There are many types of security
testing, including:
• Vulnerability scanning – this searches for vulnerabilities.
• Security scanning – this is designed to identify network and system weaknesses.
• Penetration testing – this simulates an attack from a malicious hacker to check for
potential vulnerabilities.

Usability testing
This measures an application’s ease-of-use from the point of view of the end user.
It may be performed as part of system or acceptance testing stages. The goal is to
determine whether the design and aesthetics of an application meet the intended
design specifications and are easy for the intended users to use. It also helps find out
if the system as a whole is intuitive to use.

Compatibility testing
This gauges how an application or piece of software will work in different environments.
It is used to check that the software is compatible with the necessary operating
systems, platforms, browsers or configurations. The goal is to ensure that your
software’s functionality is consistently supported across any environment you expect
your end users to be using.

Knowledge Activity: Conduct research to find additional information about

one or more types of code testing, or about a type of code testing not
mentioned here.

20 © LCG 2021
 Section 1: Understand the processes and practice of coding

The characteristics of test-driven development

Please read the following as it will help you to answer question 10.

Test Driven Development (TDD) is a style of programming where coding, testing and
design are tightly interwoven. The TDD process reverses traditional development and
testing. So, instead of writing the code first and then using a unit test to validate the
code, in test-driven development the test is written first, expecting the code to fail, and
the code is then updated and changed until it passes the test.
Every new project starts with a test. This will fail because it takes place before any
features are implemented. The test helps the developer understand the requirement
before beginning to write the program code. After the code has passed the test, the
programmer refactors the code. This is when the code is restructured without changing
its external behaviour. This does not damage any existing functionality and helps in
removing duplication between production and test codes.
Code produced using this method is often cleaner and less prone to breaking in the
long run.
TDD consists of six basic steps:
• Determine the type of code needed – what it needs to do.
• Use this requirement to write a unit test.
• Write and implement the code that fulfils the requirement. Run the test on the code.
• If the code fails, refactor.
• Repeat step 4 until the code passes the test.
• Clean up the code by refactoring.

This workflow is sometimes called Red-Green-Refactoring, which comes from the

status of the tests within the cycle. The red phase indicates that code does not work.
The green phase indicates that everything is working, but not necessarily in the most
optimal way. There is also a blue phase, which indicates that the tester is refactoring
the code, but is confident their code is covered by the tests.
In this process, the code is first designed to pass the test but is not necessarily perfect.
However, knowing it has passed the test will give the programmer confidence that they
can quickly modify and update the code to meet all of the requirements. The main
requirement is that the size of each step should be small, with around 1 to 10 edits
between every test run.

Workbook 2 21
 Section 1: Understand the processes and practice of coding

The benefits of test-driven development

Please read the following as it will help you to answer question 11.

Test-driven development is a key part of an Agile project management process. This

is where requirements and solutions evolve through the collaborative effort of cross-
functional teams and their customers. A focus on test-driven development has a
number of benefits, including:
Improved productivity – test-driven development helps to increase productivity by
forcing coders to think about small chunks of code or functionality at a time. Coders
focus solely on getting each section to pass the test, before moving on, rather than
trying to tackle the bigger picture from the start. This also means that once each
section of code is completed, it is likely to be as bug-free as possible, which also saves
time.
Improved interfaces – because coders are working on a single piece of functionality at
a time, writing the test first means they also need to consider the public interface that
other code in the program needs to integrate with. This means that code will read well
and make more sense.
Safer refactoring – once a section of code has passed the test, then you know
that it works. This means it’s easier and safer to refactor that section or add new
functionality, because you can be confident that you won’t break the code.
Fewer bugs – test-driven development involves more tests, but this saves time later
on that would have been spent fixing bugs that only showed up nearer to the end of
the process. If a bug does come up later on, you can still write a test before attempting
to fix the problem, to ensure that the bug won’t come up again. This also helps define
what the bug actually is, before you try to fix it.
Decreased costs – the initial cost of developing a program in a test-driven
environment is higher at first, when compared to not writing any tests. But projects
that don’t have tests written first usually end up costing more. This is because they
are more susceptible to bugs and other issues. These will take longer to fix at the end
of the process than nearer to the beginning. This, in turn, makes the project more
expensive overall. Using test-driven development also means that it costs less to
change functionality later on, because the tests act as a safety net that ensures any
changes won’t break existing functionality.
Living documentation – tests can also serve as a form of documentation for
developers. In test-driven development, tests are written for different scenarios,
including for how a class or library will be used. So, reading through the tests can tell
you the expected inputs a method requires and what is expected as an outcome. This
means that program developed using test-driven development are easier to understand
and work on by coders who did not help develop the program in the first place.

22 © LCG 2021
 Section 1: Understand the processes and practice of coding

What is meant by a bug in relation to code

Please read the following as it will help you to answer question 12.

A software bug is a problem that causes a program or system to crash or produce

an incorrect or unexpected result, or to behave in unintended ways. A program that
contains many bugs, or has serious bugs that affect its functionality, is said to be
buggy (defective).
Bugs are caused by poor logic in the code and most bugs are due to human error in
developing the source code or in its design.
Sometimes, bugs do not have a serious effect on the functionality of the program, and
can remain undetected for a long time. A particularly serious type of bug is a security
bug. These are errors in the code that can allow a malicious user to bypass access
controls and gain unauthorised privileges.

Did you know?

The first bug? – There are many stories about the origin of the term ‘bug’
in programming. In one popular story, in 1947, a team at Harvard University
found that their computer, the Mark II, was delivering consistent errors. When
they opened the computer’s hardware, they found an actual bug – a moth –
squashed between the contacts of an electromechanical relay, preventing
the relay from fully closing. The bug was extracted with a pair of tweezers and
taped into the operator’s logbook with the comment, “First actual bug found.”
However, this comment makes it clear that is not the first use of the term ‘bug’
in engineering. Thomas Edison reported ‘bugs’ in his designs as early as the
1800s.

Workbook 2 23
 Section 1: Understand the processes and practice of coding

Did you know?

The Y2K bug – In the last century, software developers did not think about the
fact that some of their code might last past the year 2000. Many assumed that
writing “19” before the variable “year” was an unnecessary waste of time and
memory. So, most decided to omit these two digits.
This went unnoticed until we started getting close to the year 2000 and
programmers started to realise that many codes written in the 1990s were
still in use. At midnight, December 31st, 1999, these computer systems would
update their internal clocks to read January 1st, 1900 instead of 2000. Some
people worried that, because of this, computers all over the world would shut
down, major disasters would be unleashed and it would be the end of the world.
Although the world did not end, the Y2K bug was a real problem. Billions of
dollars were spent to upgrade computer systems to eliminate it. Most of the
issues were found, although some small incidents still took place: in Spain,
some parking meters failed; the French meteorological institute published on
its website the weather for January 1st, 1900; and in Australia, some bus-ticket
validation machines crashed.

What is meant by debugging

Please read the following as it will help you to answer question 13.

Debugging is the process of locating and removing bugs, errors or abnormalities. This
is often done using specialised software.
In the debugging process, complete software programs, or sections of program, are
compiled and executed to see what issues come up. When debugging large software
programs, which may contain millions of lines of source code, the program is first
divided into smaller sections. Each of these is then debugged, followed by the program
as a whole.
In the old days, programmers would observe some functional bug while testing and
then go back and search through the code to find the error. It wasn’t unusual for this to
take weeks or even months of work.
In contrast, today, reverse debugging systems track or monitor program while they run,
to make debugging more of an automated process.

24 © LCG 2021
 Section 1: Understand the processes and practice of coding

Bugs can be classified into several broad categories. Here are some of the most
common types:
• Token error – a token error occurs whenever a program contains a word or symbol
that is not in the programming language’s vocabulary.
• Syntax constraint error – these occur when the compiler cannot determine the
meaning of a program. For example, if a motorist asks for directions and we tell
them to: “Keep going for eight hundred just miles.” Technically, this sentence is
syntactically correct, because the word ‘just’ can be used as an adjective (to mean
‘morally right’) but in this context it is meaningless. Usually, the compiler will catch
this type of error.
• Execution error – this type of error occurs when the system is executing a program
and discovers that it can’t legally carry out an instruction (for example, if it is asked to
divide by 0). If an execution error is found, the execution of the program will stop.
Execution errors are often called run-time errors, because the runtime system can
detect them only when it tries to execute or run a program.
• Intent error – an intent error is often not picked up by either the compiler of the
runtime system. This results in the program being successfully executed, but an
incorrect answer is delivered.
Intent errors often occur early in the program and then later lead to execution errors.
In this case, the error can be hard to track down, because its effect is noticed at a
different location from the actual source of the error.
• Syntax error – a syntax bug is an error caused by something the programmer has
typed – it could be a spelling mistake or a command that the computer doesn’t
understand.
• Logical bugs – a logical bug is an error that means that even though the computer
is able to carry out its instructions, it doesn’t act as the programmer intended or the
user expects.

Workbook 2 25
 Section 1: Understand the processes and practice of coding

Knowledge Activity: Bugs

Find examples of different types of software bugs.

What is meant by continuous integration

Please read the following as it will help you to answer question 14.

DevOps (the word comes from ‘development’ and ‘operations’) is made up of a wide
number of working practices and tools that are designed to increase an organisation’s
ability to deliver applications and services faster than traditional software development
processes.
Continuous Integration (CI) is a DevOps practice where developers integrate code into
a shared repository. The code can then be verified by automated build and testing.
Usually, the code is uploaded into the repository several times a day.
This system is used to detect bugs and errors quickly. Because the changes at each
upload are usually very small, it is easy to pinpoint the exact change that caused the
problem and fix it before the problem can grow.
In recent years CI has become a best practice for software development and is an
important part of both continuous delivery and continuous deployment processes.

26 © LCG 2021
 Section 1: Understand the processes and practice of coding

What is meant by continuous delivery

Please read the following as it will help you to answer question 15.

Continuous delivery is an approach to making software updates and changes so that

these are done in a fast, reliable and efficient way.
Once software is released, it often needs to be updated, have new features added,
bug fixes released, configurations changed, etc. In continuous delivery, these changes
are made in small chunks and in a way that ensures the code is always usable – even
when there are many teams of developers making changes on a daily basis.
Continuous delivery involves keeping software updates small and incremental, with the
goal that an update can be delivered at any moment, whether that is into production or
directly to end users. It also ensures that delivery is made without disruption, by using
a sustainable and scalable process.
There are several different methods for continuous delivery. Generally, the software
is divided into different ‘branches’ or parts, with a team assigned to each branch. The
team makes updates to its own branch, using continuous integration to build and test
the code. Once this is done, the updated code is merged into the rest of the software.
This way, everything is kept running the entire time.

What is meant by continuous deployment

Please read the following as it will help you to answer question 16.

Continuous deployment is similar to continuous delivery, but goes one step further. In
continuous deployment, every change that passes all stages of your production pipeline
and passes its tests is released directly to customers – there’s no human intervention.
In other words, rather than releasing new versions of software on a particular day, each
software update is automatically released as soon as it has passed automated testing.
Automated builds, tests and deployments take place as one smooth workflow.

Workbook 2 27
 Section 1: Understand the processes and practice of coding

Knowledge Activity: Describe continuous delivery in your own words. How is

it related to continuous integration and continuous deployment?

The steps required for: continuous integration, continuous

delivery and continuous deployment
Please read the following as it will help you to answer question 17.

Steps for continuous integration

Although each developer may have their own process for continuous integration, here
are the basic steps:
• The coder or team updates a section of code.
• The section of code is uploaded to a continuous integration repository.
• Tests are run automatically from the repository – if a problem is found, the coder is
notified and fixes it.
• If no problem is found, the code is merged into the ‘main pipeline’ and integrated into
the software.

28 © LCG 2021
 Section 1: Understand the processes and practice of coding

Steps for continuous delivery

Again, each developer will have their own process for continuous delivery, but here are
some of the steps that are commonly used:
• The coder or team updates a section of code.
• The section is uploaded to a continuous integration repository.
• Tests are run automatically from the repository – if a problem is found, the coder is
notified and fixes it.
• If no problem is found, the code is merged into the ‘main pipeline’ and integrated into
the software.
• Deploy to staging – the software is evaluated by staging or production teams. This
includes testing the changes in a production environment by quality assurance
teams. Additional tests may also be conducted. For example, image security scanning
tools may be used to ensure the quality of images by comparing them to known
vulnerabilities.
• The changes are verified in a peer review – this involves other teams checking to
ensure the changes work as needed.
• The new section of code is merged into the ‘master’ code.
• A build and test is run on the entire master code. If it passes without error, it is
released to customers.

Steps for continuous deployment

As with continuous delivery, each developer will have their own process for continuous
deployment, but they will often include the following:
• The coder or team updates a section of code.
• The section is uploaded to a continuous integration repository.
• Tests are run automatically from the repository – if a problem is found, the coder is
notified and fixes it.
• If no problem is found, the code is merged into the ‘main pipeline’ and integrated into
the software.
• The software is automatically tested in a production environment.
• If no problems are found, it is merged into the master code.
• A build and test is automatically run on the entire master code. If it passes without
error, it is released to customers.

Workbook 2 29
 Section 1: Understand the processes and practice of coding

Did you know?

There are many companies that offer paid-for software-as-a-service tools that
developers can use to automate the continuous integration/continuous delivery
‘pipeline’. Here’s a typical continuous integration workflow used by one of these
tools, which we will call ‘S’.
• A developer creates a new branch of code in GitHub (this is a distributed
version-control platform where users can collaborate on or adopt open source
code projects), makes changes in the code, and uploads them.
• When the developer places their work on GitHub, S builds the code using
automated tools (this includes steps like downloading dependencies, installing
tools, and compiling and checking that the code is safe and follows best
practices).
• S then runs an automated test suite.
• If S detects any errors, the developer receives a Slack notification or sees a
message on their personal dashboard on the S system.
• If there are no errors, the developer receives a notification that the code has
passed continuous integration. S automatically deploys a new version of the
application to a staging server.
• The developer’s quality assurance teams can now test the changes in a
production-like environment.
• Once the developer has verified the changes in a peer review, the new branch of
code is merged into the master branch.
• S runs one more build and test on the master branch, and when it passes, the
new version of the code is deployed to production. The team gets a notification
about a new release via Slack.

30 © LCG 2021
 Section 1: Understand the processes and practice of coding

The differences between continuous integration, continuous

delivery and continuous deployment
Please read the following as it will help you to answer question 18.

Continuous integration, continuous delivery and continuous deployment can often

seem like the same process, or at least very similar processes. This is because they
build on each other.

Continuous integration

In this process, coders and developers make changes to small sections of code, and
then merge this section back into the main code, or main ‘branch’ of the code, several
times a day. These changes are validated automatically using a software platform that
conducts the build and runs automated tests against the build. This way, problems are
found and corrected quickly, and the software is kept up and running while changes
and updates are made.
Continuous integration emphasises using automated testing to check that the
application is not broken whenever new changes or updates are added to the main
branch. The key thing to remember is that continuous integration is often a part of
continuous delivery and continuous deployment.

Continuous delivery

Continuous delivery is an extension of continuous integration and also involves

automatically deploying all code changes to a testing and/or production environment
after the build stage. However, in addition to automated testing, continuous delivery
also involves an automated release process so that software can be deployed any
time.
In theory, with continuous delivery, developers can decide to release updates or
changes whenever it suits their business requirements – daily, weekly, etc. However,
they usually release small batches that are easy to troubleshoot in case of any
problems.

Workbook 2 31
 Section 1: Understand the processes and practice of coding

Continuous deployment

Continuous deployment goes one step further than continuous delivery. With this
practice, every change that passes all stages of the production process (also called
the production pipeline) is automatically released to customers. There’s no human
intervention, and only a failed test will prevent a new change from being deployed to
production.
With continuous deployment, there is no scheduled release day – instead, any new
changes or updates are released automatically as soon as they pass testing.

How the practices relate to each other

To put it simply, continuous integration is part of both continuous delivery and

continuous deployment. Continuous deployment is like continuous delivery, except that
releases happen automatically.

Explain what is meant by exception handling

Please read the following as it will help you to answer question 19.

In coding, robust means that software can cope with unexpected or incorrect input
without crashing or breaking. The incorrect or unexpected data could come from user
error or when a program receives incorrect data from external files. There are different
strategies for making sure that code is robust.
An exception is an unwanted event that interrupts the normal flow of the program
(when an exception occurs, this is often called ‘throwing an exception’ or ‘throwing
an error’). Exceptions could include events like opening a non-existing file, network
connection problems, bad input data provided by the user, etc. When an exception
occurs, the program stops running and the system generates an error message.
Exception handling is the process of using the code to respond to exceptions so
that the program does not stop running. The method used depends on the type of
exception. If the exception is a development error, this may be handled with rigorous
proofreading. Exception-handling techniques for logic errors or bugs usually involves
using debugging or troubleshooting software or methods. If the exception occurs in
runtime, then countermeasures can be used to allow the program to work around the
error.

32 © LCG 2021
 Section 1: Understand the processes and practice of coding

Example: Exception handling of a runtime error

Here is an example of exception handling of a runtime error in JavaScript.

try {
console.log(test);
} catch (err) {
console.log(“Error encountered: “ + err);
console.log(“Continuing with the rest of our program…”);
}

Here, console.log(test) tells the program to print the value of a variable named ‘test’
to the console (screen). However, the variable ‘test’ has not yet been defined, so the
console.log method generates an error.
Normally, this would cause the program to crash, but the exception has been handled
by enclosing the error-causing code in what is called a ‘try-catch’ statement. The
program ‘tries’ to run console.log(test), and if it works, the catch block (err) is skipped.
But if it causes an error, the error is ‘caught’ – instead of the program crashing, the
catch block is executed. As a result, the program will produce the output:

Error encountered: ReferenceError: test is not defined

Continuing with the rest of our program...

As you can see, exception handling requires thinking about what types of error might
be encountered with each section of code, and finding ways of making sure the normal
flow of the program can continue. Special applications can sometimes help automate
the process of exception handling. These can anticipate errors and help the program
recover without crashing.

Workbook 2 33
33
 Section 1: Understand the processes and practice of coding

Explain what is meant by defensive programming

Please read the following as it will help you to answer question 20.

Defensive programming is the practice of writing software to allow a program to

continue running while experiencing unplanned issues. Like with exception handling,
defensive programming involves anticipating things that are likely to go wrong and
writing code to handle these issues, instead of throwing exceptions.
Defensive programming practices are most often used where it is important that the
program remains operational (such as a web page) or where security is involved.
There are a lot of different ways to program defensively, depending on what you
are trying to accomplish with the code, the programming language and the control
structures being used. But the main considerations to keep in mind include:
• Validation: checking that the input data is sensible and in the right format.
• Sanitation: hiding or protecting data so it cannot be seen or disclosed.
• Authentication: verifying the identity of a user.
• Maintenance: ensuring a program is easy to understand, modify and update.
• Testing: checking the code for errors and bugs.
• Making the source code understandable: if the source code is easily readable and
understandable then it is easier to find and correct errors.
• Making sure the software behaves in a predictable manner even when unexpected
inputs or user actions occur. This can often be done by using exception handling
methods.

While defensive programming sounds like something that should always be applied,
there are risks as well. For example, if a programmer tries to anticipate and deal with
all of the exceptions that might happen, instead of the ones that are most likely to
happen, this could lead to a very long and unwieldy code. This, in turn, can make the
code slower to run and more expensive to develop.
Some developers prefer to let the code throw an exception and then fix whatever error
occurred. However, whether you decide to do this, or to use defensive programming,
will often depend on the type of program and what it will be used for. For example, if
the program is vital to the running or security of a company, it is probably better if it
does not fail very often!

34 © LCG 2021
 Section 1: Understand the processes and practice of coding

Example: Defensive programming

Pre-conditions are one of the most widely used types of defensive programming.
A pre-condition guarantees that a method can be executed only when particular
requirements are met. Here’s an example (in pseudocode):

public void CreateAppointment(DateTime dateTime)

{
if (dateTime.Date < DateTime.Now.AddDays(1).Date)
throw new ArgumentException(“Date is too early”);

if (dateTime.Date > DateTime.Now.AddMonths(1).Date)

throw new ArgumentException(“Date is too late”);

/* Create an appointment */
}

Here, users are supposed to enter a date for an appointment that is between two
dates. If they enter a date that is not between the specified dates, the program will
throw an exception that says the date chosen is either too early or too late. This will
prevent the user from setting an appointment on a date where it can’t happen and
leading to a more complicated error down the line (such as the user showing up for an
appointment that does not exist).

Workbook 2 35
 Section 1: Understand the processes and practice of coding

Summary

In this section you have learned about:

• the KISS principle
• the definition of single responsibility, abstraction and solid principles
• methods of testing code
• why it is important to test code and some different methods for testing code
• the characteristics and benefits of test-driven development
• what is meant by ‘bug’ and ‘debugging’
• the processes used in DevOps, including continuous integration, continuous delivery
and continuous deployment
• two strategies for creating robust code – exception handling and defensive
programming

36 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

In this section, you will find out about the importance and methods of communication,
including when to use different methods of communication and how to adapt
communication for different audiences. We will also define active listening and look
at some methods for active listening, before exploring ways of presenting information
clearly and the use of release notes.
We then move on to a discussion of feedback and how to give productive feedback.
Next, we will learn about project management, the role of the project manager and the
principles of Lean and Waterfall methods of project management. This section also
includes a discussion of the triple constraint in project management.
Finally, we will look at what is meant by Agile development and Scrum, and how these
work.

The importance of communication

Please read the following as it will help you to answer question 21.

The stereotype of a computer coder or programmer is often as someone who does not
communicate very well. But communication is actually a very important part of work as
a coder.
Communication skills are important when writing documentation for frameworks and
libraries, when sending emails or messages to co-workers on Slack or Asana, making
presentations and contacting clients. They’re also an important part of ensuring that
teams collaborate and work together well. Communication skills are also important to
your career development. Many organisations prefer to hire and promote only people
with good communications skills.
Here are just a few of the ways in which communications skills are used in software
design and coding.
• Understanding requirements – communication is vital to making sure that everyone
on the team, as well as the client, understands the project in the same way. To do
this, you will need to communicate any questions you have.
• Getting across your ideas – there may be times when you will need to communicate
complex ideas to clients or to a wider group of people.
• Feedback – there will be many times when you will need to give feedback about
the work of others. In order for this to be effective, you need to be able to make
suggestions in a supportive and effective way.
• Teamwork and planning – developers and coders usually work in a team. In a team,
it is crucial for you to be able to explain your thinking and the processes behind the
code to all team members.

Workbook 2 37
 Section 2: Understand the importance of communication and
project management in coding

• Talking to clients – you may often need to talk with clients. It is important that you
are able to communicate your ideas to clients and to understand their requirements.
This is especially important when you are talking to people who do not have the same
level of technical expertise.
• Improving diversity – good communication skills are an important factor for making
the tech industry more inclusive, by enabling people from different backgrounds to
work together.
• Although the focus in software development is often on technology, it is actually
people who decide what gets built, how it gets built, and when and where it gets into
the hands of people who will use it.

Knowledge Activity: Think about a time when you used good communication
skills to achieve something at school or work. Then think about a time when
you or someone else showed a lack of communication skills. What was the
difference in these two events?

38 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

Different methods of communication

Please read the following as it will help you to answer question 22.

There are many different methods of communication, including some, like art and
music, that we may not always think of as communication – especially in the field of
software development. In your work, however, you will mostly be relying on the types of
communication discussed here.

Verbal communication

Verbal communication refers to any time we use speech to send a message. Examples
include chefs hollering when an order is up, teachers verbally explaining concepts to
students and salespeople using convincing words to make a sale.
In the workplace, verbal communication can include both informal types of
communication like gossip and telling jokes, and more formal types of communication
such as a making presentations and contributing to discussions in meetings. It also
includes things like how loudly or softly we speak and the choice of words.
Verbal communication also includes speaking over the phone and video, from recorded
TikTok videos to business meetings conducted over Zoom with people in far flung
locations.

Non-verbal communication

Whether we realise it or not, a lot of how we react to other people has to do with non-
verbal communication – the way we communicate without using words. Although your
posture, hands and eyes can’t speak, they are saying more about you and how you feel
than you might think.
In business, non-verbal communication can be very important. In many organisations,
employees are expected to act and appear a certain way in order to be considered
professional. People around you pick up on the way you carry yourself and interpret
your gestures and body language as energy, interest and respect. For example,
slumping in your chair, having a glum expression and dressing sloppily can all give the
impression that you do not want to be there.

Workbook 2 39
 Section 2: Understand the importance of communication and
project management in coding

Body language, facial expressions and eye contact are some of the most important
types of non-verbal communications. Leaning back in a chair with an expressionless
face comes across as disinterested and unfocused. In contrast, sitting up straight and
looking into the speaker’s eyes conveys that you are interested and understand the
information being presented to you, even if that’s not really the case.
Proxemics is another part of non-verbal communication. This refers to the distance
between the speaker and their audience. This may seem unimportant, but imagine a
situation where the person you were speaking with stood so far away that you had to
raise your voice, or so close that when you made a gesture you accidentally hit them.
It is important to always be aware not only how you stand and move, but where you
stand and move.

Written communication

Written communication involves any time you use writing to convey information. This
includes tweets, emails, word documents, instant messaging, marketing material,
formal reports, letters, etc.
Written communication provides a record and is used to send large amounts of
information without the risk of someone forgetting, because it can be referred back to
for reminders.
In business, leaving a record becomes especially important, and so most businesses
rely heavily on written communication.
Written communication can also be used for conversations that are hard to have face
to face, or for communicating small bits of information where it is not important to
communicate face to face, such as the answer to a quick question. Some situations
will require a more formal communication style, while in others a quick email will be
enough – it is very important to learn when a situation requires a formal or informal
type of written communication.
For some, writing skills may be difficult to develop, and many people have problems
writing simple, clear and direct documents. In fact, one way to stand out at work is to
be able to write clearly and concisely in a variety of styles.

40 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

Knowledge Activity: Formal vs informal

Think about an organisation where you have worked or about your life in
general. When do you use informal types of written communication, such
as tweets, texts or addressing someone by their first name in an email?
When do you use more formal types of communication? Write down three
or four instances of each. Do they have anything in common? How are they
different?

Visual communication

Imagine someone describing a beautiful flower using only words. Now imagine them
using a photo. The beauty of the flower is probably much easier to understand
and picture with the photo. Visual communication is very useful in explaining or
understanding different concepts.
In business, visual communication is often used in this way, to help explain concepts
or to present information. Think about the use of graphs and charts in presentations.
These visual aids are useful because they can present a great deal of information
concisely and clearly.
Other forms of visual communication, such as photos, models and physical objects,
can also come in handy when you are struggling to find the right words to describe
something. If you are delivering information that is loaded with numbers or complicated
phrases, it may help to use some form of visual communication.

Workbook 2 41
 Section 2: Understand the importance of communication and
project management in coding

When to use different methods of communication

Please read the following as it will help you to answer question 23.

Verbal communication

This form of communication is best when you want to add a personal touch or get your
message across in a memorable way. For example, sales presentations, interviews,
employee evaluations and press conferences. Verbal communication is also a good
way to brainstorm and work as a group, because it encourages people to share and
communicate freely.
In face‐to‐face interactions, a person can judge how someone else is reacting and get
immediate feedback. In general, people often feel that talking to someone directly
is more credible than receiving a written message. Face‐to‐face communication also
makes it easier to see non-verbal cues like posture and facial expression. Of course,
verbal communication can also be very personal, so it is a good choice when you want
to express your support or gratitude to someone.
However, verbal communication also has its drawbacks. Sometimes people hear
only what they want to hear, instead of what was actually said, so it can be easy for
misunderstandings to happen in verbal communication. Verbal communication may
also be a poor way of conveying a lot of specific or detailed information, as people will
not remember everything that was said unless it is also written down for them to refer
to.

Written communication

This is the best form of communication to use whenever you want to create a
permanent or long-lasting record, or when you want to get across a lot of detailed
information. Written communication is necessary for many types of formal
communications, such as contracts, but is also helpful when you need a record of what
happened at events such as meetings – which is why it is a good idea to take notes or
‘minutes’ of verbal meetings.
Written communication is also the best choice when you need to distribute information
to a large number of people, whether this is advertising or a company memo outlining
a new policy or process that everyone needs to be aware of and comply with. Don’t
forget that written communication doesn’t need to be on physical paper, it can also be
digital.

42 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

The way you write can set the tone for how people will respond to you in person. It is
important to know when a situation calls for a casual written style, such as an email
addressed to a person by first name, and when it calls for a more formal style, such as
a formal letter or a report.

Non-verbal communication

You use this type of communication all the time, often without thinking about it. But
in a work environment it is important that you give thought to the type of non-verbal
communication you use. For example, are you dressing appropriately for your particular
workplace? Are you displaying a positive demeanour when talking to others – smiling,
nodding, making eye contact, etc? Are you using the right tone of voice and volume for
the situation? Are you being careful not to touch other people without their permission?
You may find that, in many situations, using appropriate body language can help you in
your work. For example, by indicating that you are interested and paying attention, or
by smiling, you can earn a reputation as a positive person and a team player.

Visual communication

You may find that you most often use visual communication when giving presentations
or talks. However, visual aids may also be useful in non-formal situations – for
example, when you need to discuss complicated or detailed information, or information
with a lot of numbers and figures. Visual communication can be used any time that
you feel it could be helpful in explaining something or making information more clear,
concise and easier to understand.

Workbook 2 43
 Section 2: Understand the importance of communication and
project management in coding

The importance of adapting communication for different

audiences
Please read the following as it will help you to answer question 24.

Just as you would not start an email to your best friend by writing ‘Dear Sir,’ you would
also not address a client you have never met before as ‘Hey buddy’. In other words,
you need to always adapt the way you communicate to the audience.
Of course, this will be different in every organisation and situation – some
organisations and people are much more informal than others. You will need to watch
how others communicate in order to find out what is right. In general, however, when
you are unsure of what is expected, it is better to start off by being more formal. It is
also important to try and be yourself – people will pick up on it if you are being fake or
stilted.
Some ways of matching your communication to your audience include:
Match your vocabulary to the audience. Know when you need to be formal and when
informal. Changing your vocabulary to fit the situation can help you better connect
to people. This includes making sure that you use words that the other person will
understand or expect – if you are talking to other software engineers, you can use
highly technical language, but when talking to clients with no technical knowledge, you
will earn their trust by knowing how to simplify concepts without talking down to them.
Vary your tone to fit the situation. Tone can tell the listener a lot about the situation.
You may use a serious tone while discussing a product delay with your manager,
an encouraging tone while helping a fellow employee or a casual tone while out
with friends. When you adjust your tone, make sure that your non-verbal and verbal
communication match, which will show sincerity. For example, a firm, serious tone
would be undermined if you were also smiling and slouching, while an encouraging
tone that is accompanied by nodding and smiling helps to give the feeling that you
care.
Try to schedule face-to-face meetings when discussing new or complicated topics, even
if you feel like you could address the topic in an email. That way, you will give people
an opportunity to ask questions and make sure everyone understands the topic.
Always use social media professionally. By now, it is clear what can happen if you
post something unprofessional where it is visible to the public. Keep workplace social
media posts positive and concise, and stay away from anything that can be interpreted
as controversial. If you interact with co-workers, employees, or customers on social
media, steer away not only from personal attacks, but also from venting, complaints
and images that could be interpreted as inappropriate. Always assume that anything
you post online can be seen by the public.

44 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

Tailor your presentation to fit your audience. It’s important to know your audience
so that you can shape your message to fit them. When giving a presentation, you
should know who will be in the audience, a bit about their background and why they’re
attending. The more information you have, the better you can shape your presentation.
For example, if you are making a formal presentation to a group of senior executives,
then your language should be professional and polished. However, if you are speaking
at a brainstorming session with colleagues, you may want to include jokes and
casual discussion. You should also try to be aware of the background of people in the
audience to make sure that you don’t inadvertently use language or behaviours that
are offensive.

Knowledge Activity: Imagine you are giving three different technical

presentations to three different groups of people: your colleagues, clients
with some technical knowledge and users with no technical knowledge.
How would you change or adapt your presentation to each group?

Workbook 2 45
 Section 2: Understand the importance of communication and
project management in coding

What is meant by active listening

Please read the following as it will help you to answer question 25.

Active listening is a way of listening and responding to another person that improves
mutual understanding. In active listening, the listener makes it clear that they
are interested in what the speaker is saying, and that they are doing their best to
understand the facts and the feelings they hear.
Some of the key elements of active listening are that the listener:
• focuses fully on the speaker
• avoids interrupting
• shows interest
• avoids appearing judgemental
• provides feedback, either verbally or non-verbally

Methods of active listening

Please read the following as it will help you to answer question 26.

The main point of active listening is to show your interest and engagement in what the
speaker says. Here are a few of the methods for doing this.

Don’t drift off

We can all have the tendency to drift off while someone is speaking, especially if we
are tired or the subject does not particularly interest us. But drifting off shows that you
are not listening and can alienate or discourage the speaker. To prevent this, you can
mentally repeat to yourself what the speaker has just said. Another way to stay alert
and focused is to make physical notes. If you are becoming distracted by noise, you
can also suggest a move to somewhere quieter.
It is also important that you are not being distracting, for example, by playing with your
pen, or looking at your watch or your phone.

46 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

Minimise interruptions

Try not to interrupt the speaker unless you have to. A lot of the time we spend listening
to people is actually taken up with rehearsing what you are going to say when it is your
turn to speak. For many people, once they have decided what they are going to say,
there is a temptation to jump in and say it as soon as possible so that you don’t forget.
But you should resist this impulse. Again, taking notes can help with this.
You can also use body language to signal to the speaker that you have something to
say. For example, by having your lips apart and leaning towards the speaker. Similarly,
in order to signal that you are actively listening, keep your mouth physically closed
and lean slightly back. If you find it difficult to stop yourself saying something, one
technique is to rest your chin lightly on your hand.
Keep in mind, though, that some types of interruptions can actually signal that you are
actively listening. For example, asking the speaker to clarify something.
Keep in mind that active listening is also about patience – accepting pauses and
short periods of silence. You shouldn’t always be tempted to jump in and fill any silent
moment – the speaker may be using this time to gather their thoughts. Active listening
involves giving the other person time to explore their thoughts and feelings.

Show you are listening

If someone is speaking to you and they don’t get any feedback, they will find it very
difficult to carry on. You can show you are listening with non-verbal cues, such as
smiling or nodding to show your interest, or non-intrusive verbal cues, such as with
expressions like ‘Uh huh’ or ‘Hmm’.
Making eye contact can also show active listening, but if the speaker is shy, this can be
intimidating. You will need to gauge how much eye contact is appropriate for any given
situation.

Workbook 2 47
 Section 2: Understand the importance of communication and
project management in coding

Staying neutral

As far as possible, remain neutral until you have heard the speaker out. Giving your
opinion too soon can give the impression that you are anxious to move on or are not
interested in what they have to say.
Being judgemental can also be conveyed through what appears to be a positive
attitude. This is called ‘passive aggression’. For example, saying something like “Nice
to see you are on time” might give the impression that you think the person is often
late or that you hope this is not going to take long.
You should also try to avoid making assumptions about the speaker based on ways
they are different from you. This can prevent you from understanding fully what they
are trying to say.

Knowledge Activity: Making assumptions

Take a look at the following list of objects and write down what each item
suggests about the gender, age, beliefs, likes, dislikes or interests of the
person who owns them. Then consider what assumptions you have made in
making your list. What could be an alternative reason for the person to own
these items? What would this alternative reason say about the person?
Porsche 911
Set of golf clubs
Rosary or prayer beads
High-end laptop computer
Screwdriver
Electric bicycle

48 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

Give feedback

In order to reduce the impact of your own assumptions and attitudes, it is important to
provide the listener with feedback. It is a way of demonstrating that you are listening
and checking that you have understood what you have heard. Some ways that you can
give feedback or demonstrate that you have understood the speaker are by:
• Paraphrasing – putting what the speaker has said into your own words. This
demonstrates that you are listening carefully and trying to understand. It also
gives the speaker an opportunity to correct anything you have misunderstood and
encourages them to offer further explanation.
• Summarising – you can provide an overview and frame your response by summing up
the whole discussion, perhaps starting by saying something like, “Let me make sure
that I have understood …” You can also use this technique to check the accuracy of
your own understanding.
• Reflecting – focusing on the emotion behind the words can help to show
comprehension. For example, if someone seems confused by the situation they
are describing, you might include a comment such as “… and you feel confused by
this.” This can both reinforce the message of the speaker and demonstrate your
understanding.

Asking effective questions

This is another way to demonstrate that you have been listening. Some types of
questions that can help you signal this include:
• Open questions – use these to gather information and facts. For example, “What are
your main concerns about this situation?”
• Probing questions – these are asked to gain additional detail, such as, “Can you
explain how that works?”
• Hypothetical questions – you can use these to suggest a new approach or introduce a
new idea. For example, “If we had funding or resources, how might that help?”
• Reflective questions – these can be used to check understanding. For example, “So
you are saying that you would prioritise the most critical areas for attention first?”
• Leading questions – these can be used to help the speaker reach a conclusion, if
they are struggling. One example might be, “Have you thought about asking your
manager for help?”

Workbook 2 49
 Section 2: Understand the importance of communication and
project management in coding

• Deflective questions – these can be used to defuse an aggressive or difficult

situation. For example, if the speaker says, “I’m very unhappy with this project
because no one is working hard but me,” you could respond by asking, “What do you
think is the best way of getting everyone to work hard?”

Ways of verbally presenting information and ideas clearly

Please read the following as it will help you to answer question 27.

There are a huge number of ways of presenting verbal information. Here are some that
will help you to present information clearly, whether in informal or formal situations:
• Know your audience – consider who you will be delivering your presentation to. How
much do they know already? What types of questions will they have? What do they
expect to hear? Try to answer these questions in advance, so you are prepared.
• Know your material – if you know very little about the subject, this will come out in
your presentation. Spend time researching and thinking about the information you
wish to share. Think of ways to present the information in an engaging and interesting
way. In your presentation, stick to the key points, to ensure that you do not bore your
audience.
• Structure the presentation – create an organisation for your presentation and stick to
it. Using cue cards, notes or slides can help with this. Keep in mind that memorising
everything that you intend to say may result in a robotic and/or monotonous delivery.
• Practise – even for an informal conversation, it can help to practise or go over what
you want to say and how you will respond to questions.
• Manage your nerves – if you are giving a presentation to a group, walking around
or using gestures can help you work off nervous energy. Make sure to breathe, and
pause to take a sip of water and gather your thoughts. One trick is to smile while
you speak (if it’s appropriate to the subject) – this will give you a more energetic and
upbeat delivery.

50 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

How release notes are used to communicate information to

others
Please read the following as it will help you to answer question 28.

Release notes are the technical documentation produced and distributed alongside the
launch of a new software product or a product update. They very briefly describe the
product or detail the specific changes included in a product update. The primary target
audience is the product user, but release notes can also be used internally.
The release notes should provide relevant information about the product or update,
but are not as detailed as a user guide. Typically, release notes will include information
such as why the product was developed or the changes that have been made since the
last release, how this is going to affect the user and what the user might need to do
differently.
A well-crafted release note should:
• Use plain language.
• Be short and to the point.
• Be easy to read – for example, if there are fixes, improvement and new features,
these should all have their own headings.
• Include relevant links to more in-depth information, such as to a user guide, step-by-
step walk-through or a video tutorial.
• Give an idea of the organisation’s brand and personality – release notes can be used
to develop a community of users and deepen relationships with customers.

Workbook 2 51
 Section 2: Understand the importance of communication and
project management in coding

Did you know?

Release notes examples
Here are a few ways that different software companies have made their release
notes easily accessible to users.
1. Intercom
This company releases their release notes at: www.intercom.com/changes/.
Calling the notes “changes” is a way to reduce formality and lower users’ anxiety
about any changes that are taking place.
2. InVision
This company organises their release notes by product, with a “what’s new”
section at the top followed by “what’s fixed or improved”. This makes the
information easy to find. Users can easily click on the sections that matter
most to them. Their release notes also include links to various support
documentation and help articles.
3. HubSpot
This company has created product spotlight videos that take their users on a
tour of how the product has grown over the course of the last month.

52 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

Ways of seeking feedback on communications

Please read the following as it will help you to answer question 29.

In order to learn and grow in your work, it is important to get useful feedback on your
communications skills. However, this won’t happen automatically – you will need to
use different ways to seek feedback on your communications. Here are a few of those
ways.
Asking – it sounds obvious, but people often assume that their communication
skills are fine and don’t think to ask. Seek feedback from your line manager or from
colleagues with informal conversations or by using feedback or suggestion forms. Make
it clear that you are seeking constructive ways to improve.
Ask clarifying questions – if you receive feedback that surprises you, asking questions
will give you a clearer picture. Asking questions and listening to specific suggestions
will help you understand the full scope of the feedback and ways that you need to take
action to improve.
Get feedback from a range of different people – asking your line manager for
feedback is important, but other people in your team or department can also be of
help. People who you work with on a daily basis may also be in a position to see things
in your communications that your line manager does not.
Ask for feedback in real time – if you want some insight into how you did on a
particular task or how you might improve on the next project, it’s best to ask sooner
rather than later. You don’t have to use a formal approach, you can take an informal
approach – for example, taking your line manager or a colleague aside after a meeting
and requesting their reaction to your role on a recent project. You can also send follow-
up emails or use surveys. Sites like Survey Monkey allow you to easily make and send
free, anonymous surveys.
Pose specific questions – it is better to ask specific and direct questions, rather
than an open-ended question such as, “Do you have any feedback for me?” Instead,
consider posing questions such as, “What’s one thing I could improve on?” or “What’s
one thing I could have done better in that meeting or presentation?” Avoid asking
questions that are likely to result in yes or no answers and opt instead for questions
that begin with ‘how’ or ‘what’.
Ask for examples – to get the most out of the feedback you receive, you may want
to ask for specific examples. For example, if you are told that you need to be more
assertive, ask additional questions like, “Can you explain what you mean?” or “What
kinds of things should I do to be more assertive in the future?”
When working virtually or remotely, ask more frequently – it can be particularly
hard for virtual team members to get regular feedback, since physical distance often
prevents informal exchanges. In this case, you may need to ask for more input,
perhaps by making calls instead of relying on email.

Workbook 2 53
 Section 2: Understand the importance of communication and
project management in coding

Knowledge Activity: Case study

Case study #1: Get the right feedback to grow
Meghan works in online marketing and is getting a lot of feedback from her
boss; most of it is praise about her performance. But her boss wasn’t telling
her anything that would help her to get better in her work or to have more
impact.
After thinking about the kind of feedback she needed, Meghan decided to
approach her boss. She told him she wanted to take steps to move up the
company, rather than just stay where she was. Meghan asked him to create a
specific set of goals for her. She asked him what it would take to impress him
enough to promote her.
As a result, her boss began giving more constructive feedback, including
details of how she could expand her duties and stretch her skills.

54 © LCG 2021
Section 2: Understand the importance of communication and
project management in coding

Knowledge Activity: Case study

Case study #2: Keep your questions narrow
Bob, a network engineer at a telecoms company, wasn’t getting much
feedback from his line manager, and when he did, it was usually basic and
vague, things like, “you’re very friendly.” So, he asked a client for feedback,
asking specific questions about what he thought went well and what could
have been improved.
Bob then went to his boss, told her about the feedback he’d received from
the client and asked his boss for constructive criticism of his work with
specific questions like, “How effective would you rate my leadership style?” or
“How do you think I could have handled situation X better?”
Once his boss knew the type of feedback Bob wanted, she was able to give
him more useful feedback.

Workbook 2 55
 Section 2: Understand the importance of communication and
project management in coding

The purpose of using feedback to develop communication

skills
Please read the following as it will help you to answer question 30.

Feedback is essential to good communication and collaboration because it makes

you aware of what you can do to develop and improve, and it builds trust in your
relationships with team members.
Feedback is about listening actively, taking the time to analyse what others are saying
and then considering the best possible way to perform better. Feedback can help
individuals and teams to improve their focus and develop their skills. It also brings
people together and creates a healthy communication flow.
Like any communication skill, feedback – how to seek it, how to give it and how to
receive it – must be practised regularly.
When someone asks you for feedback, try to give them constructive feedback. In other
words, don’t only be negative or only positive – phrase your feedback in a way that
gives the person something they can work on to improve. Similarly, when asking for
feedback, try to ask specific questions, so that the feedback you get is useful.

What is meant by productive feedback

Please read the following as it will help you to answer question 31.

Not all feedback is helpful. For example, if all someone ever hears is that they are
bad at something, they will become demotivated and will not improve. Instead, it is
important to give productive, or constructive, feedback. This is supportive feedback
that helps to identify possible solutions to areas of weakness. It is used as a supportive
communication tool to address specific issues or concerns.
It is not always easy to know how to give constructive feedback. Here are a few
important things to keep in mind when giving constructive feedback.

Be specific
Focus on a specific situation, incident or question. Use specific examples and details.
This helps the person receiving feedback to focus on exactly what they need to do
to improve. For example, avoid saying things like, “Your reports are difficult to read.”
Instead, you could say, “Make sure you always use spellcheck on all your reports and
have someone read them first before they are finalised.” Focusing on specifics will also
help you to remain impartial.

56 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

Be sincere
Whether it is positive or negative, feedback should be honest and genuine. Avoid giving
mixed messages, which are often referred to as “yes, but” messages. For example,
“John, you have worked hard on this project, but …” – putting “but” in the middle tells
the other person, “Don’t believe a thing I said before,” and can lead to antagonism or
anger, which is not helpful.

Be timely
Feedback should be given as soon as possible after an issue comes up. Otherwise,
negative habits can become entrenched and achievements forgotten. Waiting too
long can also mean that details are forgotten and it then becomes harder to take the
feedback on board.

State observations, not interpretations

Observations are what you see; interpretations are your analysis or opinion of
what you see. Instead of telling the other person what you think or feel about their
behaviour, stick to observations. Tell them what you’ve noticed, not what you think of
it. Observations tend to be more factual and non-judgmental than interpretations. For
example, instead of saying, “Drinking too much coffee makes you hyper and hard to
work with,” you could say, “I have noticed that when you drink coffee at lunchtime your
work suffers.”

Example: Feedback techniques

Here are a couple of examples of good and bad feedback techniques.

Bad: “Your sales numbers are rising, which is great, but we have noticed that you tend
to avoid working with the rest of the sales team. That said, you are also very punctual
on the job.”
Good: “We would like you to work more with your team. That said, your sales numbers
are on the rise and we have also noticed that you are very punctual, that’s great. Keep
it up.”

Many people use the sandwich technique to give feedback, giving a negative statement
between two positive ones. But this does not always work well – the constructive
feedback can easily get lost amongst the positive statements, and the other person
tends to focus on either the negative comment or the positive one, so doesn’t know
what they are supposed to focus on.

Workbook 2 57
 Section 2: Understand the importance of communication and
project management in coding

Bad: “Your presentations are very confusing. You need to do better.”

Good: “Your presentations aren’t as clear as they need to be. From now on add
concrete data to back up your points, and use bulleted lists, graphs and other visual
aids to make things easier to read.”

Here, the good feedback gives specific examples for how to improve, so it is very
helpful. Simply telling someone to improve does not help them to know how to
improve.

What is meant by project management

Please read the following as it will help you to answer question 32.

Project management is the process of planning and organising projects. It involves

using all of the available resources, knowledge, skills, techniques and tools to move
a project forward to successful completion. It can involve a one-time project or an
ongoing activity. The work is usually undertaken by a trained project manager.
Project management is particularly important in fields such as engineering,
construction, software development and other areas that involve a lot of people
working on different parts of a project that all need to be completed and assembled in
a particular order and time-frame.
Project management may involve creating and managing a project budget, scheduling
work, agreeing and managing deadlines, organising work tasks, hiring, monitoring
progress, etc. The exact steps and organisation of the tasks will depend on the type of
project. In general, the project management process involves five stages:
• planning
• initiation
• execution
• monitoring
• closing

58 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

There are different methodologies used in project management. Some of the most
common include:
Waterfall
In this system, each task needs to be completed before the next one starts. Steps are
linear and progress flows in one direction – like a waterfall. Because of this, project
management focuses on task sequences and timelines. The size of the team working
on the project will grow as smaller tasks are completed and larger tasks begin.

Agile Project Management

This methodology is commonly used in computer software development. It is
an iterative process focused on the continuous monitoring and improvement of
deliverables, or products. Agile project management does not follow a sequential step-
by-step approach. Instead, different phases of the project are completed in parallel to
each other by different teams. This allows errors to be found and fixed without having
to restart the entire process.

Lean Project Management

This methodology is all about avoiding waste of time and resources. The main idea is
to create more value for customers with fewer resources.

The role of a project manager

Please read the following as it will help you to answer question 33.

Project managers take the lead in planning, executing, monitoring, controlling and
closing projects. They are often responsible for the project scope, project team,
resources and even the success or failure of the project.
Effective project managers need both technical know-how and very good organisational
and problem-solving skills. The project manager is the ‘point person’ for the project and
will often be the person that project members come to first when there is a problem or
when they need more resources. The project manager may also liaise with clients, and
they may represent the project to the board of directors, if there is one.
They also need to be knowledgeable in many different areas of the organisation, as
well as having specialised project management skills. Luckily, there are many project
management tools and platforms that can be used to help organise the work.

Workbook 2 59
 Section 2: Understand the importance of communication and
project management in coding

Project management may involve the following work:

Initiating phase
• developing the project goal
• organising the start-up meeting
• identifying stakeholders

Planning phase
• developing a project management plan
• defining and managing the scope of the project, creating a breakdown of the work,
gathering requirements for the project from the stakeholders
• developing schedules and activities, estimating resources
• estimating costs and determining budgets
• identifying quality requirements and planning the QA process
• identifying human resource needs
• planning what communications will be needed and how they will be organised
• identifying potential risks, performing qualitative and quantitative risk analysis, and
planning risk mitigation strategies
• identifying necessary materials and tools
• planning stakeholder communications for the project

Executing
• directing and managing all work for the project, including timelines and budgets
• selecting, developing and managing the project team
• managing all aspects of communications between teams and with stakeholders
• securing the necessary material, tools and equipment
• managing all stakeholder expectations – for example, communicating changes in the
project scope or deadline
• managing regular project and/or team meetings

Monitoring and controlling

• monitoring and controlling the project work and managing any necessary changes
• validating the scope of the project
• monitoring and managing project costs

60 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

• monitoring the quality of deliverables to ensure they meet the planned expectations
• monitoring all team and stakeholder communications to ensure they are going as
planned
• monitoring and controlling procurements, making sure everyone has the resources
they need to complete the project on time and on budget

Closing
• closing out all phases of the project
• closing out all project procurements, making sure all contractors have been paid

Knowledge Activity: Imagine you are planning a party for a friend or family
member. Act as the project manager for the party. What will you do at each
stage to manage the party? How is this different from managing a work
project?

Workbook 2 61
 Section 2: Understand the importance of communication and
project management in coding

The principles of Lean project management

Please read the following as it will help you to answer question 34.

The Lean project management method began in the Japanese manufacturing industry
in the period after World War II. It is a method for systematically eliminating waste. It
takes into account waste created by events such as uneven workloads.
In Lean projects, work is seen from the point of view of creating value for the client.
Here, ‘value’ is defined as any action or process that a customer is willing to pay for,
or that generates customer satisfaction by serving a need, performing a job, improving
the business position or accomplishing a mission. Lean teams constantly review their
product and service from the eyes of the customer.
In the Lean approach, any aspects of production that do not add value are reduced.
For example, if a particular process is not adding value, it is eliminated. Lean
techniques aim to help organisations adapt to changing market conditions and
requirements. The following are key principles in Lean project management, in the
order in which they are applied in Lean project management.

Identify value

The first principle is to clearly define and create value for customers. In order to do
this, teams continuously evaluate the product from the customer’s point of view. They
may do this using qualitative and quantitative techniques in the form of surveys or
interviews to determine customers’ requirements.

Map the value stream

Once the key values are identified, all the processes that contribute towards generating
those values are noted, and all the other processes are considered as waste. The
processes that are wasteful are then either eliminated or reduced. By reducing waste
from the value stream, costs are reduced and projects can be sped up. Eliminating
waste can also lead to greater customer satisfaction because projects deliver greater
value at a lower price.
Example: Value stream mapping
Imagine you are working for a company that manufactures tables for primary school
classrooms. You work with your team to identify every step it takes to go from a stack
of raw materials to a table ready to be used in a classroom.

62 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

For example, you would start with the materials, and ask questions such as:
• Where do we put the wood after it is delivered by the supplier?
• Does the wood come to the factory pre-cut or do we cut it to specifications? Who does
that?
• Where do we source the wood glue, nails and sealant?

For the production process, you could ask questions such as:
• Where do we keep the tools and materials needed?
• Who handles the production process?
• How are the tables produced – for example, does one person make a table from start
to finish or is it an assembly line?
• Are large orders produced in the same way as small orders?

For sales and customer service, questions could include:

• Do we know who the decision maker is in each school?
• Is the need for tables likely to grow or shrink in the future?
• When a customer needs to order a table, what steps do they go through? Who do they
talk to at our company?

Flow creation

Once the value stream has been mapped, organisations analyse each step in the
process, finding ways to maximise efficiency and reduce waste. As part of this, any
steps that cause friction or delays are removed, the workload is redistributed and the
production steps are changed to make the project run more smoothly and focus on
delivering value. The guiding question for this principle is: how can we think in a smart,
streamlined way to provide the most value to our customer?
Example: Creating flow
Let’s return to our table manufacturing example. In flow creation, a Lean manager
might ask their team:
• What tools do we need for each step and are each of these tools needed every day for
production to run smoothly?
• Can we abandon the traditional assembly line model and approach the production
process in a new way that reduces the time between steps?

Workbook 2 63
 Section 2: Understand the importance of communication and
project management in coding

Establish pull

This principle aims at reducing excess inventory and excess work, both of which are
considered huge wastes. One strategy for reducing inventory and work is to understand
when exactly the customer needs the value, or product, and when they will ‘pull’ the
value from the industry. In other words, when will they order or use the product.
By finding out exactly when the product will be needed or used, the project timeline can
be changed to focus on delivering the product exactly when it is needed. This is called
‘just in time’ delivery. This, in turn, helps to eliminate waste by reducing the amount
of inventory, resources and/or workers that need to be kept on hand, and helps to
establish a smooth workflow.

Seeking perfection

This principle is at the heart of Lean project management. Of course, perfection can
never really be achieved. However, the idea of ‘seeking’ perfection is a way to focus on
continuously improving the implementation of the first four principles.
Lean teams constantly analyse each process for ways to increase the value (for
example, by reducing cost, time, resources used, space needed, etc.). They focus on
the elements that add value and eliminate those that do not. The goal is to create a
culture, or mind-set, of continually striving for perfection. This concept is also called
continuous improvement.

The principles of Waterfall project management

Please read the following as it will help you to answer question 35.

Waterfall project management describes a sequential or linear flow of work, in which a

team completes the different steps in a project in stages, one stage after another, like
the way water cascades from the top of a waterfall downward. The Waterfall method is
also known as the traditional approach to project management.
There are three key principles that govern the Waterfall approach:
• Sequential project structure – project activities are broken down into sequential
phases. Because it is difficult and/or expensive to return to a stage once it has been
completed, once each step is completed, it needs to also be validated or tested to
make sure that it works.

64 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

• Minimum customer involvement – in Waterfall project management, clients or

customers usually do not participate except at certain milestones. Client and
customer participation usually takes place during status meetings, reviews and the
approvals stage.
• Strong project documentation – the Waterfall method requires project managers to
gather a lot of details about the project at the beginning of the process. These details
might include the criteria the project needs to meet, the specific skills needed to
complete the project, the timeline and the breakdown of the individual steps of the
project. All of these details are documented and followed throughout the project life
cycle.

How does the Waterfall methodology work?

In software development, Waterfall project management follows five distinct phases, or
stages. Complex projects may need more than five phases, but no matter the number
of phases, the next phase does not begin until the previous phase is complete. Each
stage also usually involves sign off by the project stakeholders.

The stages usually involve:

• Requirements – the team gathers client and end-user needs and expectations and
uses these to determine the project requirements.
• Design – this is also referred to as the ‘analysis’ stage. It is where teams evaluate the
requirements and then use these to create specifications for what the final product
would look like, how it will work and the steps needed to get there. This is also when
the project management plan is worked out for the following phases.
• Implementation – in this stage, teams carry out the project plan to develop the
product, overseen and organised by the project manager. This is when the actual
coding begins.
• Verification – this is also known as the ‘testing’ phase. This is when the QA teams
test the product for errors. After unit testing, individual units are integrated into a
final product. This is also tested and checked to make sure that all of the project’s
requirements have been met. User testing may also be carried out in this stage.
• Maintenance – the maintenance stage begins as soon as customers start using the
product in the real world. It involves modifying or updating the product or its individual
components based on user feedback, requests from the client, or newly detected
system.

Workbook 2 65
 Section 2: Understand the importance of communication and
project management in coding

When to use Waterfall project management

The Waterfall method is not always the best project management option. Because it
is very difficult for teams to make changes to a completed phase, projects that rely on
constant user feedback and multiple development cycles to create the final product
are probably better off using a different approach.
The Waterfall method makes the most sense to use when:
• The project’s requirements are well defined and can be gathered before work on the
project begins.
• The project’s scope is well understood by everyone involved.
• The client prefers limited involvement in the project.
• The project’s budget and timelines are fixed and immovable.

What is meant by the triple constraint

Please read the following as it will help you to answer question 36.

The triple constraint is a way of describing the three most important restrictions on any
project: scope, schedule and cost. The triple constraint is also sometimes referred to
as the project management triangle or the iron triangle.
Each part of the triple constraint affects every other part. For example, if a client asks
for more features to be added, this will increase the cost and time needed to finish the
project. Or, if the project budget is cut, then the scope may need to be reduced in order
to finish on time. It is the job of the project manager to balance the triple constraints
and manage everyone’s expectations so that the project can be successfully
completed.

Scope
In order to clearly understand the scope of a project, it is important to document all
of the project goals and requirements before work begins. This can prevent the scope
from expanding for no reason during the project. The project manager needs to monitor
any changes in the scope so they can also make any changes to time and budget that
may be needed.

66 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

Time (schedule)
In project management, completing a project faster usually means it will be more
expensive. This is because extra resources, such as more workers, will be needed to
get the work done faster. This is also why it is very important that the project manager
makes an accurate estimate of the amount of time a project will take. This estimate
will be used to schedule work, hire workers, purchase resources and materials, and
can affect project decisions.

Cost (budget)
Costs affect a project in similar ways to time. Project managers need to be able to
accurately estimate the costs of each phase of a project, as this affects the project’s
budget. When making a project budget, they take into account resource costs,
materials needed, human resources (workers) needed, equipment costs, etc. If an
unexpected expense pops up, the project manager may need to reorganise the budget
or propose changes to the time and scope to account for it.

Knowledge Activity: Imagine that you are working on a software design

project and a client suddenly asks for a whole bunch of new features to be
incorporated into the product. How will this affect the time and cost?

Workbook 2 67
 Section 2: Understand the importance of communication and
project management in coding

What is meant by an Agile development

Please read the following as it will help you to answer question 37.

Agile software development is an umbrella term that describes a set of frameworks

and practices that focus on how the people doing the work – the coders and software
developers – work together. It focuses on the idea of iterative development, where
requirements and solutions evolve through collaboration between self-organising cross-
functional teams.
Self-organising doesn’t mean that there aren’t managers. It means that teams have
the ability to figure out how they are going to approach things on their own. Cross-
functional refers to the fact that teams do not focus on specific roles, but on having the
right skill sets needed for the project.
When teams and organisations work using Agile development, they focus on the
practices that help with collaboration and organising the work, as well as specific
technical practices that directly deal with developing software.
Agile methods or Agile processes encourage adaptation, teamwork, self-organisation
and accountability, as well as engineering best practices that allow for rapid delivery of
high-quality software, and a business approach that aligns development with customer
needs and company goals.
Agile development also refers to any development process that is aligned with the
concepts of the Agile Manifesto. This is a document that was developed by leading
figures in the software industry and reflects their experience of what approaches do
and do not work for software development.
The key concepts set out in the Agile Manifesto are:
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
7. Working software is the primary measure of progress.

68 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

8. Agile processes promote sustainable development. The sponsors, developers,

and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity – the art of maximising the amount of work not done – is essential.
11. The best architectures, requirements and designs emerge from self-organising
teams.
12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behaviour accordingly.

Did you know? – History of Agile development

Starting in the mid-nineties, there were various people working in software
development who realised that the way organisations had been building
software wasn’t working.
These software developers started mixing old and new ideas, and they came up
with a method that emphasised close collaboration between the development
team and business stakeholders; frequent delivery of business value; tight, self-
organising teams; and smart ways to craft, confirm and deliver code.
The people who created those methodologies also came up with ways to spread
the ideas to other organisations and contexts. They developed frameworks
to help with this, such as Scrum, Extreme Programming, Feature-Driven
Development (FDD), and Dynamic Systems Development Method (DSDM). Each
of these described a different part of the Agile process.
In 2001, a group of leading figures in the software industry got together at a ski
resort in Utah to discuss the ways that their different approaches to software
development were similar and where they were different.
They didn’t agree on everything, but what they did agree on eventually became
the Manifesto for Agile Software Development. The Agile Manifesto provided
a set of value statements that formed the foundation for Agile software
development and coined the term Agile software development.
The Agile Alliance was officially formed in late 2001 as a place for people who
are developing software to explore and share ideas and experiences. More
teams and organisations started to adopt Agile.
In some ways, the first sentence of the Agile Manifesto encapsulates the whole
idea: “We are uncovering better ways of developing software by doing it and
helping others do it.”

Workbook 2 69
 Section 2: Understand the importance of communication and
project management in coding

The key characteristics of an Agile development

Please read the following as it will help you to answer question 38.

In addition to the concepts set out in the Agile Manifesto, Agile development includes
the following key characteristics:
• Scrum – this is an approach to Agile software development methodology. The Scrum
approach focuses on empirical feedback, team self-management and the ability to
build ‘tested’ products within short timeframes.
• Quality and value – in Agile development, testing is integrated throughout the entire
product lifecycle. This allows the product owner to make necessary adjustments and
gives the product team early warning of any quality issues. For this reason, product
features are the central unit of planning, tracking and delivery. The product team
measures the number of functional and tested features with each release.
• Ongoing rolling wave planning – Agile methods dictate that most project planning
is ongoing throughout the entire project, rather than having all planning take place at
the start. This method of preparation is referred to as rolling wave planning (or just-in-
time planning), and it includes delaying product decisions until the team is in the best
position to make them.
At the start of the project, the product team does just enough planning to start the
first stage (each stage is called a ‘sprint’). As the project proceeds, the team can make
more informed decisions as more knowledge becomes available.
• Relative estimation – instead of setting out the exact amount of time each stage, or
sprint, will take at the start of a project, many Agile development projects use relative
estimation. For example, instead of saying each stage will take 3 days, they may say
that it will take 1 to 5 days, or that it will not exceed 40 hours.
This prevents teams from wasting time debating an exact estimation. Product teams
improve and refine their estimates as the project progresses.
• Features begin at high-level – rather than spending an extended period of time
setting out the requirements of features before development, Agile development
projects often prioritise and estimate features, and refine the details as they go.
The features for each stage become more detailed as more input is gathered from
customers, testers and developers.
• Continuous testing – this approach to testing reduces the risk of failure late in
a project. By practising continuous testing, product teams can avoid the risk that
problems won’t be noticed until the end of the project – when they are harder and
more expensive to fix.
• Continuous improvement – in Agile software development, product teams
continuously refine both the system and the project. That way, when problems come
up during the project, it is easier to find new ways to adapt the process to fix them.

70 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

• Client visibility and transparency – Agile development encourages the user or

client to take an active part during the development phase of the product. However,
this also requires clients to understand that they are seeing a work in progress in
exchange for this added benefit of transparency.

The advantages and disadvantages of an Agile development

Please read the following as it will help you to answer question 39.

Agile development has several advantages, but it is not appropriate for all projects.
Here are some of the advantages and disadvantages of Agile development.

Advantages

Flexibility and adaptability

Agile development allows changes to take place relatively quickly and easily. This
makes an Agile approach especially useful where it is very difficult, or even impossible,
to completely define the requirements and design for the project before it begins.

Creativity and innovation

Too much central planning and control can stifle creativity and innovation.
Because the Agile approach allows planning to adapt to changing circumstances, it
emphasises creativity and innovation.

Reduced time-to-market
An Agile approach often results in faster development, because it has a shorter start-
up time. The incremental approach used in product development also allows at least
part of the product (e.g. the Beta version) to be delivered early.

Higher productivity of the project team

Agile development reduces the chance that the project specs will grow unnecessarily –
often referred to a ‘project creep’ or ‘mission creep’. This is because Agile development
prioritises requirements.

Workbook 2 71
 Section 2: Understand the importance of communication and
project management in coding

Improved quality
In an Agile project, each team is responsible for the quality of each stage or sprint. The
developers know that quality is not ‘someone else’s responsibility’. The result can be
higher quality overall.

Customer satisfaction
Because the customer is involved in providing feedback throughout the entire
development process, an Agile approach tends to result in higher customer satisfaction
and more effective solutions.

Employee satisfaction
An Agile approach also often results in higher employee satisfaction because
employees are much more engaged in taking responsibility for their own work as part
of an empowered team.

Greater organisational synergy

An Agile approach helps break down organisational barriers and aids in developing a
spirit of trust and partnership.

Disadvantages

Large amount of training and skill is required

An Agile approach requires a considerable amount of training and skill to implement
successfully. Many project teams don’t fully understand the need for this training and
skill or don’t want to put the effort into it. An Agile approach is not effective unless
teams have been adequately trained in how to apply it.

Organisational transformation
Agile development usually requires an amount of organisational change or
transformation in order to be successful. This can be expensive and can take a great
deal of time.

72 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

Scalability
It can be difficult to scale an Agile approach to apply to large, complex projects.

Integration with project/program management

Some projects require a high degree of predictability that can be better achieved by
using a more plan-driven approach, such as the Waterfall method.

Knowledge Activity: Research what types of projects Agile development

works best with.

What is meant by Scrum

Please read the following as it will help you to answer question 40.

The Scrum process is a widely-used framework for Agile development. It uses

development cycles called sprints. A sprint is a short, time-limited (or ‘time-boxed’)
period when a Scrum team works to complete a set amount of work. Sprints break
down big, complex projects into bite-sized pieces.
The Scrum process involves three basic concepts: Roles, Artefacts and Time-boxes.

Workbook 2 73
 Section 2: Understand the importance of communication and
project management in coding

Time-boxing

Time-boxing is used for sprints, but also for other aspects of Scrum development. In
time-boxing, each activity is given a fixed, maximum period of time for completion. This
keeps teams focused on accomplishing the task at hand, by providing a clear definition
of what needs to be done and when. It also encourages teams to start getting work
done immediately. All of the main activities, or ‘events’, in Scrum are time-boxed.

Artefacts

In Scrum, the term ‘artefact’ refers to key information needed during the development
of a product. The main Scrum artefacts are: product backlog, sprint backlog and
increments.
A product backlog is a prioritised list of work for the development team. The most
important items are shown at the top of the product backlog, so the team knows what
to deliver first. The development team pulls work from the product backlog as there
is capacity for it. The backlog is often given in the form of user stories – these are
informal, general explanations of software features written in non-technical language
and from the perspective of the end user. Their purpose is to explain how a software
feature will provide value to the customer.
The sprint backlog is a list of tasks that the Scrum team has identified as needing to
be completed during a particular Scrum sprint. During each sprint planning meeting,
the team selects one or more product backlog items, usually in the form of user
stories, and identifies the tasks necessary to complete each user story. It can be
thought of as the work that will be conducted in each sprint.
An increment is the sum of all the product backlog items completed during a sprint,
and during all previous sprints. It can be thought of as the state of the project at a
particular point in time.
Examples: User stories
User stories are often very short. They might look like these:
As a database administrator, I want to automatically merge datasets from different
sources so that I can create reports more easily for my internal customers.
As a brand manager, I want to get alerts whenever a reseller advertises our products
below agreed-upon prices so that I can quickly take action to protect our brand.
As the leader of a remote team, I want our team messaging app to include file sharing
and annotation so that my team can collaborate in real time and keep an archive of
their work in a single place.

74 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

Scrum roles

Scrum roles describe the key responsibilities for the people on a scrum team. They
aren’t job titles, because any team member, no matter what their job title is, can
perform one of the roles. Instead, the roles are a basic definition of the responsibilities
of each team member. This allows teams to take responsibility themselves for how
they organise and work. The three roles are: Scrum Master, Product owner, Team.
These will be discussed in more detail next.

The role of Product Owner, Scrum Master and Scrum Team

Please read the following as it will help you to answer question 41.

The three Scrum roles are: Scrum Master, Product Owner, and Team (which is made
up of all the Team members). The people who fulfil these roles work together closely to
ensure the smooth flow of information and work, and the quick resolution of any issues
that come up.

Scrum Master

The Scrum Master (also written as ‘scrum master’) is responsible for making sure
that processes run smoothly, removes obstacles to productivity, and organises and
facilitates meetings. The Scrum Master does not assign tasks to Team members, as
this is a Team responsibility.
The Scrum Master can also be thought of as a support role – their job is not to lead
the team, but to help the team to work better. The Scrum Master encourages and
facilitates the team’s decision-making and problem-solving, so that they can work more
efficiently and with less need for supervision.
In practical terms, the Scrum Master needs to be someone who understands Scrum
well enough to train and mentor the other roles, and to assist everyone who is involved
in the project. The Scrum Master should have a constant awareness of the status of
the project and be flexible enough to identify and deal with any issues that come up.

Workbook 2 75
 Section 2: Understand the importance of communication and
project management in coding

Product Owner

The Product Owner is the keeper of the project requirements. In practice, this means
that the Product Owner acts as a liaison between the business, the customers and the
Team, similar to a project manager. The Product Owner is the single point of contact for
all questions about product requirements.
The Product Owner’s main responsibilities are:
• Managing the Scrum backlog – the Product Owner is not the only one putting new
tasks into the backlog, but they are responsible for managing the backlog. That
means the Product Owner should know about everything that is in the backlog and
should communicate regularly with anyone else who adds items to the product
backlog.
• Release management – Scrum Teams can deliver product at any time in a sprint. It’s
the Product Owner’s responsibility to keep track of products and review customer
usage and feedback to determine when products and updates can and should be
released.
• Stakeholder management – any product will have many stakeholders involved. These
include users, customers, the company CEO, etc. The product owner works with all
these people to ensure that the development team is delivering value.

Scrum team

The Team is made up of all the people who do the hands-on work of developing and
testing the product. Team members decide how to break work into tasks, and how to
allocate tasks during each sprint. Team sizes are usually between five and nine people.
(A larger number make communication difficult, while a smaller number leads to low
productivity.) The term ‘Scrum Team’ refers to the Team plus the Scrum Master and
Product Owner.

76 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

Knowledge Activity: How do the Scrum Master, Product Owner and Team
each contribute to making sure a project is completed?

Describe different Scrum events

Please read the following as it will help you to answer question 42.

A sprint is a short, time-boxed period when a Scrum team works to complete a backlog
item. The sprint is itself made up of several different events – these are the steps
involved in completing each sprint.

Sprint planning

The sprint begins with the sprint planning event, which lays out the work to be
performed for that sprint. The plan is created collaboratively by the entire team but
may be managed or overseen by the Product Owner.
Each product backlog item that will be worked on during the sprint may be broken
down into smaller increments that each take a day or less to complete. Sprint planning
itself is often time-boxed to a maximum of eight hours for a one-month sprint. For
shorter sprints, the planning event is usually shorter.

Workbook 2 77
 Section 2: Understand the importance of communication and
project management in coding

Sprint planning addresses the following topics:

• Why is this sprint valuable?
• What needs to be achieved during this sprint?
• How will the work get done?

Daily scrum

The purpose of the daily scrum is to inspect progress toward the sprint goal and adapt
the sprint backlog as necessary, adjusting the upcoming planned work.
The daily scrum is a 15-minute meeting for the scrum team. It is generally held at the
same time and place every working day of the sprint. The Product Owner and/or Scrum
Master may also participate.
The daily scrum focuses on making progress toward the sprint goal and producing
an actionable plan for the next day of work. The goal of the daily scrum is to improve
communications, identify impediments, promote quick decision-making and eliminate
the need for other meetings.

Sprint review

The purpose of the sprint review is to inspect the outcome of the sprint and determine
if any adaptations are needed in the future. During the review, the scrum team
presents the results of their work to key stakeholders and discusses progress toward
the product goal.
During this event, the Scrum team and stakeholders review what was accomplished
in the sprint, what has changed and what should be done next. This may result in
adjusting the product backlog.
The sprint review is generally time-boxed to a maximum of four hours for a one-month
sprint.

78 © LCG 2021
 Section 2: Understand the importance of communication and
project management in coding

Sprint retrospective

This takes place once a sprint has been completed. The goal of the sprint retrospective
is to plan ways for increasing quality and effectiveness.
The Scrum team discusses what went well during the sprint, what problems it
encountered, and how those problems were (or were not) solved. The team also
identifies changes that may be most useful in improving effectiveness. The most
impactful improvements are addressed as soon as possible. These may be added to
the sprint backlog for the next sprint.
The sprint retrospective concludes the sprint. It is time-boxed to a maximum of three
hours for a one-month sprint.

Workbook 2 79
 Section 2: Understand the importance of communication and
project management in coding

Summary

In this section you have learned about:

• the importance of communication
• different methods of communication and when to use them
• different methods for active listening
• different ways of presenting verbal information
• how release notes are used to communicate information
• ways of seeking feedback and the purpose of using feedback to develop
communication skills
• how to recognise productive feedback vs unproductive feedback
• the principles of project management and the role of the project manager
• the principles of Lean and Waterfall project management styles
• how the ‘triple constraint’ affects project management
• the key parts, and advantages and disadvantages, of Agile development
• what is meant by Scrum, and Scrum events, and the different roles of the people
involved in Scrum projects

80 © LCG 2021
 Section 3: Extension activities

Further your knowledge and understanding of the topics in this workbook by completing
the following extension activities.

Extension Activity 1: Research and compare code that is DRY or that uses the
KISS principle and code that is WET. How are they different? Which do you think
is easier to understand and why?

81 © LCG 2021
Section 3: Extension activities

Extension Activity 2: Create a chart below or on a separate piece of paper to

illustrate the DevOps process.

Workbook 2 82
 Section 3: Extension activities

Extension Activity 3: Imagine that you need to communicate a complicated or

technical idea to a group of 10 year olds. How would you do it? What methods
would you use?

83 © LCG 2021
Section 3: Extension activities

Extension Activity 4: Create a flowchart below or on a separate piece of paper,

illustrating the steps used in Agile development.

Workbook 2 84
 DEFENSIVE PROGRAMMING

Disclaimer Copyright 2021

Every effort has been made to ensure that the information All rights reserved. All material contained within this manual,
contained within this learning material is accurate and including (without limitation): text; logos; icons; and all other
reflects current best practice. All information provided should artwork is copyright material of Learning Curve Group (LCG),
be used as guidance only, and adapted to reflect local unless otherwise stated. No part of this publication may
practices and individual working environment protocols. be reproduced, stored in a retrieval system, or transmitted
in any form or by any means (electronic, mechanical,
All legislation is correct at the time of printing, but is liable to
photocopying, recording or otherwise), without the prior
change (please ensure when referencing legislation that you
permission of the copyright owners.
are working from the most recent edition/amendment).
If you have any queries, feedback or need further
Neither Learning Curve Group (LCG); nor their authors,
information, please contact:
publishers or distributors accept any responsibility for any
loss, damage or injury (whether direct, indirect, incidental or Learning Curve Group
consequential) howsoever arising in connection with the use 1-10 Dunelm Rise
of the information in this learning material. Durham Gate
Spennymoor, DL16 6FS
NCFE is a trading name of NCFE (registered company number
[email protected]
02896700) and NCFE; Council for Awards in Care, Health
www.learningcurvegroup.co.uk
and Education; and NNEB are registered trademarks owned
by NCFE. NCFE has exercised reasonable care and skill
in endorsing this resource, and makes no representation,
express or implied, with regard to the continued accuracy of
the information contained in this resource. NCFE does not
accept any legal responsibility or liability for any errors or
omissions from the resource or the consequences thereof.

This resource has been endorsed by national

Awarding Organisation, NCFE. This means that
NCFE has reviewed it and agreed that it meets
the necessary endorsement criteria.

LCG-UC November 2021

Version 1 (603/5854/3) PC1B.4.23