Introduction
Here are some links to pages that describe how I decide to deliver a particular development or project.
As you will read I don't necessarily think there is one methodology that fits all projects.
I think that at the start of any project you should looks at it's profile (particularly it's risk profile) and for example your ability to deliver it and then consider what methodology or practices you should adopt for it's delivery.
Obviously if, for example you have an application that is undergoing a never ending series of enhancements you will likely just establish an agile based method and move forward - here I am talking more about ad-hoc and/or greenfield projects.
Project Types and Development Approach
The industry seems to gloss over the fact that we clearly deliver different types of development - I think this is perhaps because the majority of people writing about methodologies have come from companies that are focussed on the continuous enhancement of a small number of applications.
Anyway - read this page to understand the different types of project we may have to deliver and how I often assess a development or project and then decide on a delivery approach.
Project Types and Development Approach
Approaches
So to summarise what that mean in terms of approach...
Towards the 'simpler' end of the scale we can adopt a full agile approach (or as close to pure as our circumstances allow)
Towards the more complex end of the scale we might need to include elements of waterfall e.g. if we have new offshore development partners whose English skills are not 100% we might want to write specs to eliminate risk.
Agile Adoption
Agile methods are quite loosely defined and with SCRUM for example there is a preference to talk about Values and Principles rather than documenting a whole series of detailed processes.
This is great and I think the right approach - you really get to understand what agile is about by reading about what is valued and thinking through, from first principles, what that means you should do.
As you will have seen (if you've read the pages linked to above) we have a number of agile practices.
Some are technical such as CI and have little behavioural impact and no dependencies on other practices - so they are good candidates to push out early and hence get some momentum going at low risk.
The practices listed with an Impact of 'Organisational' (e.g. co-location, multi-skilled (and eventually cross-skilled) teams, customer involvement) need senior management sponsorship and action.
Other practices - typically listed as behavioural can then follow on with the proviso that some such as TDD and BDD are much more difficult to adopt and should be left until we have achieved some steady state with the more basic agile practices.
We also see above that agile is perhaps most easily adopted for projects / work streams of Type A or B.
With that in mind what I have done in the past is to:
- Identify such a project / workstream
- Create the cross functional team - preferably co-located, confirm the people who will fill the SCRUM roles - SCRUM Master, Product Owner.
- Do a few days training on SCRUM - can be internal.
- Implement Jira or a similar tool (or just use a spreadsheet) and define the backlog.
- You can then proceed with the SCRUM lifecycle with some assurance of success.
As you achieve success with this first project / workstream you can be planning further SCRUM teams and making the organisational changes required permanent.
The success of this first team will also help getting buy in from the business for their commitment to the process and generate the trust necessary for agile to work.