Agile way of working

Revision as of 18:27, 20 February 2022

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 (Dictionary, 2022) 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 (Rico, 2022):

• 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, 2022).

The making of the Agile Manifesto:

The frustration with traditional methods continued to increase, especially in the software industry. One of the first so 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 (Agilemania, 2021):

• 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 (Highsmith, Agile Manifesto, 2001):

• 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 (Highsmith, Agile Manifesto, 2001):

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. 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 now days a popular choice of management, whether that be organisational, team, project, program or portfolio management.

Agile WOW (way of working)

Intro

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 (Charles G. Cobb, 2011). With change such as the incorporation of agile methodologies also comes the transition of organisational and working methods, or so-called Agile WOW (Ganesan, 2022).

Organisational practises

Some of the key organisational practises that should be considered in an agile environment are (Charles G. Cobb, 2011):

• 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 (Rob Cole, 2015).

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. Some of these tasks that would normally be the responsibility of the project manager, but are the responsibility of the team are (Charles G. Cobb, 2011):

• 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.

To effectively incorporate an agile project management approach a correct mindset must be developed first. 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. Secondly, the project should enable the possibility to increase customer value. And lastly, 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 (Charles G. Cobb, 2011).

Overall, it is very hard to define how an agile project should be managed and what exactly will the project managers 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.

The first principle is 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. The second principle is Customer Collaboration, where the methodology should be adapted to maximize the inclusion of the customer in the project. Collective Ownership is another principle, where it is important that the project manager takes on a role of a facilitator, instead of an authoritative figure. Ownership should be collective within the team. Therefore, the manager should encourage strong teamwork and individual´s empowerment. Validation over verification should also play a key role in an agile environment, meaning that the final product fits the customer needs, rather than meeting all the documentation requirements. When it comes to failure the agile philosophy is to “fail early and fail often”, meaning that with each iteration adjustment and improvement should be made in order to reach the final goal. Daily stand-up meetings which are quick and focused are highly recommended. They are called stand-up meetings because it is recommended to do them while standing up to ensure a proactive and timely meeting. The last principle is Timeboxing, where meetings or set events are executed in a fixed time, and if more time is required a new meeting or event is set. 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 event in question (Charles G. Cobb, 2011).

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 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 (Scrum.org, 2022).

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 (Charles G. Cobb, 2011).

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 (Charles G. Cobb, 2011).

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 (Charles G. Cobb, 2011).

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” (Rob Cole, 2015).

Kanban consists of three guiding principles (Rob Cole, 2015):

• 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 (Rob Cole, 2015).

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 (Rob Cole, 2015).

Agile VS Waterfall

Agile

+ Faster development, high productivity and motivation

+ High level of flexibility

+ Learning outcomes provided throughout the process

- 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

(Charles G. Cobb, 2011)

Waterfall

+ Control and predictability over cost and schedule

+ Lower dependency on skilled resources

+ Consistent within many businesses’ environments

+ Higher efficiency for low uncertainty products

- Control and predictability over cost and schedule

- Lower dependency on skilled resources

- Consistent within many businesses’ environments

- Higher efficiency for low uncertainty products

(Charles G. Cobb, 2011)

References

AgileAlliance. (2022). Agile 101. Retrieved from Agile Alliance: https://www.agilealliance.org/agile101/

Agilemania. (2021, March 30). The Complete History of Agile Software Development. Retrieved from Agilemania: https://agilemania.com/history-of-agile-software-development/

Charles G. Cobb, P. (2011). Making Sense of Agile Project Management: Balancing Control and Agility. JOHN WILEY & SONS, INC.

Dictionary, C. (2022). Agility. Retrieved from Cambrideg Dictionary: https://dictionary.cambridge.org/dictionary/english/agility

Ganesan, A. (2022). Agile Ways of Working (WoW) - Know your WoW now! Retrieved from Jile: https://www.jile.io/blogs/agile-ways-of-working

Highsmith, J. (2001). Agile Manifesto. Retrieved from Agile Manifesto: https://agilemanifesto.org/

Rico, D. F. (2022). Broad Introduction: Agile Methodologies. Retrieved from Dave´s Lean & Agile Webpage: http://davidfrico.com/rico18l.pdf

Rob Cole, E. S. (2015). Agile project management: A practical guide to using Agile, Scrum and Kanban. Pearson Education.

Scrum.org. (2022). What is Scrum. Retrieved from Scrum.org: https://www.scrum.org/resources/what-is-scrum