Difference between revisions of "AgilePM-Video-Introduction"

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

Revision as of 07:59, 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