7-9 minutes<\/p>\n
Whether you are a Scrum Master<\/a> , Project Manager, Product Owner<\/a> or Team Member<\/a> or simply someone who wants an answer to the question \u201cHow do I run an Agile Scrum project in the real world\u201d, this article can definitely provide an answer for you.<\/p>\n The traditional Project Management (waterfall) approach is linear where all the phases of a process occur in a sequence. The approach depends on predictable tools and predictable experience. Each and every project follows the same life cycle which includes the stages such as feasibility, plan, design, build, test, production, support, as shown in the figure below.<\/p>\n Waterfall vs Agile software development The entire project is planned upfront without any scope for changing requirements, such as Waterfall, PMI\u2019s PMBOK, and PRINCE2 are all rigid and highly controlled. They outline distinct stages for project planning from start to finish, and assume that you have all the requirements and information you need upfront.<\/p>\n This approach assumes that time and cost are variables and requirements are fixed. This is the reason why traditional project management faces budget and timeline issues.<\/p>\n When a traditional system focuses on upfront planning where factors like cost, scope, and time are given importance, Agile management gives prominence to teamwork, customer collaboration, and flexibility.<\/p>\n Agile rejects these traditional project management methodologies as cumbersome, restrictive, and unsuitable for the new era of speed. Agile project management is iterative and aims at constantly incorporating user feedback and continuous releases with every iteration of software development project as shown in the Figure above. Every task output is a product you\u2019re selling to stakeholders. Team and work structures are designed around creating things that are directly useful to the customer or client.<\/p>\n According to the 2011 CHAOS Manifesto from the Standish Group, Agile projects are three times more successful than Waterfall projects. The graph below shows the specific results reported from a study conducted based on projects executed from 2002 to 2012:<\/p>\n Success in project management has been traditionally associated with the ability of the constraint parameters of projects in scope, time, cost, and quality called iron triangle as shown in the Figure below. It is a popular metaphor pointing out that the project manager is asked to reach a reasonable trade-off among these constraints.<\/p>\n Agile vs traditional iron triangle in project management<\/a><\/p>\n For example, a project can be completed faster by increasing budget or cutting scope. Similarly, increasing scope may require equivalent increases in budget and schedule. Cutting budget without adjusting schedule or scope will lead to lower quality. In practice, however, trading between constraints is not always possible. For example, throwing money (and people) at a fully staffed project can slow it down. Moreover, in poorly run projects it is often impossible to improve budget, schedule or scope without adversely affecting quality.<\/p>\n In traditional sense, Iron Triangle in project management is clearly insufficient as a model of project success because it omits crucial dimensions of success including impact on stakeholders, learning and user satisfaction. Iron Triangle in Agile Sense \u2013 A Paradigm Shift In traditional approach, the triangle would typically look like the one on the left as shown in the Figure below. As you can see, there is a fixed scope of product requirements. So in order to ensure the product can be completed all of our required features, we need to be a little flexible with our resources (and budget), and schedule (deadlines). If we absolutely need the product to have a list of features described in the upfront requirements pecification, perhaps we need to delay the release date by several months or more in reality.<\/p>\n In the Agile sense, there are a fixed schedule (in Scrum we do this through time-boxed<\/a> Sprints<\/a> , and fixed resources. Thus when things doesn\u2019t work according to the plan, it is the scope that needs to be reduced. In Agile, however, we ensure that even if we have to compromise on scope, we are still delivering the highest priority items in the product backlog for maximizing the value yielded by the project.<\/p>\n","protected":false},"excerpt":{"rendered":"Traditional Project Management<\/h3>\n
Agile Project Management<\/h3>\n
Traditional or Agile \u2013 How to Choose?<\/h3>\n
Agile vs Traditional Iron Triangle in Project Management<\/h3>\n
What is the Problem of Traditional Iron Triangle?<\/h3>\n