Difference between revisions of "AgilePM-Video-Introduction"

From AgilePM wiki
Jump to: navigation, search
(AgilePM 07: Communication)
(AgilePM 09: Fixed Duration Projects)
Line 28: Line 28:
  
 
[[File:BN - 2.jpg|300px]]
 
[[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]]
 
  
  

Revision as of 07:58, 7 January 2017

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.


BN - 1.jpg


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.


BN - 2.jpg



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.


Control - 1.jpg


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.

Keywords: AgilePM, AgilePM Foundation, AgilePM Practitioner, AgilePM Certification, AgilePM Exams, AgilePM PDF, AgilePM Manual