Agile Method: SCRUM
First and foremost, the major false impression from those who don’t recognize about PMBOK, is that it is a methodology that should be strictly followed and involving nonstop documentation. Apparently, It is not. The Project Management Body of Knowledge (PMBOK) is a set of procedures that have been identified as being crucial for winning projects delivery. It is up to the project manager, together with the stakeholders, to define what processes should be used and to which degree. [1]
Scrum on the other side, is a combination of a values and tools based on the Agile Manifesto aiming at delivering (mostly but not only) software projects. It was developed by Ken Schwabe . Scrum values and artefacts are clearly defined and not following them means you’re not doing Scrum. Its goal is to radically develop efficiency in teams previously paralyzed by heavier, process-laden methodologies. Its projected use is for supervision of software development projects as well as a wrapper to other software development methodologies such as Extreme Programming. [2]
Scrum has three Fundamental Roles: 1. Product Owner: Responsible for communicating the vision of the product to the development team. It is the most authority of the three roles, it’s also the role with the most responsibility. 2. ScrumMaster: Helps the team remain creative and productive, while making sure its successes are visible to the Product Owner and does not manage the team. 3. Team Member: the team is responsible for completing work and usually the UI designer, software engineers and programmers.[3]
Both are embracing change: Scrum embraces change by letting features to come in and out of the Backlog. PMBOK has a slightly different approach: simply put, any change request should be documented, reviewed by a defined set of people, added to the WBS if accepted and updating the various baselines (scope, cost, quality). Actually let me rephrase my point with Scrum: the Product Owner is responsible with what comes and goes in and out of the Product Backlog. Yes, that’s right, again Scrum fits in the PMBOK when it comes to change management.[1]
Project values drive how the project will be managed: Scrum wouldn’t be what it is without the underlying values of the Agile Manifesto. When projects start with Scrum as basis, the direction is clear as to how the team should work together. When PMBOK is used as basis for projects, there is no pre-defined set of values to guide the team: it’s up to the project manager, together with other stakeholders, to define the project values and use the tools or define the processes that will be aligned with the projects values the various stakeholders committed to.[1]
All the values and artifacts present in Scrum fit in the PMBOK Knowledge Areas (The Integration, Range, Time, Price, Value, Risk, Procurement, Human Resources, and Communication): Sprint planning, Sprint review, Product Backlog, Estimations, Team building, doing the dangerous stuff first, defining ‘done’, close customer relationships, measuring success, daily Scrum, iterative planning it all fits in the PMBOK Knowledge Areas, only with a different vocabulary. Again, it’s up to the project manager, together with the stakeholders, to define how all these areas should play together. [1]
REFERENCES:
1. http://www.njamin.org/blog/.PMBOKvs. Scrum.Retrieved 23 November 2009.
2. http://www.mariosalexandrou.com/methodologies/scrum.asp.Retrieved 29 November 2009
3. http://www.controlchaos.com/about/.Retrieved 29 November 2009
No comments:
Post a Comment