1- What is traditional software development? How is agile different from this?

Answer in
500 words
or above.
Traditional software development is a sequential development that flows steadily downwards
through several phases, often used to design and develop simple software with minor
security and functionality required. There are based on pre-organized phases/stages of the
SDLC: Analysis – Design – Implement – Coding & Testing – Maintenance.
- Traditional SDLC used predictive approach while agile used adaptative approach
- In term of the communication between the company and customers Traditional SDLC
used formal communication while agile communication is informal
- Traditional SDLC are often used for less complex project while Agile are for very
complex one.

2- Is Scrum Master the decision maker regarding the work to be done in the next sprint?
Elaborate on your answer.

In an agile team specially on agile Scrum method, there are three main entities which are the
development team, the Scrum master and the product owner. Even though agile team
interact with many actors, those three poles constitute its core. For instance, we should focus
on the scrum master activities and check if he is the decision maker regarding work to be
done.
The Scrum master's objective is to facilitate the organization of the team. His role is to
ensure that the team is not hindered by obstacles by applying the principles and practices of
the Scrum method. He ensures that the cooperation between team members is fluid, so that
it’s functional and productive. He oversees coordinating ceremonies and overseeing
workshops. His overall role is to make sure that operations are carried out in the most
positive atmosphere possible.
He does not give injunctions or instructions to the team, he only proposes. The Scrum
master, like the product owner, is not a hierarchical manager therefore making decision on
work to be done is not part of his qualification.

3- Mention the challenges involved in developing Agile software

Even though Agile software is the most recommended in the field, it doesn’t come without some
challenges among which:
- Lack of understanding or misunderstanding of agility
Most people do not understand what it means to be Agile.
Many companies want to be Agile, but don't invest the time, money or effort to really educate
management or employees.
Too often, Agile is adopted as a solution... or worser more as a development team "Things" among an
entire organization to "test" the method.
For any cultural, organizational or process change, the lack of investment in understanding the
change and its effects inevitably leads to failure.
- Minimizing documentation in agile development
Since development starts quickly, product requirements are clarified just in time for development.
The documentation of an agile product is, generally speaking, less elaborate and detailed.
When new team members join the team, they do not know the details of some features and how
they should work.
This can lead to difficulties and a longer adaptation time.
- The complexity of adopting an agile culture
Not all corporate cultures are "ready" for the drastic changes that Agile culture requires.
Trust, flexibility and uncertainty are variables that can be incompatible with the values of a company.
And yet these are the elements that make agile methodologies successful.
- The lack of predictability of the Agile approach
As quickly stated, the agile philosophy does not allow a company to rely on 12 or 24 month
roadmaps.
The Agile culture is based on the idea that teams will not know what their end result will look like.
This makes it difficult to predict the cost, time and resources needed to start a project.
This problem becomes more pronounced as projects become larger and more complex.
- The difficulty of implementation for complex projects and large-scale companies

4- Explain in detail the process and workflow of the following agile frameworks and how
companies are benefitted out of this
a. Agile Scrum methodology
Scrum is a framework in which people can solve complex adaptive problems, while
productively and creatively delivering the highest value products possible.
By using Scrum, the development team easily breaks down their product into tasks.
They become more agile and discover how to react quickly and respond to the unexpected.
Scrum uses artifacts and ceremonies or rituals to achieve the desired results
b. Kandan
Like Scrum, Kanban encourages work to be broken down into smaller tasks.
But rather than scheduling work into an iteration or Sprint, team members retrieve the
highest priority task from the backlog that is ready to be developed.
Kanban is a work method inspired by the Lean approach focused on the continuous
improvement of production processes. It was conceptualized in 1950 by Japanese industrial
engineer Taiichi Ōno for Toyota in order to optimize the car manufacturer's manufacturing. It
is based on a "pull" system, taking into account consumer demands, rather than push.

The creation of a kanban board for a given project involves several steps:

Identify the succession of tasks to be performed that can be modeled as collaborative

flows,
Map each phase of the process,
Identify the phases that require a large volume of resources or depend on numerous
sub-tasks,
Name the steps/columns of the table according to the business workflow.
The definition of the table columns or lists depends on the business process. For
example, a content publication workflow could be broken down into "Proposed topics",
"Validated topics", "Drafting in progress", "Completed articles", "Reviewed articles" and
"Published articles" columns. Obviously, the stages will be different for an IT project, which
could be broken down into "To be developed", "Under development", "Completed
development", "Testing phase", "Acceptance phase", "Deployment".
c. Extreme programming (XP)
 The extreme Programming kwon as XP methodology is a project management
