Generally the software development industry has caught on to the fact that iterative development is a good thing. Only people that don’t believe in common sense think it’s a great idea to leave all of your testing to the end and hope for the best. With that in mind then why do people still have a waterfall mentality to their software development processes?
At the beginning of a project you can’t possibly know everything about it, that’s one of the many reasons it makes sense to iterate, so you can do some work and then refine your plans based on your work. For some odd reason though a lot of projects, even though they might develop iteratively, seem to think they should define their process at the beginning of a project in great detail and then stick to it regardless of the facts due to some misguided need for process alignment or similar.
That attitude just doesn’t make sense. A view of what practices will be followed is necessary at the beginning so that everyone’s on the same page and now what they’re meant to be doing, but even the formally defined iterative processes like RUP say that the process should be examined and refined each iteration.
In my experience an extremely detailed formal process is difficult to change. If you’ve got a 50 page development case. huge stack of xml files in your favourite process authoring tool or similar it’s very hard to make useful changes to a process. Of course you can change the review requirements of the Use Case Specifications from Formal-Internal to Formal-External, but it’s not so easy to scale down the formality of business modelling while adding a practice to address user experience issues.
Software development process can (and should) be thought of as a collection of practices. Each practice should address a particular aspect of software development in a complete fashion. Every small technique is not a practice (in coding terms every idiom is not a pattern). Using Use Cases, being Iterative, using Component Based Development are all good examples of practices. They can be added or removed to your project’s way of working and the level of formality can be scaled up or down on each practice. Practices are the natural unit of adoption for processes.
It’s always best to start small and simple. At the beginning of a project just do what you can see. It might initially make sense to think about using Use Cases as a common way of managing requirements for your project and it clearly makes sense to iterate in most cases. Then as the project progresses and more understanding is reached more practices can be added as necessary. This is an iterative approach to software development process, it’s just common sense.
At IJI we’ve been doing this sort of practice based way or working for ages – in fact it’s what the company was created around as the fine brains we have created this approach and brought it to life in EssWork and EssUP which is a kernel and a collection of practices.
Anyway, enough of the company blurb, more about practices. I think everyone can agree that this is a sensible approach to software development as it applies the lessons the industry has learnt about software development back onto the problem. It doesn’t matter which vendors tools are used, or what process frameworks are used this is just a sensible approach, and the best thing is it is compatible with whatever you’re already doing that is successful or necessary in your organisation. I work with organisations helping them to change and adopt their processes and in every organisation I’ve been to is doing at least one thing well. Using practices to work with process improvement means that we can just add to what’s already working, incorporate the necessary governance or operational activities in an organisation, add SCRUM if that’s what’s wanted and have it all work together in a cohesive way of working.
To achieve this adding together of practices in a way that works you need to have a foundation that provides a common understanding of the basic concepts of software development so that practices can fit together neatly. This is intellectually quite tricky to achieve but necessary. It should also be practically invisible to the people doing projects – they don’t want to think about process geeky things like the process architecture that can support practice composition in a seamless way. At IJI we call this the kernel – which I think is a suitably geeky term. We have also built it both conceptually and in software (that’s what EssWork is) along with what we think are the “essential practices” (that’s what EssUP is) and now the big vendors are following suit and packaging their processes this way.
Maybe one day we can get away from branded processes by vendors and just have a software development community using, sharing and collaborating on practices.
Oh yeah, and they should be in tools not websites, and free!