Agile Methodology Useful in Project Management

Updated April 13, 2023

What’s So Great About Agile? A Primer on Agile Methodology

Agile Management Systems have been around for a while but have recently gained currency. In fact, Agile Management consistently features on the Top Project Management Trends of nearly every IT Project Management blog every year.

The applications of Agile in IT-based projects are undisputed, as it finds use not just in IT software projects but also in product development and innovation.

So what’s so great about Agile? Ask employees who have moved from a traditional system to Agile, who might bemoan the constant meetings and “meetings about meetings.”

There’s a lot more to Agile than just meetings and feedback. It focuses on empowering teams and removing sequential ways of project development so that there is more flexibility and innovation. While that means meetings and deliverables more often than with traditional systems, it also means there is a lesser chance of iterations and changes later on in the project cycle.

It’s touted as the cure-all for common problems plaguing IT-related projects. What exactly is it, and how is it better than traditional systems?

Need for Agile Methodology – Management practices

Anyone who has worked on agile methodology in software development projects will have some idea of some of the usual problems that come up during a project: change in scope, deadlines that seem impossible to meet, and overworked resources.

Traditional agile methodologies in Project Management had many drawbacks. Unfortunately, they failed to cope with the ever-changing business environment, especially in software development, and the above situations were all too common. This is not to say that traditional methods are not applicable anywhere. They are still the best bet for projects in which the idea is fully formed from the start.

Agile Management practices became the need of the hour because they satisfied the following needs of a product launched in a dynamic environment:

• Need for speed to reach the product to the marketplace
• Need for flexibility to accommodate multiple changes in specifications
• Flaws in the ‘division of labor’ scenario
• Dilemma of the customer
• Need for reduction in cost

Need for speed to reach the product to marketplace:

We live in a fast-paced environment where flexibility and speed are key to success.

Technology is one of the fastest-changing sectors in the industry. There is a newer idea, product, or innovation every minute. In this backdrop, the traditional project management approach fails to deliver. A sequential project is necessarily dependent on the agile methodology steps being completed satisfactorily in order. Timelines in traditionally managed projects are always a bone of contention.

Organizations and teams that are not dynamic will lose the race to those who morph themselves to suit the changing environment.

Need for flexibility to accommodate multiple changes in specifications:

Client expectations and requirements often change over the course of product development. Before Agile Management Systems were mainstream, IT projects often failed because the traditional project management system was built to “plough on”. Clients often felt the pinch to their wallets or timelines if there were any changes. The traditional project management model, adapted from other industries, simply wasn’t working for a dynamic industry such as IT.

Division of labour:

The traditional model has distinct phases, from systems requirements analysis to product release and maintenance. This results in the division of labor and labeling the members as ‘designers’, ‘programmers’, or ‘testers’. But in reality, today’s resources are extremely cross-functional, and such a clear-cut distinction of roles is not feasible in most projects.

Dilemma of the customer:

In volatile projects, clients are often not entirely sure what their final product, with all the specifications, must be. Functionalities and requirements often change as pieces of the work get complete. Traditional models, such as the Waterfall model, emphasize clarity with respect to the final product, and deviations in plans place huge stress on the system. This brings us to the last factor that led to the development of Agile systems.

Need for reduction in cost:

Traditionally, changes in requirements any time after the project started were discouraged. Rather, the costs of any additional component were high, sometimes prohibitively. Therefore, it was imperative to include all possible scenarios in the planning stage. This meant that all scenarios were considered and a solution proposed. But since it’s nearly impossible to know which part of the product the user will prefer, teams often develop “bloated versions” of a product. This contained all possible scenarios, of which a typical user would use not more than 20%. This resulted in unnecessary cost and development.

This meant that all projects were global in their planning.

And there is extra cost anyway when an entirely new unplanned scenario emerges, despite all the planning.

A group of people met in February 2001 to discuss exactly this: the need for a flexible and agile model of software development that helped develop products that worked for the client and the developer. What resulted was the “Agile Manifesto,” which was the benefits of agile methodology software development, i.e., a set of four principles that are as simple as they are descriptive. Twelve “Agile principles” explaining how Agile systems would actually work in a project environment were also developed.

Through this work, we have come to value:

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

That is, while there is value in the items on the right, we value the items on the left more.

The 12 Agile Principles

The 12 Agile Principles are guiding concepts behind the Agile Manifesto that support project teams in implementing Agile Projects. They are:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcoming changing requirements, even in the late development stage. Agile methodology 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 a shorter time scale.
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 do the job.
6. A face-to-face conversation is the most efficient and effective method of conveying information to and within a development team.
7. Working software is the primary measure of progress.
8. Agile methodology 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. The team regularly reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Example of a Project Needing Agile Management

Imagine a start-up that develops a mobile app for a client. Freezing the entire application design before development starts might be disastrous. There is also limited time to conduct the market survey, chalk out a detailed plan, decide on the variants they want to offer, and develop the product. Besides the huge cost involved in this approach, they run the risk that some other company might develop the app before they do.

Agile methodology in project management helps overcome these problems. Under this system, the app develops in stages, with client interaction every day and deliverables or project milestones identified for every week. Multiple teams may also work on the same app, reducing the development time drastically.

Functionalities are refined with each meeting, and the end product is reflective of the final need. They learn what works for the customer and improvise the offerings until they get the desired product. In the traditional approach to project management, one would think of all the revisions before releasing the product. This would result in missed deadlines, increased workloads, and cost inflation. Moreover, the product might have completely lost its relevance by the time of release.

