Download Beginner's Guide to Agile Project Management
This handbook is meant to be a quick starter guide to Agile Project Management. It is meant for the following people:
Someone who is looking for a quick overview of what Agile is and why it is awesome.
Someone who needs help getting their head around Agile project management.
Someone who is scared to introduce Agile on their next project.
Someone who needs help selling Agile to their boss or client.
This guide is not meant to be the end-all-be-all to agile. Far from it. It is meant to give busy people an overview of the framework and its benefits in 15 minutes or less.
An Agile overview:
Agile is a way to manage projects. It can be used for virtually anything, but it was founded in software development. This handbook focuses on agile for software development, but many of the principles can be expanded to other fields.
Agile breaks down larger projects into small, manageable chunks called iterations. At the end of each iteration (which generally takes place over a consistent time interval), something of value is produced. The product produced during each iteration should be able to be put into the world to gain feedback from users or stakeholders.
Unlike Waterfall project management, which is strictly sequenced: you don’t start design until research is done and you don’t start development until the designs are signed off on; agile have designers, developers and businesspeople working together simultaneously.
The purpose of this guide is to suggest the benefits and advantages of Agile Project Management (APM) adopted in business. The Agile Project Development is now common in software development because it is more accurate and practical within a limited timeline and requirements.
This guide draws upon primary and secondary sources including Agile Software Development, Project Management, and APM. The results of this guide can be concluded that APM is beneficial for an organization or company, team developer, and product.
Agile Project Management Roles:
It takes a cooperative team of employees to complete a project. Agile project teams are made up of many people which are :
Development team: The group of people who do the work of creating a product. The development team includes programmers, testers, designers, writers, and anyone else who has a hands-on role in product development.
Product owner: A person who is responsible for bridging the gap between the customer, business stakeholders, and the development team called the product owner, or sometimes, a customer representative. The product owner is an expert on the product and the customer’s needs and priorities. The product owner works with the development team daily to help clarify requirements based on the customer’s need.
Scrum master: A scrum master or a project facilitator is an important person who is responsible for supporting the development team, clearing organizational roadblocks, and keeping the agile process consistent.
Stakeholders: Stakeholders provide input and are affected by the project’s outcome. They are not ultimately responsible for the product. The group of stakeholders can include people from different departments or even different companies.
Agile mentor: Agile mentor is an expert who has experience implementing agile projects and can share that experience with a project team. This role is a good supporter who can provide valuable feedback and advice to new project teams and to project teams that want to perform and succeed at a higher level.
By the end of this fast-paced video, you'll practically be a scrum master. You'll know about burndown charts, team roles, product backlogs, sprints, daily scrums and more. You'll also be ready to start implementing Scrum in your own team.
Lecture briefly explains What is Agile? and What is Agile Project Management? As per agile definition, it is a process and methodology by wh...
Lecture briefly explains What is Agile? and What is Agile Project Management? As per agile definition, it is a process and methodology by which projects can be managed and implemented in small chunks of work.
Agile software development is an approach to software development under which requirements and solutions evolve through the collaborative effort of self-organizing and cross-functional teams and their customer/end user.
Content: 1.The Art of Project Management 2. Traditional Project Management Methodologies 3. Agile Project Management Methodology 4. Agile F...
4.2 Kanban: comprehensive solution to handling work in progress
4.3 Lean: eliminating waste in software engineering
5. Agile Software Engineering Best Practices: Extreme Programming
Agile project management focuses on continuous improvement, scope flexibility, team input, and delivering essential quality products. Agile project management approaches include scrum as a framework, extreme programming (XP) for building in quality up front, and lean thinking to eliminate waste. Download also:
The Principles behind the Agile Manifesto commonly referred to as the 12 Agile Principles are a set of guiding concepts that support project teams in implementing agile projects. Use these principles as a litmus test to determine whether or not you’re being agile in your project work and thinking:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. 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 a preference to the shorter timescale. 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 behavior accordingly.
During my career in the past years, I have been in many circumstances where we have to adapt to the new challenges due to the huge changes occurred in the business environment and technology, there should be a more competitive approach to manage our daily project activities in a way where we can absorb all these fluctuations and ambiguity in the business requirements, and here comes the magic of Agility, where the working environment is becoming more adaptable, flexible and enjoyable for all stakeholders whether it’s a customer or a team.
I have a passion for Agile and its mindset, and I’m sure its applicable at any type of work or industry, because Agile isn’t limited with specific methods, it’s a wide broad concept where we can live literally with it, Having an Agile mindset doesn’t mean that it will overcome all that you have learnt, Agile is Agile which means that you should have this flexibility of thinking about what is the best approach for your project, whether it’s a traditional Waterfall or Agile or a Hybrid one, this is the art of tailoring and adapting your knowledge to be the most appropriate for your project.
I will go through the Agile concept, how and when it was born, is it a new mindset or a methodology, what are the challenges working on an Agile way, what are the characteristics of the Agile organizational structure and the Agile project manager, and is it easy to have the mindset, is it something you can aquire so this is where I begin this series of articles, as an Agile guru and practitioner I would like to put some highlight on this concept and mindset and how our working daily life will be better when we live this concept, stay tuned.. Thanks
An Introduction to Agile Project Management Copyright image to invensislearning.com
OVER THE PAST 10 TO 15 YEARS, there has been a rapid and dramatic adoption of agile methodologies:
1-Project Management Institute (PMI)® studies concluded that from 2008 to 2013, the use of agile practices tripled
2-According to a 2013 survey conducted by VersionOne:
88% of the respondents say that their organizations are practicing agile development, up from 84% in 2012 and 80% in 2011.
Over half of the respondents (52%) are using agile software to manage the majority of their projects.
88% say that they are at least “knowledgeable” about agile software development techniques, up 7% from the previous year.
3-This trend has been going on for some time. As early as 2007, a Forrester survey reported
“26% are already using agile and an additional 42% are aware.”
“Adoption of agile increased 56% from 17% in 2006, to 26% in 2007.”
“Awareness increased 45% from 29% in 2006, to 42% in 2007.”
These statistics indicate that agile is not a fad, it is having a significant impact on the way projects are managed, and it’s definitely here to stay. This trend has a significant impact on the career direction of project managers who have come from a traditional, plan-driven project management background since there is no formal role for a project manager at the team level in an agile project.
The Chams In Project Management Philosophies
In spite of this rapid and sustained proliferation of agile, there is still a fairly large chasm between the agile and traditional project management communities:
There has been only a limited amount of progress on developing a more integrated approach to project management that embraces both agile and traditional plan-driven project management principles and practices.
Many people seem to see agile and project management principles and practices as competitive approaches that are in conflict with each other, and they are essentially treated as two separate and independent domains of knowledge.
Considerable polarization between these two communities is based in some part on myths, stereotypes, and misconceptions about what agile and project management is.
A major goal of this Article and other some is to help project managers understand the impact of agile on the project management profession and to broaden and expand their project management skills as needed to develop a more integrated approach to adapt to this new environment.
A lot of the polarization that exists between the agile and traditional project management communities is rooted in some well-established stereotypes of what a project manager is that are based on how typical projects have been managed in the past. The role of a project manager has been so strongly associated with someone who plans and manages projects using traditional, plan-driven project management approaches that many people can’t conceive of any other image of a project manager. It’s time to develop a new vision of what an agile project manager is that goes beyond all of those traditional stereotypes and fully integrates agile within the overall portfolio of project management principles and practices.
It feels very similar to an evolution that took place when I worked in the quality management profession in the early 1990s. Up until that time, the primary emphasis in quality management had been on quality control, and inspection and the image of a quality manager were heavily based on that role:
The predominant quality management approach was based on final inspection of products prior to shipping them to the customer and rejecting any that didn’t meet quality standards. It’s easy to see how that approach was inefficient, because it resulted in a lot of unnecessary rework to correct problems after the fact, and it also wasn’t that effective because any inspection approach is based on sampling, and it is impractical to do a 100% sample. For that reason, it can result in mediocre quality.
A far better approach was to go upstream in the process and eliminate defects at the source by designing the process to be inherently more reliable and free of defects and build quality into the inherent design of the products. That didn’t mean that the prior emphasis on quality control and inspection was obsolete and eliminated; it was just not the only way to manage quality and wasn’t the most effective approach in all situations.
That was a gut-wrenching change for many in the quality management profession—instead of being in control of quality and being the gatekeeper with the inspection process, a good quality manager needed to become more of a coach and a consultant to influence others to build quality into the way they did their work. This changed the nature of the work dramatically for many in the quality management profession and eliminated a number of traditional quality management roles that were based on the old quality control and inspection approach. The similarity to the changes going on in the project management profession should be apparent:
To be successful in more uncertain environments, project managers need to be able to take an adaptive approach that is appropriate to the level of uncertainty in the project and integrate quality into the process rather than relying on final acceptance testing at the end of the project to validate the product that is being produced.
They also need to give up some of the control that has become associated with the project management profession—in some cases, they may need to become more of a coach and a consultant to influence others rather than being in absolute control of a project.
This can dramatically change the role of a project manager. In some situations, the role of a project manager as we’ve known it may no longer exist. For example, at a team level in an agile project, you probably won’t find anyone with a title of project manager because the project management functions have been absorbed into other roles and are done very differently. That doesn’t mean that project management is no longer important, but it may cause us to dramatically rethink what project management is in a much broader context than the way we might have thought about it in the past.
The Evaluation of Agile and Waterfall
You will often hear people make a comparison between agile and waterfall. Many of those discussions are polarized and position them as competitive approaches. Here’s an example:
According to the 2012 CHAOS report, Agile succeeds three times more often than Waterfall. Because the use of Agile methodologies helps companies work more efficiently and deliver winning results, Agile adoption is constantly increasing.
While that statement is generally true, it’s an oversimplification. There are at least two problems with that kind of statement:
It makes it sound like there are only two binary, mutually exclusive choices, agile and waterfall.
The meaning of the words agile and waterfall are typically not well-defined and are used very loosely.
For those reasons, I prefer to avoid comparing agile to waterfall because it tends to be a very polarized discussion—I prefer to take a more objective approach that is based on a comparison between a plan-driven and an adaptive approach to project management. So let’s first define both agile and waterfall, and then compare the two approaches.
Definition of waterfall
The word waterfall actually has a very specific meaning, but that’s often not how the word is really used: The waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Imagine a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it cannot turn back. It is the same with waterfall development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back.
Another aspect to the waterfall model is that it is plan-driven; it attempts to define and document detailed requirements and a plan for the entire project prior to starting the project. When someone makes a statement comparing waterfall to agile, the word waterfall is often used very loosely to refer to any kind of plan-driven methodology, and that’s not really a very accurate and meaningful comparison. In some other comparisons like this, the word waterfall refers to a general style of project management that obsessively emphasizes predictability and control over agility, and that’s just bad project management.
Definition of agile
The meaning of the word agile in this kind of comparison is also somewhat elusive because it has taken on some very strong connotations in actual usage. At a project level, at least in the United States, the word agile has taken on a specific connotation associated with using the Scrum methodology on software development projects: Scrum is an agile software development model based on multiple small teams working in an intensive and interdependent manner. The term is named for the scrum (or scrimmage) formation in rugby, which is used to restart the game after an event that causes play to stop, such as an infringement. Scrum employs real-time decision-making processes based on actual events and information.
Comparison of plan-driven and adaptive approaches
Traditional, plan-driven project management is a style of project management that is applied to projects where the requirements and plan for completing the project can be defined to some extent prior to implementing the project. However, plan-driven is a relative term, and you won’t find many projects that start out with an absolutely rigid plan that is not expected to change at all.
In contrast, an adaptive style of project management starts the implementation of a project with a less well-defined plan of how the project will be implemented and recognizes that the requirements and plan for the project are expected to evolve as the project progresses. Adaptive is also a relative term; you won’t find many projects that have no plan whatsoever of how the project will be done.
The important point is that the terms plan-driven and adaptive: are relative—they are not discrete, binary, mutually exclusive alternatives. They should imply a continuous range of approaches with different levels of upfront planning.
Saying “Agile is better than waterfall,” is like saying, “A car is better than a boat.” Agile and waterfall are different kinds of methodologies designed for different kinds of projects. The problem is not so much that waterfall or agile are inherently good or bad; the problem comes about when those methodologies are misused and people try to use a single methodology (whatever it might be) for all projects. Using a “one size fits all” strategy to applying either waterfall (plan-driven) or agile (adaptive) approaches to all projects is not likely to yield optimum results.
In my opinion, being able to objectively understand the difference between a plan-driven approach and a more adaptive approach—as well as the principles behind those approaches at a deeper level—is probably one of the most important skills an agile project manager needs to have.
An agile project manager needs to recognize the following:
There is a broad range of alternative approaches between being plan-driven and being adaptive. The agile project manager must choose the right level of upfront planning to be applied to a project, based on the level of uncertainty and other factors in the project.
It takes some skill to make the right choice. There is nothing inherently wrong with either of those approaches (adaptive or plan-driven). The problem comes about when people try to force-fit a project into one of these approaches rather than selecting and tailoring the approach to fit the project. For example, if I were to set out to try to find a cure for cancer and I attempted to apply a highly plan-driven approach to that project, the results would probably be dismal.
The important point is that a heavily plan-driven approach (what some loosely refer to as waterfall) is not the only way to successfully manage a project. In many projects, a good approach is to use an adaptive approach to start the design effort without fully-defined and detailed requirements and perhaps prototype something quickly. Then user feedback can be added to further refine the design as the project progresses. With a more adaptive approach:
The elements of the approach are much more concurrent than sequential. Instead of doing the entire design and then turning it over to quality assurance (QA) for testing, the design is done in small chunks called iterations or sprints that are typically two to four weeks long. During that time, developers and testers work collaboratively to design and test the software during each sprint.
The customer also provides detailed inputs on the design during each sprint. The customer accepts the results of each sprint at the end of each two- to four-week period rather than waiting for user acceptance testing (UAT) at the end of the project. That has the advantage of finding and resolving any problems quickly and early in the project.
One primary advantage of a more adaptive approach is that the project startup is accelerated because less time is spent upfront in attempting to define detailed requirements. In addition, engaging the user more directly in the design process is more likely to produce an outcome that provides the necessary business value and really meets the user needs.
An adaptive approach maximizes the business value to the customer because the customer is directly engaged with the design team as the project progresses, but it is worse for predictability and control because the customer can make changes as the project progresses. In an agile project, change is the norm rather than the exception. However, this is not an “all-or-nothing” proposition to have total control or no control at all. There are many ways to achieve the right balance of control versus agility. For example, prior to the start of a project, the high-level requirements might be defined and stabilized, and then only the more detailed requirements need to be further elaborated as the project progresses.
The Evaluation of the Project Management Profession
Many of the techniques associated with project management that are in use today haven’t changed significantly since the 1950s and 1960s. I believe that we are on the verge of a major transformation of the project management profession that will cause us to redefine project management in a much broader context that includes both agile and traditional, plan-driven project management.
Agile Project Management Benefits
I am a strong believer in agile, and there are some very significant benefits of an agile approach in many situations. However, many proponents of agile oversell the benefits and sometimes position agile as a panacea that should be used for all projects. The real benefit to a typical project manager of developing an agile project management approach is not in throwing away any notion of using a plan-driven approach, converting to agile, and using a totally agile approach for all projects. Rather, the benefit results from recognizing that a traditional, plan-driven approach is not the best way to manage all projects and thus learning to blend adaptive/agile and plan-driven principles and practices in the right proportions to fit a given situation.
Here are five specific benefits of developing an agile project management approach:
Increased focus on business outcomes. Many people think that the primary benefit of an agile project is just getting it done faster, but that is not always the case. The primary emphasis in an agile project is really to deliver value in the form of very successful business outcomes by taking an adaptive approach to maximize the value that is delivered. That doesn’t always result in the fastest delivery times. In some cases, it may require some experimentation and trial-and-error prototyping to find an optimum solution—that may or may not be the quickest way to get it done, but it should result in a better product in the end.
Reduced time to market. Time to market is, of course, an important consideration, and agile accomplishes that in a couple of ways
Higher productivity and lower costs. Agile can also result in higher productivity and lower costs by eliminating unnecessary overhead and bottlenecks and doing work concurrently rather than sequentially.
Higher quality. A very important benefit of agile is higher quality. In a traditional waterfall project, quality is sequential and is often perceived as a separate effort that is the responsibility of the quality assurance (QA) department. The developers many times develop the software and then “toss it over the wall” to be tested by QA. In an agile project, the team, as a whole (which includes QA testers) jointly owns responsibility for building quality into the design of the products that they produce—it’s not someone else’s responsibility. The development effort is broken up into short iterations called sprints that are typically two to four weeks in length. There is an emphasis on producing a shippable product at the end of every sprint, which means that quality testing must be more integrated with development and cannot be put off indefinitely.
Organizational effectiveness. Finally, a very important benefit of agile is a more effective organization with higher morale
Agile project management focuses on continuous improvement, scope flexibility, team input, and delivering essential quality products. Agile project management approaches include scrum as a framework, extreme programming (XP) for building in quality up front, and lean thinking to eliminate waste.
Follow Us
Were this world an endless plain, and by sailing eastward we could for ever reach new distances