Difference between revisions of "AgilePM-Video-Introduction"

From AgilePM wiki
Jump to: navigation, search
(AgilePM 05: Quality)
 
(21 intermediate revisions by the same user not shown)
Line 1: Line 1:
  
=== AgilePM 01: Introduction ===
+
AgilePM Videos
  
<youtube>gPKcOcsQ-PQ</youtube>
+
[[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]]
Let’s say you are working in a company in the IT department and you have created a number of software applications for different departments (e.g. sales, logistics, finance) .  These application are being used and the IT department is now involved in day to day support and keeping users happy and productive.   
+
[[MP-AgilePM-04-Iterative Development|04 AgilePM Iterative Development]]
 
+
[[MP-AgilePM-05-Quality|05 AgilePM Quality]]
One day the head of the sales department requests a new application to allow users to order, re-order and track deliveries from a mobile device as they understand that more and more shopping is now one online from mobile devices and a competitor is rumored to be working on a similar product. 
+
[[MP-AgilePM-06-Collaboration|06-AgilePM Collaboration]]
 
+
[[MP-AgilePM-07-Communication|07 AgilePM Communication]]
As this stage you have something in common with the head of the sales department and that is that you don’t know what the sales department actually wants as the expectations are very vague. So you have to start a conversation with some people from the sales departments and extract the know requirements. It can be a good idea to facilitate a number of workshops to gather these requirements and after each workshop we will have a better idea of what they need. 
+
[[MP-AgilePM-08-Business Need|08 AgilePM Business Need]]
 
+
[[MP-AgilePM-09-Fixed Duration Projects|09 AgilePM Fixed Duration Projects]]
 
+
[[MP-AgilePM-10-Control|10 AgilePM Control]]
x
 
 
 
 
 
The next step is perhaps to start the project and deliver what is expected. We work hard in our IT area and we focused on delivering on-time and within budget.  Sometimes we may ask questions to the users if our requirements are detailed enough.   
 
 
 
Once we are ready, we show the application to the users and in many cases (for IT projects, creative projects) we find that the expectations were something different and what we delivered cannot be used.  This is because we could not understand the expectations up front and it was an impossible task to try to gather all the requirements up front. 
 
 
 
 
 
x
 
 
 
 
 
This happens a lot in creative projects (IT development products, design, writing, ). Projects like constructing a house or a building are much easier to document and discuss so it much easier for all stakeholders to get a better understanding of the expectations. 
 
 
 
So how do you think we can improve the way we carry out these creative projects and deliver a product that matches expectations at the end of the project?
 
 
 
=== AgilePM 02: Adaptive Approach ===
 
 
 
<youtube>X2FvK9fLltE</youtube>
 
 
 
 
 
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. 
 
 
 
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? 
 
 
 
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:
 
* Facilitation workshops
 
* Prototyping  (e.g. A 3D model of a house) 
 
* 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. 
 
 
 
 
 
x
 
 
 
 
 
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.
 
 
 
 
 
x
 
 
 
 
 
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 ===
 
 
 
<youtube>Qicl7ficDoM</youtube>
 
 
 
 
 
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.
 
 
 
 
 
x
 
 
 
 
 
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.
 
 
 
x
 
 
 
=== AgilePM 04: Iterative Development ===
 
 
 
<youtube>UVw_rIgnC7I</youtube>
 
 
 
 
 
As established earlier, in adaptive approaches we have development cycles.
 
 
 
 
 
x
 
 
 
 
 
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.
 
 
 
 
 
x
 
 
 
 
 
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 ===
 
 
 
<youtube>-NwJKISPiRo</youtube>
 
 
 
 
 
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.
 
 
 
x
 
 
 
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.
 
 
 
x
 
 
 
 
 
 
 
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 ===
 
 
 
<youtube>lbuKTzdh30I</youtube>
 
 
 
=== AgilePM 07: Communication ===
 
 
 
<youtube>iLXMcfVRfmU</youtube>
 
 
 
===AgilePM 08: Business Need ===
 
 
 
<youtube>-CFx_ZSOjvM</youtube> 
 
 
 
=== AgilePM 09: Fixed Duration Projects ===
 
 
 
<youtube>CX-izYjED18</youtube> 
 
 
 
=== AgilePM 10: Control ===
 
 
 
<youtube>H4YXqPqJjGA</youtube>
 
 
 
 
 
 
 
 
 
 
 
<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 09: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