Difference between revisions of "AgilePM-Video-Introduction"

From AgilePM wiki
Jump to: navigation, search
(AgilePM 06: Collaboration)
 
(9 intermediate revisions by the same user not shown)
Line 1: Line 1:
  
=== AgilePM 07: Communication ===
+
AgilePM Videos
  
<youtube>iLXMcfVRfmU</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]]  
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.
+
[[MP-AgilePM-04-Iterative Development|04 AgilePM Iterative Development]]  
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.
+
[[MP-AgilePM-05-Quality|05 AgilePM Quality]]
 
+
[[MP-AgilePM-06-Collaboration|06-AgilePM Collaboration]]  
 
+
[[MP-AgilePM-07-Communication|07 AgilePM Communication]]  
[[File:Communication - 1.jpg|300px]]
+
[[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]]
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 ===
 
 
 
<youtube>-CFx_ZSOjvM</youtube>
 
 
 
 
 
 
 
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 ===
 
 
 
<youtube>CX-izYjED18</youtube>
 
 
 
 
 
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 ===
 
 
 
<youtube>H4YXqPqJjGA</youtube>
 
 
 
 
 
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 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