Software development lifecycle – Part I – Introduction

Software development lifecycle – the process of how we build software, the steps we go through to design software, build it, test it, deploy it – it means a lot of different things to a lot of different people, but yet we find that many organisations aren’t really paying close enough attention to their processes and management of software development which leaves them reacting to problems, not knowing when they are going to deliver, delivering features that are irrelevant or lower priority than missing features and with no deep insight into what they are supposed to be delivering in the first place.

I’ve heard a number of teams say “oh, we’re agile"" – and what they mean is they have no specifications, no plans, no timescales and at the end of it, no jobs because the company employing the team went bust waiting for the team to deliver something.

So, in this series of blog posts I want to take a look through some of the things to think about when implementing structure around your development activity – on the one hand you don’t want to just have a team banging away at code with no formal structure, as the example above, but similarly you don’t want to get too binding with this otherwise you’ll end up with Carl (lets call him Carl in this situation) rocking in the corner, muttering about how he’s “too confined and boxed in maaaan” – development is a creative, problem solving process, let them be creative but within some structured boundaries.

I’m going to keep this series open ended an just chew the fat on a different topic each week and see where we come out. Whilst not a list of topics that I’m going to write on individually, below is a list of some of the things I'm going to explore in this series;

• Typical phases of a project
• How to understand the problems and get a holistic view.
• Involve the business or customer early and keep them engaged!
• Defining the product
• Why bother
• What format
• Who owns the product?
• Understanding and addressing risk.
• Prove it – show me the code.
• The point of spikes.
• Housekeeping!
• Keeping track of risks, issues and key decisions.
• Backlog pruning.
• Keeping the customer engaged.
• Other project artefacts.
• Making a plan – estimation is not about marketing!
• Iterating and aggressive construction.
• Transitioning to live/launch.
• Supporting the product.
• Managing the team
• The role of team lead
• 8 hours does not a day make
• Motivating technical people.
• Doesn’t involve putting the dev team in an open plan office next to the sales department hotlines!
• Continual harassment != productivity.
• Monitoring progress
• Dealing with hold ups and blocking issues.
• Why it’s possible to keep the reigns of management loose and still be impossible to get away with being a slacker.
• Capability leads and subject (domain) experts.
• Recruiting technical staff
• Show me the code!
• Solve this problem!
• Welcome on board – induction or abduction?
• Training and/or free time to experiment.
• Managing the code, the build and quality
• Code reviews – still as important today! But let’s not get hung up on the traditional formality.
• Daily and continuous builds
• The build wall
• Unit testing
• Bugs – squish em soon and squish em often.
• It works on my machine!
• Source control.
• Framework, framework, framework.
• Strategy
• Have one!