Agile way of working

Agile and its origins

Before we dive into the origins of Agile methodology it is important to first understand the word “agility”. As defined by the Cambridge dictionary the word “agility” represents the ability to move your body quickly and easily.

However, “agility” as a word representing the Agile Methodology can be better defined through the words of Dr. David F. Rico in Broad Introduction: Agile Methodologies :

• The ability to create and respond to change in order to profit in a turbulent global business environment
• The ability to quickly reprioritize the use of resources when requirements, technology, and knowledge shift
• A very fast response to sudden market changes and emerging threats by intensive customer interaction
• Use of evolutionary, incremental, and iterative delivery to converge on an optimal customer solution
• Maximizing BUSINESS VALUE with right-sized, just enough, and just-in-time processes and documentation

The origins of agile methods date back to the 90s when primarily in the software development industry and other industries such as aerospace, defence and manufacturing, the traditional methods were simply not suitable anymore when it came to timely product delivery (Agilemania, 2021). Companies and the developers within quickly started developing their own methodologies and mixing old with new. The new methods had a big focus on close collaboration, business value and self-organised teams. In this time methods such as Scrum, Extreme Programming, Feature Driven Development (FDD and Dynamic System Development Method (DSDM) were established and implemented AgileAlliance. .

The making of the Agile Manifesto

The frustration with traditional methods continued to increase, especially in the software industry. One of the first to speak up on this topic was Jon Kern, who in 2000 organised a meeting in Oregon with 17 other software developers in order to look for new ways of bringing software products faster to the market. The meeting concluded with two outcomes :

• To solve the product-market fit and unfinished product problem- shortening the delay of benefits to customers.
• To ensure the usefulness of the new software and improve it- gathering feedback from customers.

The second meeting with the same group took place in Utah in 2001, where the birth of the Agile Manifesto took place. The Agile Manifesto consists of the four mentioned values :

• Individuals and interactions over processes and tools,
• Working software over comprehensive documentation,
• Customer collaboration over contract negotiation,
• Responding to change over following a plan,

and of 12 main principles :

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 for the shorter timescale.
4. Businesspeople 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.
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 maximizing the amount of work not done--is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

Since 2001 and the forming of the Agile Alliance by the software developers, agile has spread beyond the software industry and is nowadays a popular choice of management, whether that be organisational, team, project, program or portfolio management.

Agile WOW (way of working)

Introduction

When transitioning into an agile business it is important to consider volatility and uncertainty levels. Therefore, based on that the agile approaches within a business will differ. The key part of the transition is to be open towards the change . With change such as the incorporation of agile methodologies also comes the transition of organisational and working methods, or so-called Agile WOW .

Organisational practises

Some of the key organisational practises that should be considered in an agile environment are :

• Teamwork → The team works as an integrated individual entity, where collective ownership of the project is taken.
• Respect for people, self-organisation, and empowerment → The team works together to establish the course of the project and the division of workload. The team works as one when carrying the responsibility and when facing failure.
• Transparency and trust → Risks and issues are commonly shared with the business user, and he/she/they are involved in the process of recognising and resolving them.

Incorporating these methods also means that the right people with the right mindset have to be selected. People with the following characteristics such as collaborative, committed, focused, open, courageous, and honest are more prone to adapt well to the agile WOW .

Agile project management

In traditional project management, the Project Manager plays a key role when making decisions and delegating the tasks. However, in agile project management, the roles are not strictly defined, and the role and the tasks of the project manager are not solely performed by one individual. A lot of tasks that would normally be the responsibility of the project manager, are the responsibility of the team .

Team responsibilities:

• Most of the time the decisions are collectively made by the team.
• The team plans the schedule based on a consensus-driven approach.
• Reporting and tracking progress is normally deformalized and part of the team´s flow.
• The team self-manages and the key team members are signed on the project full time until the project is concluded in order to lessen the resource planning.
• If the team is using Scrum as their framework, the project manager will normally take on the role of the Scrum Master.

Three things should always be considered when wanting to effectively incorporate an agile project management approach :

1. Correct mindset → A system thinking approach should be undertaken when facing an agile project. This means that the focus should be on the big picture and not on smaller technicalities.
2. Customer value → The project should enable the possibility to increase customer value
3. Adaptation → Through the course of the project, the methodologies should be adapted to better fit the project itself and the problem. Meaning that the project should not be force-fitted into a specific methodology

Overall, it is very hard to define how an agile project should be managed and what exactly will the project manager's role be, as it differs based on the project, framework, methods, etc. However, there are principles that can easily be incorporated, specifically in a hybrid agile approach to strengthen and improve project agility.

Principles to help the Project Manager (PM) establish their role in an agile project :

• Rolling Wave Planning

Here the project manager can take the initiative to execute a brief upfront planning to avoid delays in later stages where the upfront planning is normally done collectively by the team. The project manager should use a risk-and-value based approach to acquire the appropriate level of upfront planning needed and its conclusions should be presented to and approved by the sponsors and stakeholders.

• Customer Collaboration

Here the PM should take the initiative to adapt the methodology to maximize the inclusion of the customer in the project.

• Collective Ownership

It is important that the PM takes on a role of a facilitator, instead of an authoritative figure. Ownership should be collective within the team. Therefore, the PM should encourage strong teamwork and individual empowerment.

• Validation over verification

This means that the final product should fit the customer's needs, rather than meeting all the documentation requirements. The PM should take care that this is achieved and help the team by removing bureaucratic barriers.

• Fail early and fail often

With each iteration adjustments and improvements should be made in order to reach the final goal. The PM should consult the team and work on successfully implementing the necessary changes.

• Daily stand-up meetings

The PM should lead and schedule the daily stand-up meeting, which should be quick and highly focused. They are called stand-up meetings because it is recommended to do them while standing up to ensure a proactive and timely meeting.

• Timeboxing

Incorporating timeboxing means that meetings or sets of events are executed in a fixed time, and if more time is required a new meeting or event is scheduled. This is a great method to use to increase productivity in a set time and to avoid unnecessary costs due to prolonging the meeting or the event in question.

All these principles can easily be incorporated into any project, whether that might be agile or traditional. However, the goal is that they provide a more agile oriented management with a customer-focused product.

Frameworks

In agile WOW there are different frameworks that can be used in order to make product development and teamwork more agile. Meaning that the team is able to work flexibly with optimized performance. Based on the given project, program or portfolio different frameworks or a combination of two might be chosen. The frameworks act as a guideline that can be adapted from project to project.

Scrum

Scrum is the most popular model in agile management, and it is heavily oriented around iteration management. The scrum model consists of predefined events and roles. The predefined events are time-boxed. This means that a set time is used on an event and if more time is required a new event will be scheduled instead of extending the time on the current one. The events are sprint, sprint planning, daily scrum, sprint review and sprint retrospective. The roles are the scrum master, the product owner, and the team .

The goal of the project is achieved through multiple sprints, each lasting approximately a month. One sprint consists of the above-mentioned events. The sprint is initiated through sprint planning, where the product backlog is filled with tasks arranged based on the level of importance. Throughout the whole duration of the sprint daily scrum is executed. The daily scrum is a meeting within the team that is never longer than 15min. This reduces the complexity and ensures that everyone is on board and fully informed about the state and changes of the product. If relevant the scrum master and the product owner also participate in the meeting. At the end of the sprint, there is a sprint review, where the team and the stakeholder gather for an evaluation of the sprint and to note down possible changes and adaptations to the product. The last stage of the sprint is the sprint retrospective, where the team analyses the sprint in terms of people, tools, processes, and interactions (Scrum.org, 2022).

In terms of the roles, the Scrum Master is in charge of maintaining and having an overview of the processes. He/She acts as a facilitator towards the team. Meaning that he/she makes sure to remove the teams’ obstacles, external interferences during the project work and interferes when conflicts arise. The Scrum Master is also the bridge between the team and stakeholders in terms of communication and has an active role in supporting the Product Owner .

The Product Owner acts as a representative for the stakeholders and the company. The Product owner is, therefore, in charge of the product backlog and its profitability. This means that he/she sets the product requirements, which are normally based on a customer-centric approach, and sorts them based on the importance. After each iteration, the Product Owner must readjust and re-evaluate the set requirements/tasks. The Product Owner, therefore, plays a key role in the sprint planning stage .

The Team normally consists of approximately seven people, and they are the main responsible when it comes to tasks such as design, analysis, testing, etc. Their role is to select the sprint goals from the backlog and to define the goals and wanted results for the sprint. They are a self-organized team and have the responsibility of keeping track that the goal is being reached within the set time .

Scrum can easily be incorporated into projects of all shapes and sizes as long as they are agile. Projects that are based on other methods will have a difficult time incorporating Scrum and executing it efficiently. It is also not suitable to use when the work is highly individual.

Kanban

Kanban when directly translated means signboard or billboard. It is easy to implement and can act as a good, simplified replacement or support to Scrum. It has a big advantage of low cost and the ability to be used by individuals or a team to manage everything from workload to full scale projects. To describe Kanban words of Rob Cole can be used: “Kanban is the concept that all work starts life as to-do and ends up as done” .

Kanban consists of three guiding principles :

• Start with what you do now.
• Agree to pursue incremental, evolutionary change.
• Respect the current process, roles, responsibilities, and titles.

The first thing that is needed when beginning the Kanban implementation is a Kanban board. The board consists of three columns: to do, in-process and done. These three columns represent the workload and the flow of it from the beginning to the end. The to-do area acts as a backlog, therefore, it is important that the tasks can contribute to the business value. Kanban backlog is very similar to other agile work stacks (fx. Scrum), however, it does have some of its own specifications. For example, in Kanban it is preferred that the tasks are of a similar size, meaning that larger tasks should be broken down into smaller more manageable pieces. The backlog in Kanban is also reviewed more often, sometimes even on daily basis. And lastly, the tasks are taken for the backlog only when the resources allow to do so .

A very important part of the Kanban framework is also the WiP limit (Work in Progress limit). This limit is set per employee and ensures that not too many tasks get stuck in the “in-process” stage not being complete. Most often the limit per employee is 3 tasks. Another aspect of this framework is also getting tasks from “in process” into “done”, where defining the criteria for complete tasks is of key importance .

Agile VS Waterfall

Agile

Benefits:

+ Faster development, high productivity and motivation

+ High level of flexibility

+ Learning outcomes provided throughout the process

+ Customer focused approach

+ Teams manage projects

+ Communication is more efficient

Limits:

- Difficult to implement

- Requires a lot of organisational changes, if the company´s work culture is not already agile

- Not suitable for all projects

- High uncertainty and low control in projects

Waterfall

Benefits:

+ Control and predictability over cost and schedule

+ Lower dependency on skilled resources

+ Consistent within many businesses’ environments

+ Higher efficiency for low uncertainty products

+ The scope is defined at the beginning

+ Defined team roles

Limits:

- Control and predictability over cost and schedule

- Lower dependency on skilled resources

- Consistent within many businesses’ environments

- Higher efficiency for low uncertainty products

- Limited involvement of the customer