3

The context is a PMO running across two development groups, one doing Agile development, the other using the waterfall model. In order to come up with a common approach and engagement model, we would like to standardize roles, responsibilities, and definitions.

The "project" definition is somewhat fuzzy in the Agile world, because work is a collection of features/epics that are aligned to a value stream. A project is a more legacy concept of an activity that has a start/end date, with hopefully some value being delivered to customer.

How do we define "project" in the Agile world?

  • "one doing Agile, the other development"? Is the "Agile" group not doing development then? Or are they doing support/maintenance and the 'dev' team is creating new stuff? – Stephan Jul 31 '13 at 9:25
  • Sorry, typo...meant to say one group doing Agile, the other one using a Waterfall methodology. – Agile PMO Jul 31 '13 at 13:11
  • 1
    I think this is an X/Y question. "How do we define 'project' in the Agile world?" doesn't seem to be your real question. I think you're really asking how to standardize roles, responsibilities, and definitions across models. Yes, no, maybe? – Todd A. Jacobs Jul 31 '13 at 14:09
3

The definition of a project in agile terms is no different to that of a project in traditional terms. The difference is how the project is run and executed and the values behind the project.

Common

Both agile projects and traditional projects:

  • have a start and end
  • may be constrained by schedule, scope or budget
  • should be for a single product; (lets not debate symantics)
  • run internally built or by external vendors
  • be part of a larger program or portfolio of work
  • deliver a product
  • deal with risk management and risk mitigation
  • If you look at PRINCE2 and PMBoK, both promote iterative approaches in the form of stages or phases. Most agile frameworks do to.

Differences

Agile recognises that we deal with complex technologies and requirements in a world of many uncertainties and ambiguities. In doing this the approach is more an empirical process control instead of following a defined process control. It allows the team to adapt around challenges.

The work is done in very short iterations, not exceeding 30 days to mitigate risk against these complexities and uncertainties. Traditional projects may run for years without phases, or phases may be several months. Agile practitioners feel that this is far too long and far too many risks are involved.

Most Agile practices follow lean principles to eliminate waste and only build what is needed. Agile practitioners recognise upfront requirements normally lead to high volumes of waste; e.g. 64% of features are rarely or never used - Standish Group Research.

Most people don't get agile as it is hard. The reason it is hard is we have all been educated to work with defined processes and control these processes. Breaking this mindset to deal with and learn to manage complex projects using empirical process control takes a lot of energy and commitment. It has been proven to be a very reliable way to deal with software projects but needs the change.

I have done some pod-casts on project management and Scrum which highlights these differences in detail, you may want to use google to try find these.

  • Thanks Brett, makes sense. I'll check out some of the podcasts. – Agile PMO Jul 31 '13 at 13:11
1

Regardless of the mechanism to deliver (as per @Brett's answer) I suggest that the definition of a project be as simple as "a project is an activity which delivers measurable value to the organisation by either increasing revenue, reducing cost or improving efficiency".

Each project that you deliver should be easily quantifiable as to why you are doing it.

0

How Agile projects are different from Waterfall projects

To elaborate on what @Brett Maytom PST said on the differences side:

  1. Minimize project risk: If you have features that are high risk (any unique value proposition that has not been built before), you can schedule them early on to validate whether it is at all doable. If you determine that it is either not possible or too costly to build, you can rethink the project viability.

  2. Fast feedback: Agile projects produce "shippable feature increments" at the end of each sprint. So, you can deploy this and get business users to play with it, do usability testing and sign up beta customers to get early feedback. This gives you an opportunity to change direction or even abandon the project before pouring the full budgeted amount into the project. In waterfall projects, you get a shippable product only at the end of the actual project completion - which itself may be above budget and behind schedule.

  3. Value negotiation: When we do an estimation session, too often our Product Owner is surprised. Some things the PO thought would be hard, turn out to be a simple setting in the library that the developers opted to use. While others that look simple enough require extensive custom coding. Looking at the estimate, our PO may drop some features and lower prioritize others. In waterfall projects, once the requirements are written, it is carved in stone (subject to change control, which is painful).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.