SPA Conference session: Identifying and Avoiding Anti-Patterns of Project Execution

One-line description:A workshop to identify "anti-patterns of project execution" (undesirable behaviours which lead projects into disaster) and explore how we could "refactor" these into behaviours which lead to success
 
Session format: Workshop (150 mins) [read about the different session types]
 
Abstract:Use of a software development methodology, whether it's based on waterfall, iterative or agile approaches, is now mandatory on most software development projects. However in our experience, these methodologies are almost universally loathed and derided by all concerned - sponsor, users, management and developers. At best, the project is successful in spite of the use of the methodology, rather than because of it, and at worst, the project suffers delays, descoping, quality issues and sometimes even cancellation.

In this workshop we will identify some of the undesirable behaviours which tend to subvert the successful application of a methodology - "anti-patterns of project execution" - such as analysis paralysis, methodology kerplunk , governance façade, zombie march, and the ball and chain of responsibility. We will then work as a group to work out why we end up with these. (For example, a practice may have been useful in some form of project when the methodology was first developed - we will look at why it might have been useful then, but not on the project where it was observed as an anti-pattern.)

We will then decide whether these practices should be dropped or adapted ("refactored") in particular project contexts (skills, size, system type, budget and timescale constraints etc.) - based on what actually works in the experience of the presenters and the session attendees.

Our goal is not to come up with an "uber-methodology" which is applicable to any project, but rather to understand how better to apply the methodologies we've got, how to identify those parts of them which are genuinely valuable to your particular project and those which can be ignored, and recognise anti-patterns early on and change course before it's too late.
 
Audience background:Planners, architects, designers and developers who feel it is important to have a methodology but are frustrated with the lack of success of the methodologies they have today and want to understand how to make them work better. The session will be methodology-agnostic - equally relevant to you if you're an SSADM stegosaurus or an agile acolyte.
 
Benefits of participating:- Learn what methodologies aim to provide and understand why the reality so often falls short of the intention.
- Familiarise yourself with anti-patterns of project execution, learn how to recognise these and how to either avoid or neutralise them.
- Gain knowledge and insight based on the real-world experience of the presenters, and more importantly, the other attendees at the session.
 
Materials provided:Presentation slides
Worksheets for exercises
 
Process:- Introduction to set the scene and explain the purpose of the workshop.
- Presentation 1: The Myth and the Reality
Contrast what methodologies aim to provide (structure, rigour, efficiency) with the reality of most software development projects. Explain the concept of anti-patterns of project execution: undesirable behaviours which tend to subvert the successful application of the project's methodology - and provide a few simple examples.
- Exercise 1:Identifying Methodology Anti-Patterns
Split into groups which will identify anti-patterns for project execution which they have observed on projects (or maybe even been responsible for), and try to understand why these happen. Re-convene to share and collate outputs.
- Presentation 2: It doesn't have to be this way!
Propose a technique for "refactoring undesirable behaviours" - that is, recognising and neutralising anti-patterns or predicting and avoiding them.
- Exercise 2: Refactoring project behaviours
Group session to look at how to recognise the anti-patterns before it's too late, and why it was an anti-pattern in the particular project context. Determine whether any change to the project would cause the underlying practise to work and give benefit. Based on this, use the positive experiences of the attendees to identify constructive behaviours to neutralise these anti-patterns, or identify project contexts in which they should be avoided altogether. Re-convene to share and collate outputs.
- Conclusions and Summary
Try and identify some common themes, and decide if this approach can help, or whether we should abandon the application of methodologies altogether.
 
Detailed timetable:
 
Outputs:Description of anti-patterns identified
Description of refactoring approaches identified
All materials will be made available on the conference wiki.
 
History:None.
 
Presenters
1. Nick Rozanski
large UK retailer
2. Andy Longshaw
Blue Skyline
3.