Agile way of working

Revision as of 11:51, 20 March 2022

Abstract

This article provides a brief introduction to the history of agile and how the agile manifesto came to be. Furthermore, it dives into the agile WoW, explaining its methods and applications. Within this chapter, the focus is on the organisational practices and the implementation of agile in project management. The section on agile project management provides some key methods and principles that project managers can apply in order to make their projects, programmes or portfolios more agile. As part of the agile WoW different methodologies are mentioned as well. Methodologies such as scrum and kanban are explained in more detail with examples provided. The last chapter revolves around the comparison between the agile and waterfall methods and their limits and benefits. Annotated bibliography is provided at the end.

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 ^[1] 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 ^[2]:

• 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. ^[3].

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 ^[4]:

• 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 ^[5]:

• 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 ^[5]:

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.

Example: A great example of agile used in other industries is the Lonely Planet. They are the largest publisher in the world for travel guide books. In 2012 the legal team decided to implement an agile approach, meaning that they began using whiteboards, task cards, stand up meetings and running the work in sprints ^[6].

Agile WOW (way of working)

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 ^[7]. With change such as the incorporation of agile methodologies also comes the transition of organisational and working methods, or so-called Agile WOW ^[8].

Organisational practises

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

• 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 ^[9].

Example: A great example of good agile organizational practices is that of Dee Dee Trotter. An athlete that won two Olympic gold medals in 2004 and 2008. In the 2012 race, she had slim chances for another gold medal due to a knee injury. However, by being a member of the team USA, she felt responsible to consider the whole team and not just herself. With trust and transparency in mind, she brought the issue forth to the team, and together they made a decision that she will withdraw from the race and a replacement runner will substitute her. The team ended up winning another gold medal ^[10].

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 ^[7].

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 ^[7]:

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 ^[7]:

• 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 ^[11].

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 ^[11].

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 ^[7].

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 ^[7].

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 ^[7].

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.

Example: An example of how Scrum works. Anna, the product owner, meets with the customer to discuss their needs. The needs represent the backlog. Afterwards, Anna chooses the most important tasks, which her team will work on in the first sprint. The team meets daily to discuss the day's target and roadblocks, which the scrum master works on removing. Once the sprint is concluded Anna delivers the work, checks the backlog and selects new tasks for the next sprint. The sprints continue until the project is concluded.

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” ^[9].

Kanban consists of three guiding principles ^[9]:

• 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 ^[9].

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 ^[9].

Due to its easy implementation ability, Kanban can be used in almost any industry and within their projects. However, most often kanban can be seen in the software development industry and within industries where agile and lean principles are already incorporated.

Agile VS Waterfall

What is Waterfall

Before we dive into agile versus waterfall methodology, it is important to understand what waterfall methodology actually is.

The waterfall process consists of sequential phases that are executed in a set order. Once the first phase is finished the project will naturally progress into the second one and so forth. The typical waterfall method will consist of the following sequential phases:

• Requirements
• Design
• Develop
• Integrate & Test
• Implementation / Development

When using the waterfall approach certain assumptions can be made regarding the project process:

• The users will sometimes fully define or even over define the requirements for the product without seeing it until it is a finished product.
• These requirements will stay unchanged throughout the project.
• The requirement will have detailed documentation in order to make them more understandable to developers.

This process is often seen as a way to have a higher overview and control over costs and schedules. However, that is seldom reality, especially if the requirements are uncertain. In that case, the requirement uncertainty could cause low adaptability, which will lower customer satisfaction, or if changes are permitted, this could lead to additional bureaucracy and time delays. ^[7]

However, waterfall methods are recommended especially when the project consists of the following attributes ^[12]:

• Clear and well-defined requirements
• Stable product definition
• High availability of resources
• Short term projects

Exampel: A great example of the usage of the waterfall method is the construction and manufacturing industry, where strict planning and documentation is of key importance. A project within this industry has little to no space for adaptation and changes, which could lead to severe delays and extreme cost increases. On top of that, the project has a set order in which the project has to be executed. For example, when building a house some materials can be pre-ordered, however, before building the walls the foundation has to be laid first ^[13].

Comparisson between Agile & Waterfall

^[7]

Anotated bibliography

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

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

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

References

1. ↑ Dictionary, C. (2022). Agility. Retrieved from Cambridge Dictionary: https://dictionary.cambridge.org/dictionary/english/agility
2. ↑ Rico, D. F. (2022). Broad Introduction: Agile Methodologies. Retrieved from Dave´s Lean & Agile Webpage: http://davidfrico.com/rico18l.pdf
3. ↑ (2022). Agile 101. Retrieved from Agile Alliance: https://www.agilealliance.org/agile101/
4. ↑ Agilemania. (2021, March 30). The Complete History of Agile Software Development. Retrieved from Agilemania: https://agilemania.com/history-of-agile-software-development/
5. ↑ ^{5.0 5.1} Highsmith, J. (2001). Agile Manifesto. Retrieved from Agile Manifesto: https://agilemanifesto.org/
6. ↑ Scott J. (2018). GANTTPRO. Retrieved from GANTTPRO: https://blog.ganttpro.com/en/agile-in-non-software-industries-with-examples//
7. ↑ ^{7.0 7.1 7.2 7.3 7.4 7.5 7.6 7.7 7.8 7.9} Charles G. Cobb, P. (2011). Making Sense of Agile Project Management: Balancing Control and Agility. JOHN WILEY & SONS, INC.
8. ↑ Ganesan, A. (2022). Agile Ways of Working (WoW) - Know your WoW now! Retrieved from Jile: https://www.jile.io/blogs/agile-ways-of-working
9. ↑ ^{9.0 9.1 9.2 9.3 9.4} Rob Cole, E. S. (2015). Agile project management: A practical guide to using Agile, Scrum and Kanban. Pearson Education.
10. ↑ Wilson F. (2022). DZone Retrieved from Jile:https://dzone.com/articles/4-awesome-teamwork-examples-for-agile-teams
11. ↑ ^{11.0 11.1} Scrum.org. (2022). What is Scrum. Retrieved from Scrum.org: https://www.scrum.org/resources/what-is-scrum
12. ↑ Try QA. (2022). What is Waterfall model. Retrieved from TryQA: http://tryqa.com/what-is-waterfall-model-advantages-disadvantages-and-when-to-use-it/#Examples_of_Waterfall_Model
13. ↑ Dillon L. (2022). ClearpointStrategy. Retrieved from ClearpointStrategy: https://www.clearpointstrategy.com/waterfall-project-management/#5