Introduction
No two projects are alike and because of that it may well be sensible to vary the approach you use to deliver them.
It is therefore useful to consider how projects differ and how that might affect our approach to delivery.
Types of Project
So first lets look at some different types of project:
Type A - Product Implementation
For example: A project using an established team that is to deliver a lightly tailored version of a product they are familiar with to an existing customer.
The team has previously implemented the product for other clients.
Type B - Product Enhancement
For example: A development using an established team working on a product they are familiar with and delivering enhancements in a on-going /continual stream to an internal or external customer.
Type C - Greenfield
For example: A project using an established team working on delivering a new product that necessitates the use of new tools and techniques.
Type D - Complex Greenfield
For example: A project using a new team that working with other companies (including offshore) is delivering a complex new product (necessitating the use of new tools and techniques) with a defined scope to a new customer.
The customer requires the project to be fixed price for a fixed (and challenging) date
The team also has to deliver a variation on that product to another company for the same date.
The implementations will coincide with an implementation of a related system being delivered by another company to the same customers.
Risk Assessment
So broadly speaking we can see the complexity and hence risk increases as we move from A-D and we can imagine our approach to delivering these different projects may well differ.
It's also clear that various factors contribute to that risk assessment for example:
- Experience level of team wrt the product and / or wrt the tools and technologies to be used on the project.
- Involvement of third parties and level of experience of working with them.
- Level of experience working with the customer.
- Constraints such as enforced delivery date.
- Fixed price delivery.
- Complexity of product.
- Related projects creating dependencies.
These factors are mentioned in the example projects above - but there are other risk factors.
I have often used a "Risk Assessment Checklist" for projects that is pre-populated with factors such as the one listed above.
I use it, at the start of a project, to score the project against the risk factors.
Seeing the risks listed out and scored then allows you to consider how you are going to mitigate them.
Deliverable and Methodology / Practice Selection
So how do we decide on our approach for a given development stream or project?
We rate it according to our risk checklist and as a first step we consider what deliverables we may need to create.
Companies practicing waterfall often have a defined set of deliverables and during Initiation a deliverables plan is created that commits the project to producing an appropriate subset of those deliverables.
So for example if the project is greenfield a Solution Architecture document might be produced.
This approach is just as useful in an Agile methodology - you can look at the project, look at it's risk profile and where the complexity is and decide on which documents you will produce to help get consensus and prevent misunderstandings.
For a Type A project there might be little or no new documentation required but you can imagine a Type D project might require a number of documents to be written e.g. Implementation Strategy.
In a similar vein I typically propose that at the start of a project you consider the various Agile Practices and agree which you will run with.
Doing this also gives you the opportunity to consider what you need to do to mitigate the risk associated with dropping practices e.g. if the practice of co-location isn't possible for a given project what will you do to minimise the impact of not following that practice?
n.b. If you have a Type B project / workstream you will already be running it as an agile workstream using all the agile practices that fit - so the above won't be necessary.
FAQs
You're talking a lot about documentation here - how is that compatible with being lean and agile?
The values linked to the Agile Manifesto include the statement "We ... value: Working software over comprehensive documentation" - so that is stating a preference not stating that to be truly agile documentation shouldn't be produced. If there is a clear need for it then it would be risky not to produce it. If we take the Type D project - it's clear we need to start thinking about what is going to be a complex implementation early in the project and given it is complex and also involves third parties we really need to document the who, what, where and why of the implementation. Conversely for a Type B project we'd have previously implemented the application so we'd just need to dust of the implementation plan / continuous deployment process and check we were still happy with it.
Many experts have written about how agile supports projects and many large companies are running 100% pure agile development shops - if they can do it why are you proposing hybrid models?
The experts and companies you are referring to will typically be talking about or running Type A, B or C projects or variants of those types - totally compatible with pure agile - it's when we are constrained by factors beyond our control e.g. customer expectation of fixed price and scope delivery (included in the example project for Type D), involvement of new offshore partners, constraints arising from our own internal structures etc. that we have to consider and vary our approach. The driver behind the process I've described above is, anyway, to help ensure that delivery of ad-hoc projects is as agile as possibe not the other way around.