method that applies the principles of agile development to the extreme, i.e. focusing on
customer needs, implementing iterative development and continuous integration. The project
team and its relationship with the customer are at the heart of XP.
The principles of the XP method are not new since they are the same as those of
Agile methods. The difference and the originality lie in the fact that they are pushed to the
extreme.
That agile method is based on:
- a strong reactivity to the change of the customer's needs.
- teamwork.
- the quality of the work provided.
- the quality of the tests carried out as soon as possible.

XP is based on five fundamental values which are:

o Communication: it is essential that each member of the team communicates daily with his
or her colleagues as well as with the customer. This is an essential way to solve
problems.
o Simplicity: the simplest way to achieve results is preferred. The project team does what is
necessary and requested, nothing more. A simple application will be easier to evolve
later.
o Feedback: the feedback between the project team and the customer is essential. Each
step of the project is sent as quickly and often as possible to the customer so that he can
test, give his opinion and validate the step. Each modification request is taken into
account immediately.
o Respect: respect for each team member and their work is paramount. The management,
the project team and the client respect each other.
o Courage: It takes courage to make certain changes, such as trying a new technique,
restarting an iteration that has not been validated, or reviewing the project organization.
Courage allows you to get out of an unsuitable situation.
XP workflow is based on rapid development cycles (iterations of a few weeks) whose stages
are as follows:
- an exploration phase determines the customer scenarios that will be delivered during this
iteration.
- the team transforms the scenarios into tasks to be performed and into functional tests.
- Each developer is assigned tasks and carries them out with a partner.
- When all the functional tests are passed, the product is delivered.
The cycle repeats as long as the client can provide scenarios for delivery. The first delivery is
generally more important and is only realized after a few iterations. After the first release, the
iterations can become shorter (one week for example).

5-

a. Critically evaluate the approach the agile project team takes in managing
stakeholders and communicating with them.
In Agile development, stakeholders are represented by a wide range of people with an
interest in the outcome of the project. These include
- Project sponsors - the people who fund the project,
- Product owners - often the key stakeholders on the customer side,
- Project managers,
-Business managers and enterprise architects,
-account and sales managers,
-development team including engineers, designers, business analysts
- end-users.
So managing stakeholders and communicating with them will be essentials so we need to:
- Indentify
To identify our project’s stakeholders, we should start with listing every individual and group
who is impacted by our project’s outcome and has an interest in its success.
- Analyze
State the needs and objectives of your stakeholders and identify what brings business value
to each.
- And prioritize (the matrix of influence).
Create a stakeholder map to select those with the most interest and influence.
Stakeholder management is essentially the art of knowing how to communicate with
stakeholders in an attractive way, this include communicating plan and engage them
effectively:
- Plan communication
Creating a stakeholder map will help us to distinguish between people who simply need to be
informed about the progress of the project and active participants in the meeting. Set up a
meeting plan, appoint channels and determine the frequency of communication for each
person and group.
- Engage effectively.
The development team can involve key stakeholders by encouraging them to actively
participate in meetings, such as sprint reviews or retrospectives, and by appreciating their
feedback.

b. What mistakes project manager can do and how are these mistakes be avoided?
Involving stakeholders into sprint reviews makes it easier to check if everything is
going in the right direction, meaning, to meet the business goals of the project. But there are
some challenges
- Access to information and tools - some stakeholders lack time and prefer to check on the
progress of the project themselves, while others prefer to be informed of all issues through
face-to-face conversations. A combination of face-to-face meetings and asynchronous
means of communication may be the solution, but each stakeholder should be consulted on
the means to be used.
- Cultural barriers - these are the differences between the culture of the organization and the
culture of the society, which influence communication, values and tolerance of change.
These differences need to be taken into account and open communication maintained.
- Language barriers - there may be barriers to understanding the specific terminology used
by specialists. You need to be respectful of the fact that not everything will be understood in
the same way by everyone.
- Boundaries between different departments - in some companies, the different departments
are divided between them by strong boundaries, which makes communication with internal
stakeholders difficult. -According to the BizDevOps approach, to ensure a frictionless
knowledge flow, you need to get rid of these hubs. Make sure that the communication flow
between stakeholders in different departments of your organisation is smooth to ensure that
you have all the necessary data to make informed decisions.
To sum up all those misunderstanding communication barriers, open and honest
communication which recognises and respects differences is the solution to these barriers.

Question 6:
a. What is software estimation and why it is important during software project
management?

b. How can a project manager improve their estimation accuracy? What options are
available to them?