What is the definition of "project" in Agile settings?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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).

Answer 4

In Project Management you deliver a Project while in Agile you deliver an Epic. Projects have a defined start and end date while Epics have Products with a defined acceptance or done criteria instead of a date.

IMO the term Project shouldn't be used in Agile. You should align the teams to use similar terms and rolls so that generally procedures and practices can be understood and agreed by all. However if you are looking for the equivalent term to Project in Agile it wold be Portfolio Epic or Epic.

I would recommend looking into Safe for Lean Enterprises to get a good broad understanding for how to align several teams and products under a common Portfolio Epic which aligns to the business.

Another point to consider is the perspective of a Project or Epic in Agile. It should be known that Teams do not work on Epics or Projects they work on Products which could be a feature or item(s). Directors (Product Managers) and senior management work at the Epic or Project level. When they look for the status of an Epic they would be interested in understanding how many features have been complete for a given Product. The actual Product Delivery Team may not have a view of the overall Epic but only the products and features they are delivering.