SDLC: The price of disagreement

[vc_row padding_top=”0px” padding_bottom=”0px”][vc_column fade_animation_offset=”45px” width=”1/1″][text_output]When teams fail to agree and follow a common approach to developing and releasing software it often results in delays, duplication, and a mountain of technical debt.

This post explores the challenges behind one of most important decisions your delivery team or programme will make – how to agree and follow the SDLC.

Are we talking about ‘Software’ or ‘Service’ development?

Actually, it’s both. SDLC commonly stands for the Software Development Life Cycle, or Service (System) Development Life Cycle. (This may vary depending on profession and experience.)

The lifecycle covers the end-to-end process of developing, releasing and maintaining code into a live environment in support of a service.

And, its primary purpose is to make sure teams follow a common, consistent approach to delivery at every stage.

What is the SDLC made up of?

When you boil it down, the SDLC itself consists of four main elements:

• A set of processes – things that need to be done before you can progress to the next stage of the lifecycle
• Some essential artefacts/documents – things that need to be produced at each stage of the lifecycle
• A bunch of environments – to support development of code and (latterly) maintenance of software within that stage
• Some governance – both governance of the SDLC (as a thing) and governance within SDLC (review, sign off points etc)

A deeper dive of these elements is another blog post, but it’s useful to list these four here, just so we understand one another.

Why is it important?

Following a common SDLC is critical to the success of any digital programme as it:

• supports continuous delivery of code into live environment as quickly as possible
• enables safe, sustainable releases into live production that mitigates risk to existing live operations
• ensures each release has an agreed level of service, technical and business support

Getting these three right really do matter.

That’s probably enough of the basics.

‘This all sounds perfectly sensible. What’s the problem?’

Like all good ‘sensible’ approaches, people have a wonderful knack of dropping spanners in the mix (yep, that’s you too).

So given we’ve already stated the fundamental importance of getting a working path to production in place, it’s worth exploring some of the challenges that large, digital programmes commonly face while trying to set this up.

1.    ‘You don’t want to do it like that…’

In the (increasingly distant) days of the single supplier, said supplier would be reasonably expected to lay out how the SDLC was going to work, and everyone would be expected to follow it. That was that. Worry about the value later.

In the post GDS landscape, we bring in different suppliers to provide expertise at specific points along the lifecycle. Which is the right thing to do (you can read up on the logic in another post), but this brings it’s own challenges.

An absolute cornerstone to establishing a healthy SDLC is recognising and respecting the contributions different communities of practice make at specific points along the lifecycle. This is not just about engagement, but inclusion (the SDLC can only be as strong as its least collaborative link). Architecture, DevOps, Operations, Security and representation from the development teams make up the core SDLC community. But others communities e.g. testing, will also have a valid voice.

It’s likely these communities will be represented by a variety of suppliers. They will have their views of what good looks like and what works best, based on their experiences and roles.

But, no one has a monopoly on SDLC wisdom. The trick is to collectively look at your specific programme with fresh eyes and gain consensus about a sensible approach that delivers value at every stage of the lifecycle. And, you should do this in the early stages of the programme.

It’s not going to be perfect, so be honest about your limitations as they present themselves and agree how you’ll work together to resolve them.

2.    ‘I want speed, you want safety. What gives?’

The SDLC must:

• support quick delivery of code
• make sure it’s safe for the business to accept and support – checking and assurance is a critical part of the process

This creates a natural professional tension between the development and operations community because:

• any checking or assurance activity that development teams consider unnecessary  may be considered a blocker to speedy deliver
• any compromise to checking or assurance activity, where not agreed, may undermine the integrity of the live service

But, this tension is a good thing and should be embraced. It forces collaboration. And, if done really well, means that people have to adopt a genuine awareness about how and where their role contributes to the end to end lifecycle.

Remember, good will is the most under-recognised currency on any programme. So proactively forge close ties with people you are going to be relying on when the pressure cranks up.

3.    Ownership is going to change as the life cycle matures

A bit of a grey area this one. While the case for a dedicated SDLC community to collaboratively deliver a path to production is relatively easy to make, someone will need to have the final say. So, who has ultimate responsibility for the SDLC?

Eventual ownership will lie with the business. However, in the earlier stages of the programme, particularly before any major releases have occurred, the programme lead is likely to be the natural owner.

They will be closer to the day to day evolution of the programme as the communities of practice work towards creating a path to production. But, foresight should be given regarding the ‘transition of ownership’ as environments become live, service support kicks in and frequent releases become the norm.

Some practical things to consider:

• Start with a set of SDLC principles. You’re going to disagree on some of the details down the line, so agreeing your principles upfront will provide invaluable points of reference to help resolve or avoid conflict.

• Agree a common language to describe the SDLC and its components. People will bring different terms and phrases to the table. It doesn’t really matter which ones you use, just as long as they are understood and used consistently.

• Once you’ve agreed your actual approach, trust the process. Large programmes will naturally be bumpy at times, but unspoken workarounds are the devil – they can break cross working relationships and can cause serious failure demand (particular if built on top of each other).

• Implement an SDLC MVP as soon as you can. Months of endless discussion will result in stagnating code (from a release point of view), and a purely a theoretical SDLC that isn’t improving based on feedback, it’s just developing based on people’s’ opinions.

• Check in regularly. The SDLC is a living, breathing beast. So make sure the contributing communities of practice have a regular conversation to see how you are doing and support continuous improvement.

• If the approach isn’t working, call it out early. Then change it. Make sure the relevant parties are all aware of the changes though!

• Have a plan to improve and evolve. The SDLC is made up of several moving parts that will take time to establish. Iterating will be a necessity.

• Finally, always think about the bigger, end to end SDLC picture. You are only one part in creating and maintaining a successful path to production, so understand what role you play and how you contribute to making it work.

[/text_output][/vc_column][/vc_row]