Difference between revisions of "AgilePM-Video-Introduction"

From AgilePM wiki
Jump to: navigation, search
(AgilePM 01: Introduction)
(14 intermediate revisions by the same user not shown)
Line 1: Line 1:
=== AgilePM 02: Adaptive Approach ===
AgilePM Videos
  [[MP-AgilePM-01-Introduction|01 AgilePM Introduction]]  
  [[MP-AgilePM-02-Adaptive Approach|02 AgilePM Adaptive Approach]]  
[[MP-AgilePM-03-Incremental Delivery|03 AgilePM Incremental Delivery]]  
Our normal thinking of how a project works is that we start by listening to the customer to understand their expectations then document this. Next step is to create a plan and then start the project.  This approach is called the predictive approach as we can predict all the requirements upfront. 
[[MP-AgilePM-04-Iterative Development|04 AgilePM Iterative Development]]  
[[MP-AgilePM-05-Quality|05 AgilePM Quality]]  
In certain projects (eg: creative projects) this is not so easy as we cannot understand all the requirements up front. However, we have to be able to support these type of projects, so how do we do this? 
[[MP-AgilePM-06-Collaboration|06-AgilePM Collaboration]]  
[[MP-AgilePM-07-Communication|07 AgilePM Communication]]  
Once way will be try to improve the way we do predictive projects by spending a bit more time at the start of the projects and using such techniques as:
[[MP-AgilePM-08-Business Need|08 AgilePM Business Need]]  
* Facilitation workshops
[[MP-AgilePM-09-Fixed Duration Projects|09 AgilePM Fixed Duration Projects]]  
* Prototyping  (e.g. A 3D model of a house) 
[[MP-AgilePM-10-Control|10 AgilePM Control]]
* Taking time to examine similar products
This will help a little, but it will not support these projects where requirements are difficult to gather in the future.  So another idea is to take another path to development. 
We can start by considering the different approaches we can take to take deliver a product and then start by describing a smaller first deliverable that we can do in a few weeks.  We can then show this to the customer and get their feedback.  This feedback makes it much easier for the customer and development team to communicate and for the customer to have gain a better understanding of their requirements. 
[[File:Adaptive - 1.jpg|300px]]
After this feedback, we can then agree on the next deliverable (next version) with the customer and start work on this. We then show this to the customer again when ready and receive more feedback. We can continue to do this until the end of the project involving the customer when we deliver each deliverable and we reach all the customers’ expectations.  
This approach is known as the adaptive approach as we don’t try to predict all the requirements from the start of the project but we use the feedback from each deliverable so the requirements evolve during the project.  This '''adaptive approach''' is also known as Agile, so now you have a good definition for Agile.
[[File:Adaptive - 2.jpg|300px]]
Remember the main goal of any project is to deliver a product that the customer will find easy to use and will allow them to be more productive.
=== AgilePM 03: Incremental Delivery ===
The method of product delivery is one of the main differences between the adaptive and the predictive approaches.
More specifically, through the adaptive approach multiple versions of the product are created, client feedback being used at each development cycle to customize the product to fit the expectations better and better.
[[File:Incremental - 1.jpg|300px]]
This is called '''Incremental delivery''' and can often be a more practical method of delivery than the Big-Bang delivery method, which is usually used in the predictive approach. The reason for this is that for the latter no actual feedback on the product is received before we release its final version. Therefore, we do not know for sure if the product really fits the expectations of the client until it is too late to change anything without repeating the whole process.
'''Building incrementally, from firm foundations''', is a first principle used in Agile methodologies. It was drawn from the principles of the DSDM framework, one of the many Agile frameworks. Like other frameworks, such as XP or Scrum, DSDM was initially a methodology used by a group of people which was later given a name and made official by publishing a document or a book. Today, the latest version of this methodology is the basis for the Agile exam.
[[File:Incremental - 2.jpg|300px]]
=== AgilePM 04: Iterative Development ===
As established earlier, in adaptive approaches we have development cycles.
[[File:Iterative - 1.jpg|300px]]
During each cycle we need to specify what we need to do, design the part of the solution, then build the code, test it, and finally integrate it with everything else we have created.
[[File:Iterative - 2.jpg|300px]]
This sort of development process is called iterative development. Through this process, the evolving solution develops from a concept to a product which has an acknowledged business value. '''Developing iteratively''' represents one of the key principles of DSDM.
With each cycle, the product is brought closer to finish. The cycles begin and end with a dialogue, as stated by the DSDM principles of continuous and clear collaboration and communication. The initial dialogue focuses on what has to be done and how. Most of the times, this is simply an event of informal planning. After the plan was implemented, the work is reviewed and it is decided whether the result meets the expectations or another cycle is required.
Importantly, the criteria for acceptance for the product need to be kept in clear focus throughout this process in order to ensure that the quality of the product is the expected one.
=== AgilePM 05: Quality ===
How the quality of the product is assessed differs between the Agile and Waterfall methodologies.
For Agile, quality checks take place at each development cycle, during the testing phase.
[[File:Quality - 1.jpg|300px]]
By comparison, for Waterfall methodologies quality checks are carried out near the end of the project. This can often mean that a compromise on quality needs to be made, however, due to time constraints and pressure from stakeholders.
[[File:Quality - 2.jpg|300px]]
The advantage of Agile is clear, as quality issues can be addressed at any point during the development process, allowing us to reach the final result at a desired quality. This level of quality should be agreed upon at the start of the project, and all the work carried out should aim at reaching the desired level of quality. The goal is to '''never compromise quality''', this being one of the DSDM principles.
When the DSDM framework is used, testing is carried out as early as possible. In order to ensure that the testing procedure is appropriate and takes place without unnecessary risks, the teams use MoSCoW prioritization and timeboxing.
=== AgilePM 06: Collaboration ===
Business people are a vital part of any project. However, the way in which they are involved in the process differs between Agile and Waterfall methodologies. More specifically, in Predictive methodologies they are heavily involved at the beginning of the project and in the closing of the process, whereas in Agile methodologies they are involved throughout the project, during each developmental stage.
[[File:Collaboration - 1.jpg|300px]]
Their participation takes place during the Specify and Test phases of each development cycle. This is why, in Agile projects we need to have access to business people throughout the development process.
[[File:Collaboration - 2.jpg|300px]]
This means that, unlike for predictive systems, in Agile projects you cannot afford involving busy business representatives. Their presence is needed in order for the optimum product to be reached.
One thing that should be avoided is the “Us vs. Them” relationship that is found in some companies between stakeholders, business people on the one side and management and technical people on the other. This is detrimental to the ultimate, common goal of reaching the objectives of the project.
[[File:Collaboration - 3.jpg|300px]]
For this reason in Agile it is needed to bring these parties together in active cooperation, creating a one-team culture. This is because with collaboration, the understanding and speed is vastly increased and a sense of shared ownership is created, this allowing the teams to work together much better than if the team members worked individually.
We used a new term above, stakeholders. A stakeholder is any person who has an interest in the project and has the ability to influence it (e.g., customers, suppliers, competitors, etc.). As you can see, in most systems there are three types of stakeholders: business people, management people, and technical people.
Importantly, in DSDM we have a fourth category: process oriented people. These stakeholders are merged with management people in other methodologies.
[[File:Collaboration - 4.jpg|300px]]
Bringing these four categories of stakeholders working closing together is what is called '''collaboration''' in Agile, this representing one of the DSDM principles.
=== AgilePM 07: Communication ===
According to the PMBOK and PRINCE2 standards, a project manager needs to spend about 90% of his time communicating. Indeed, poor communication is often considered to be the biggest cause for project failure.
In Agile projects communication is vital at each phase of each development cycle. This is why DSDM practices were designed to improve the effectiveness of communication both for individuals and teams.
[[File:Communication - 1.jpg|300px]]
In this sense, within the DSDM framework teams informal communication is encouraged at all levels, and daily team sessions are organized in order to ensure efficient communication. The role of the project manager here is to facilitate continuous and clear communication between the team and stakeholders, and within the team – this representing another DSDM principle.
Human interaction is valued and emphasized by DSDM through stand-ups, workshops, but also by defining clear roles for the team members and by ensuring active involvement in the project development.
===AgilePM 08: Business Need ===
Decisions during a project should be made depending on the project goal – delivering what is needed when it is needed. For this, project teams need to ensure that they understand the real priorities, that they establish a business case that is valid, and that they are able to guarantee the delivery of the Minimum Usable SubseT (MUST).
Unfortunately, this does not always happen. As an example, the graph below shows that many times, a large amount of the features of new software are never used. This translates in a waste of many work hours.
[[File:BN - 1.jpg|300px]]
In order to avoid such disastrous situations, particularly when using Agile methodologies, we need a proper prioritization method. One which is characteristic to DSDM is the MoSCoW prioritization. This method is also used in other methodologies, including Waterfall ones – such as PRINCE2.
MoSCoW differentiates between:
* Must have: vital functions, or functions which are needed to comply to regulations
* Should have: not vital functions, but required. Workaround possible.
* Could have: additional functions that bring value to the product but are not required
* Won’t have this time
Often it’s difficult for the customer or business people to differentiate between “must have” and “should have”. For this reason, the “must have” for any product should be determined by the technical and management people after a conversation with the other stakeholders.
In adaptive systems, we need to start by first developing the “must have” items, and then move on to “should have” and, later, “could have” functions. This focus on the business need, a DSDM principle, allows the development of a fully functional product as early as possible, less important features being added as time constraints allow.
[[File:BN - 2.jpg|300px]]
=== AgilePM 09: Fixed Duration Projects ===
In the case of projects developed through traditional approaches, most times the duration of the project is not fixed. What that means is that we are given a fixed set of features that the product needs to have and in case the time does not suffice we can either sacrifice quality or extend the project duration, thus driving up the costs.
[[File:Fixed Duration - 1.jpg|300px]]
This is not always a good solution, however. At times, due to legal deadlines or market opportunities, the late delivery of a product is not a solution. Even when that is not the case, on-time delivery is the most important success element or at least a desirable outcome that shows control over the project.
In IT and software development, project duration is very important. The reason for this is that by extending the project duration we shorten the use time of the product, on the one hand and, on the other, that by extending the project duration we end up implementing many “could have” features that will generally not be used anyway.
For this reason, the DSDM approach uses a fixed project duration, with a fixed cost and fix quality requirements. The only flexible thing is the scope of the project. Depending on what time allows, a variable number of features will be implemented.
[[File:Fixed Duration - 2.jpg|300px]]
Using the MoSCoW prioritization technique, the project team begins by implementing the “Must Have” features, then moving on to “Should have” items and, if time permits, “Could have” features.
[[File:Fixed Duration - 3.jpg|300px]]
However, in order to ensure that the MUST is delivered, we need to have some flexibility in our projects. One rule in DSDM in this sense is that “must have” features must represent a maximum of 60% of all features, while “should have” should represent another 20%.
[[File:Fixed Duration - 4.jpg|300px]]
=== AgilePM 10: Control ===
Sometimes it is believed that Agile methods involve no kind of documentation, planning, or control, and that only by using communication and rituals such as daily stand-ups and iterations they will be Agile.
Although sometimes it is considered that by removing certain control elements from Waterfall approaches we move closer towards Agile, in fact we are moving towards Chaos.
[[File:Control - 1.jpg|300px]]
This is because Agile is a process and to have a process we need control at all times and to be able to demonstrate control, this being another of DSDM’s key principles.
This is achieved through plans for the work being undertaken, this plan being aligned to agreed business objectives. In addition, we need to ensure that transparency exists with regards to the work performed by the team.
For this to happen, the Project Manager and Team Leader together with the rest of the DSDM teams need to make plans visible to all stakeholders, measure the progress made by focusing on the delivery of products instead of on finished activities, manage proactively, continuously evaluate project viability by referring to business objectives, and use the appropriate level of formality for tracking and reports.
<span style="font-size:75%; line-height: 1.31em;">Keywords: AgilePM, AgilePM Foundation,  AgilePM Practitioner, AgilePM Certification, AgilePM Exams, AgilePM PDF, AgilePM Manual </span>

Latest revision as of 08:10, 7 January 2017

AgilePM Videos

01 AgilePM Introduction 
02 AgilePM Adaptive Approach 
03 AgilePM Incremental Delivery 
04 AgilePM Iterative Development 
05 AgilePM Quality 
06-AgilePM Collaboration 
07 AgilePM Communication 
08 AgilePM Business Need 
09 AgilePM Fixed Duration Projects 
10 AgilePM Control