What’s So Great About Agile? A Primer on Agile Management Systems
Agile Management Systems have been around for a while, but have gained currency in recent times. 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 is 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 over from a traditional system to Agile, and they might bemoan the constant meetings and “meetings about meetings.”
Turns out 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 does mean meetings and deliverables more often than with traditional systems, it also means that there is a lesser chance of iterations and changes later on in the project cycle.
It’s being touted as the cure-all for common problems that plague IT-related projects. What exactly is it and how is it better than traditional systems?
Let’s find out.
Need for Agile Management practices
Anyone who has worked on 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 methodologies in Project Management had many drawbacks due to which they failed to cope with the ever-changing business environment, especially in software development, and the above situations were, unfortunately, 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 marketplace
Need for flexibility to accommodate multiple changes in specifications
Flaws in the ‘division of labour’ scenario
Dilemma of the customer
Need for reduction in cost
Need for speed to reach the product to marketplace:
We are living 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, traditional project management approach fails to deliver. A sequential project is necessarily dependent on the steps being completed satisfactorily in order. Timelines in traditionally managed projects are always a bone of contention.
Organisations and teams who 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, projects in IT were failing often because the traditional project management system was built to “plough on”. If there were any changes, clients often felt the pinch to their wallets or timelines. The traditional project management model, adapted from other industries, simply wasn’t working for a dynamic industry such as IT.
Division of labour:
In the traditional model, there are distinct phases, starting with systems requirements analysis and leading up to product release and maintenance. This results in division of labour and labelling of the members as ‘designers’, ‘programmers’ or ‘testers’. But in reality, today’s resources are extremely cross-functional and such clear-cut distinction of roles is not feasible in most projects.
Dilemma of the customer:
In volatile projects, very often, clients are not entirely sure what their final product, with all the specifications, must be. Functionalities and requirements often change as pieces of the work are done. Traditional models such as the Waterfall model emphasize clarity with respect to the final product, and deviations in plans place a 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 requirement any time after the project started were discouraged. Rather, the costs to any additional component were high, sometimes prohibitively so. It was therefore imperative to include all possible scenarios in the planning stage itself. This meant that all scenarios were considered and a solution proposed. But since it’s nearly impossible to know for certain which part of the product the user will prefer, teams often developed “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.
Needless to say, this meant that all projects were global in their planning.
And when an entirely new unplanned scenario emerged, there was extra cost anyway, in spite of 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 actually worked for the client and the developer. What resulted was the “Agile Manifesto” 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 a set of guiding concepts behind the Agile Manifesto that support project teams in implementing Agile Projects. They are:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcoming changing requirements, even in the late development stage. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with preference to the shorter time scale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity — the art of maximizing the amount of work not done — is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
Example of a Project Needing Agile Management
Imagine a start-up which develops a mobile app for a client. Freezing on 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 then 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 project management helps overcome these problems. Under this system, the app is developed in stages, with client interaction every day and deliverables or project milestones identified, say, for every week.
Multiple teams may also work on the same app, so that the development time is reduced drastically.
Functionalities are refined with each meeting and the end product is reflective of the final need. They learn step by step what works for the customer and improvise the offerings till 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 Agile Management is mostly referred to as an IT concept, its uses are not limited to 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. The company avoided the costs relating to high inventory and unpredictable discount offerings by this method.
Some of the key aspects of Agile Project Management are:
Agile Project Management follows a flexible approach.
Agile Management welcomes additions and changes throughout the product development instead of conforming it 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 product that is more dynamic and 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 testing. Since there is regular overview of task efficiency, the team members adjust behaviour and procedures accordingly.
The profile of the project manager in an Agile project will change from a traditional role.
He/she is no longer spending a lot of time planning or monitoring resources, but now spends more time in collaborating with teams, and ensuring that the overall picture is always in sight. This is not an easy transition, and managers moving over 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 predates Agile, and was proposed for the first time in 1986, and implemented in the automotive and printer industries.
Scrum and Agile are not synonymous; there are other frameworks that can be used to implement Agile but Scrum is one of the most effective and probably the most popular. Typically, Scrum has only three roles: Product owner, Team and Scrum master. The Scrum master is not a project manager. The responsibilities of a traditional project manager role are split up among the three Scrum roles. The project is built into a series of fixed-length iterations called sprints. The success of each sprint brings about a feeling of tangible progress and continuous inspiration. The goal of each iteration is to produce a working product which can be demonstrated to the stakeholders. The Scrum master works with the product owner and team to facilitate the completion of goals by removing roadblocks. The development team is cross-functional and includes testers, designers and ops engineers in addition to developers.
Traditional Project Management: The Waterfall
One of the most prominent traditional Project Management Systems is the Waterfall. It was frequently used since the 1970s.There are several well-known and widely implemented waterfall methodologies in IT projects. These include PRINCE2 which was created by the UK Government 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 completed, the developers move on to the next step. The project plan should be fool proof; once a stage in the sequence is completed, the developers cannot revisit the same without starting all over again. It is a static approach to Project Management. There is no room for changes or error and the project plan must be diligently followed.
An analogy can be drawn 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 what he visualised, he cannot modify it easily.
Agile or Waterfall?
Agile is more suited to small teams working on incremental and evolutionary projects whereas Waterfall is suited for large schemes or development projects. Waterfall management might be better suited to industries such as the construction industry. Agile is used in more dynamic projects such as those of 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 is structured in a more traditional way, is a linear one, and is perhaps easier to understand for non-developers and those new to software development.
Many organisations find Waterfall methodology comforting since it is better documented. Agile is known for not emphasizing extensive documentation. It is more people-dependent, which can be discomforting in organizations where the attrition rate is high.
Smaller straightforward projects may not require an Agile framework and a sequential Waterfall model may work just as well.
Where Is This All Going?
Agile development methods 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 organisations (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. This approach has been described by Erick Bergmann and Andy Hamilton. 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 Development is here to stay. It has allowed for flexibility, time and cost advantages, along with the most important factor of all: giving a sense of satisfaction and a motivating atmosphere to the people who work on these projects.
Source:
For Agile Manifesto and The 12 Agile Principles- www.agilemanifesto.org
The post What’s So Great About Agile? appeared first on eduCBA.