How exactly does Agile Management work?

Though one mostly refers to Agile Management as an IT concept, its uses go beyond the IT industry. For example, chain apparel retailer Zara used the principles of Agile Management to transform its business.

Using Agile principles, Zara manufactured products in small batches rather than focusing on large production prior to the new season. This method avoided the costs relating to high inventory and unpredictable discount offerings.

Some of the key aspects of Agile Project Management are:

• Agile Project Management follows a flexible approach.

Further, Agile Management welcomes additions and changes throughout product development instead of conforming to original specifications.

• Agile projects are usually divided into separate chunks of work, with teams involved in developing one or more of these “chunks” of work.

So it is possible to have, for instance, four teams working simultaneously on different parts of a project so that project timelines are shortened. Teams coordinate with each other and with the client on a daily basis for deliverables.

• There are daily meetings about the progress or roadblocks in the project with constant feedback.

After receiving customer feedback, the changes are incorporated, and the teams move on to the next chunk. This process continues to deliver a more dynamic product better suited to the client’s needs.

• There is greater involvement of the team members rather than a top-down approach.

Within the Software Development Life Cycle, team members are involved in all the stages: requirement, design, development, and agile methodology testing. Since there is a regular overview of task efficiency, the team members adjust behavior and procedures accordingly.

• The profile of the project manager in an Agile project will change from a traditional role.

He/she no longer spends a lot of time planning or monitoring resources but now spends more time collaborating with teams and ensuring that the overall picture is always in sight. This is not an easy transition, and managers moving to Agile systems must adapt quickly for the project to succeed.

A few words about Scrum:

Scrum is one of the most popular frameworks for implementing the Agile Methodology. It predated Agile and was proposed for the first time in 1986 and implemented in the automotive and printer industries.

Agile methodology and scrum are not synonymous; there are other frameworks that can serve in implementing Agile, but Scrum is one of the most effective and popular ones. Typically, Scrum has only three roles: Product owner, Team, and Scrum master. The Scrum methodology master is not a project manager. The responsibilities of a traditional project manager role are split up among the three Scrum project management roles. The project is built into a series of fixed-length iterations called sprints. The success of each agile methodology sprint brings about a feeling of tangible progress and continuous inspiration. Each iteration aims to produce a working product that one can demonstrate to the stakeholders.

The agile methodology scrum master works with the product owner and team to facilitate the completion of goals by removing roadblocks. The agile methodology development team is cross-functional and includes testers, designers, ops engineers, and developers.

Traditional Project Management: The Waterfall

One of the most prominent traditional Project Management Systems is the Waterfall. It has been frequently in use since the 1970s. There are several well-known and widely implemented waterfall methodologies in IT projects. These include PRINCE2 which the UK Government created for its public sector.

Much like its name suggests, it is a sequential workflow. The end product is fixed at the beginning of the project. Then the various stages of the workflow are completed in sequence (conception initiation, analysis, design, construction, testing, implementation, and maintenance). Once the previous step is complete, the developers move on to the next step. The project plan should be foolproof; once a stage in the sequence is complete, the developers cannot revisit the same without starting all over again. It is a static approach to agile methodology in Project Management. There is no room for change or error, and the agile methodology project plan must be diligently followed.

One can draw an analogy between Waterfall Management and painting a masterpiece. The image of the final masterpiece is already in the artist’s mind, and he steadily works towards it. If, for any reason, the end product is different from the visualized one, he cannot modify it easily.

Agile or Waterfall?

• Agile suits small teams working on incremental and evolutionary projects, whereas Waterfall suits large schemes or development projects. Waterfall management might be better suitable for industries such as the construction industry. Agile has usage in more dynamic projects, such as the IT industry.
• Agile systems demand highly skilled team members who can handle all phases of the project. It requires a dramatic shift in the role of a project manager. The waterfall process has a more traditional and linear structure and is perhaps easier to understand for non-developers and those new to software development.
• Many organizations find Waterfall methodology comforting since it has better documentation. Agile is popular for not emphasizing extensive documentation. It is more people-dependent, which can be discomforting in organizations with high attrition rates.
• Smaller straightforward projects may not require an Agile methodology framework, and a sequential Waterfall model may work just as well.

Where is this all going?

Agile development methodology account for more than two-thirds of all IT projects in the U.S., according to a survey by HP in May 2015.

But Agile is not always the ‘perfect’ solution. It is not a ‘one-fits-all’ solution, and as a result, many organizations (24%, according to the HP survey) have now adopted a hybrid approach.

A hybrid of Agile and Waterfall methods could tap the advantages of both. This hybrid approach could work for complicated projects with external clients and large teams. Erick Bergmann and Andy Hamilton have described this approach. It is a compromise between the two methods, allowing software teams to work ‘agile’ while hardware development teams and product managers use the traditional method.

Mark Fromson, a digital consultant, points out another way in which a hybrid can work:

Breaking up the project into waterfall-like phases to allow for fixed-bid contracting and defined scope within a smaller phase, but keeping the project fluid as a whole.

Regardless of the form future teams will take, it is clear that Agile methodology Development is here to stay. It has allowed for flexibility, time and cost advantages, along with the most important factor: giving a sense of satisfaction and a motivating atmosphere to the people working on these projects.

Source:

For Agile Manifesto and The 12 Agile Principles- www.agilemanifesto.org