The Living Room Architect

Time and time again I see software teams going through the motions and using certain practices because they are told it is the "right thing to do" or "best practice". Even when that process gets in the way of their productivity. Bollox! Software Engineering practices whether branded Agile or not provide a massive toolkit for every software engineering team to use. It doesn't mean you need to use every tool in the toolbox for every project, which is what some teams I've seen end up doing. It means you select an appropriate tool or set of tools at an appropriate time in order to achieve your goals. It means you need to be intelligent about recognising when a practice or process is benefiting your project and when it is holding you back. That to me is the art of software engineering... Identifying the set of practices required for each project based on the skills of the people involved and what you're trying to achieve.

An approach I use when introducing Agile practices to software projects with people who've never worked on an Agile project is to introduce selected practices incrementally. I might start working with a team and notice that communication between the engineers and the product owners is terrible. In that case I'll simply introduce a daily stand-up to the group. I might then facilitate a retrospective to identify other areas for improvement. If the biggest problem a team has is that they don't have agreement on features for a release then I'll facilitate a release planning session. If the biggest problem is that they don't feel confident changing the code then I might introduce them to test driven design.

This approach works really well because it gradually introduces everyone to the specific development practices that are going to help them solve their current problem. Call it Agile development if you must, but this works and before you know it you've got a team that has just enough process overhead to achieve their goals.