Software development life cycle - how to find your way as a product owner

Software development life cycle methodologies – the basic structure of your project

There are a few popular methodologies when it comes to running projects. These different SDLC models aren’t competing with each other – they can be better or worse for different types of projects. 

Their common goal is to always get the project completed on time, with as few errors as possible. SDLC methodologies all divide the developers’ work into bite-sized chunks, so they don’t choke on the project at large. 

They are all divided into stages like planning, design, building, testing, deployment, and maintenance. But while their ultimate goal is the same, there is more than one way to bake a cake. 

It’s your job as a product owner to know exactly what method your team is using and to participate

Waterfall Methodology: pros and cons

The Waterfall is one of the oldest SDLC methodologies. It’s also very straightforward, and how most people approach tasks in the “real world”. That is, if their real world isn’t software development, let’s say gardening or cooking. 

Simply put, you finish one task and go on to the next task. It’s a flow, just like a waterfall, falling from one stage to another.

In this model, planning ahead is the most important part – what you plan is what you get, no buts about it. This is a documentation-heavy approach, with a few pros and cons. 

Pros:

• You know everything before you start – this includes:
  • Scope
  • Budget 
  • Timeline
• The extensive documentation makes it easy for people to get caught up. 
• Clearly defined starting point and finish line.
• Costs are estimated accurately according to the plan, point by point – no surprises here.
• Testing is clearly defined from the beginning.

Cons: 

• Not very flexible – you get what you plan for.
• Doesn’t take unplanned scenarios into account in the beginning stages. (Although changes can be added – it demands the Project Manager and Client to work together through the change Change Plan, updating the scope, timeline and budget. In short, changes are possible, but they are not taken lightly.)
• Projects might take longer to finish.

There is a time and place for the waterfall model – and this is when you want a clearly defined project from start to finish, whether it’s a short project or a longer one. It’s excellent for very long projects that need to be defined as well as short projects. 

There are many opinions out there that state this is a good option for shorter projects, but there are projects that take a longer time to finish – even years – that do just fine in the waterfall model. The only catch is making these changes – they aren’t made in a sprint. They have to be carefully documented and decided on both the developer side and client-side. Signed, sealed, and delivered – when you make changes, you basically create a brand new plan, from A to Z.

The beginning (planning) phase is the most important. All questions have to be answered. It’s good for when you know exactly what you want – because you’re getting a pre-planned package at the planning stage. It’s a bit like coming into a car dealership and choosing exactly the kind of car package you want, as opposed to getting one designed as you go along. 

Planning the technical project, scope and timeline is the most important part of Waterfall Methodology, because it’s at this stage that you create the whole roadmap for the project. A roadmap that can be changed if necessary – but has to be documented and signed off after every change is made officially. 

Agile methodology

Developed in 2021, Agile has been on the lips of developers ever since. And in their hearts and resumes. “Agile” is the ultimate tech buzzword for a reason. It’s revolutionary not only in the tech scene. It has wandered out into the general world, and people use it for projects that have nothing to do with tech. If you’d like, check out the full Agile Manifesto. 

The Agile Manifesto in a nutshell

There are 12 main principles in Agile methodology. They are: 

1. Early and continuous delivery of valuable software.
2. Change is ok – at any stage.
3. Deliver working software frequently.
4. Constant business and developer teamwork.
5. Motivated individuals get the job done.
6. Face-to-face communication.
7. The measure of success = working software.
8. No burnout.
9. Technical excellence and design.
10. Simplicity – not busy work.
11. Teams who manage and organize themselves get the best results.
12. Constant self-evaluation.

Methodology within methodology – Agile is a very broad term – it’s basically a set of values and regulations that form a package for a collection of processes that developers use to successfully deliver software. It’s basically a pod for a bunch of methodology peas. 

Kanban  – the word “Kanban” originated in Japan, and it simply means a “visual board”, and it was first got developed by Toyota, to aid with their new “Lean” manufacturing methodology. Sound familiar? Read all about Kanban here. 

Scrum – this is a widely used framework for developing, delivering, and sustaining products in a chaotic and complex workflow through self-organizing, learning from mistakes, and teamwork. Adopting Scrum is a great way to start rewiring your team to think in Agile terms. Read the Kanban guide to Scrum teams here.

Crystal, (or Crystal Methods, no jokes please) There are many levels of these methods, depending on the size of your team. The main idea behind it, in the spirit of Agile, is frequent delivery, learning from mistakes, and focusing on individuals with attention to close communication, personal safety, and access to experts. 

Crystal is one of the few methodologies that emphasize “personal safety” – or freedom from ridicule, openness, and trust, so team members can feel that they can talk about any issue or problem that they may notice. 

DSDM Atern – This is a generic approach to Agile, rather than a development-based approach. This is a great approach to use in projects that don’t necessarily involve software but need an agile approach. Developed in 1994, DSDM was a good alternative to the waterfall approach, which can be confusing in long, complicated projects. 

Lean Software Development  – This approach can be traced back to Kanban and Toyota in the early 40s. They needed a lean approach that focused on delivering products extremely quickly, on an “as needed” basis. This has never been done before and required excellent adaptation skills in very large organizations. The trick here is, in a nutshell: 

• Decide as late as possible.
• Deliver as fast as possible.

If you’d like to see CTOs talk about the benefits of making Agile a part of your company on a larger scale, watch this CTO Roundtable discussion with Sriram Narayan, author of “Agile IT Org Design”. 

At what point should you choose your project methodology? At the very beginning, best before you start. It’s near impossible, not to mention wasteful and chaotic, to change it midway through the project, or even just after it’s already on a roll.

 

Should the software developer you hire have an SDLC process ready for you and always implement it?

We know: there’s something about hiring an outside company, whether it’s a software developer or a landscaping architect, that causes people to wonder if they have given up too much control. Sometimes, clients feel that they can retain that control by handling the process of product development. But is that always helpful? Not really. 

If you’re a newbie or undecided 

You’re a business owner and you have a great idea. You have some solutions in mind but you aren’t sure how to implement them. An adopted SDLC process is perfect for you. But you have to understand it properly before putting your trust in an outside development company. 

You don’t have to reinvent the wheel – just learn how to drive, and go! Any development company that you outsource to should have a ready-to-go software development life cycle, and what’s more, they should present it to you, and make sure you understand it as a project owner and are completely on board with it. 

Note: If after discussing the process you will come to an agreement that some aspects of the process should be changed, then all deviations from the process should be written down and listed along with the reasons for these changes. 

If you’re a pro and know exactly what you need

You don’t always have to go along with a ready-made roadmap that your outsourced software development company suggests. 

If you’re a software developer yourself, or have enough experience and know your needs to a T, you can simply request project-specific specialists. We strongly recommend a wide experience in project management if you decide to completely manage or take over the development life cycle process. 

Get to know your team of developers – before you work with them

If you’re outsourcing your development project, it’s a good idea to get to know your team and their methodology ahead of jumping in. Does everybody do it? No – it’s very common to jump right in and then work out the details later. 

Playing it safe before you commit to a team can only pay off in the long run. This advice is based on our experience. This is why TSH developed a preliminary stage for the whole SDLC process – the Client Workshop. It takes time, but our experience with outsourcing and working with clients has led us to believe that there’s simply no better way to start a project or decide whether we are a good fit. 

What to discuss before you jump into a project: 

• Where are you at? We mean everything – from your niche to your current software, and your overall needs.
• Your business goals. 
• Ideal terms of cooperation. 
• How do you see operational matters? (Who is your product owner, what are your deadlines, your first release, etc.) 

Of course, that’s not all – before we start planning sessions we should actually plan the planning sessions themselves. Sound redundant? Not really. You should decide these things ahead of time: 

• Who is going to participate? It’s okay to insist that members of a potential development team join these meetings. Of course, it’s best if a Project Manager joins and then picks the appropriate specialists to join later. 
• How long will the planning sessions take? 
• Last but not least, the agenda for your first meeting 

Once this is all in place, you eliminate most of the stress associated with diving into the great unknown. Both you and the potential software house dive in with a sense of purpose – you get to say exactly what you want and need, and they have the opportunity to match their talent and their offer against those requirements. 

As far as we’re concerned, planning ahead of the project is a win-win. 

Red flag alert: If a company refuses to meet with you ahead of time, or is uncomfortable inviting their dev team to the table, it’s definitely a red flag. 

6 Software Development Life Cycle stages – the ultimate TSH list 

Yes, we’re really going to do it! I know I talked about the 7 stages, 5 stages – or whatever number of stages you can usually find when you Google the SDLC. We have our own list, and while it’s not the “ultimate list everyone should follow or else”, it’s the best list for us. 

Every software development company that does outsourcing or in-house design should have its own software development life cycle structure that fits them best – if they don’t, take it as a red flag.

SDLC step 1 – Introduction (client workshops) 

This step comes before everything else – even before signing the contract! Before we really “start” the project, we take the time to get to know our client and their needs. 

Why do we think this is a necessary step? We call this pre-contract signing project, or scope mapping – a “workshop”. Because it really is a constructive learning opportunity for all parties involved. 

It’s a workshop where we learn about each other. The client’s needs vs. our capabilities and problem-solving powers. Not everyone will have this step on their “ultimate list” – we think it’s a must. 

Depending on the client and their needs, these planning and strategy workshops can take a few hours – or a few days. They represent intense scope planning and projecting SDLC needs, and we always try to extract as much key information as possible. This usually includes the most crucial parts of the potential project, like: 

• The basic situation on the ground – does the client have any software already? What does it do? Why do they need it? What is it? 
• Business goals – that’s the whole point, isn’t it? 
• Requirements for the app – functional and beyond 
• Cooperation model – how are we able to work together and what’s best 
• Operational necessities – how often will we meet? Can the client identify a project owner on their end? Deadlines for project release – when? What’s their ideal project release scenario? 

This is a lot of information to process, and it’s different for everyone. Is your project complicated enough to need a few days or a few hours of project planning? 

Even planning takes planning! Before we sit down, we have to decide a few things: 

• How long should this process take in the client’s particular case? 
• What should we talk about? 
• Who should participate? 

And here comes the most important piece of the puzzle, at least in our experience. But I get the feeling that this is the most important piece of everyone’s puzzle in the cooperation planning stages of their project: participants. 

At this stage, we have usually already invited the PM (Project Manager) to actively participate in the workshop with the client. They actively collect requirement data and determine the most important elements for cooperation with the potential client. 

In a perfect world, it would be ideal to have the whole future team involved with the planning and consulting, but unfortunately, it’s almost impossible to put together a team at this stage. The next best thing is to invite representatives from each stage of the project – like a frontend developer or a DevOps person – in order to give advice and consult different planning stages as needed. They might end up on the project, or they might not – but their expertise is crucial to actual planning. 

Introduction/Client workshop outcome – Project’s Technical Plan 

After all the necessary hours of planning and consulting, we have to have something to show for it. At this point, we haven’t drafted a contract yet, Software development projects are usually long, complicated, and well – expensive. 

Think of this planning stage as an investment – if a software company wants to jump on your project without knowing all the basics (at least!) then they might be getting in over their heads without even realizing it – or worse – you might be jumping on a project with a partner who has no clear strategy for you. Yikes! 

So, what’s the Technical Plan and why should you have one before you start? 

The Technical Plan is born from the workshops that are longer than just a few hours – and more complex. This is basically a recap of all things discussed during the workshops, put together in a clear and concise way. 

“The client workshops provide a crucial role, where both sides decide if the project is a good fit. It’s a bit hard to change your mind after the contract is signed.” – Marek Gajda 

It’s important to keep in mind that these workshops don’t only serve as a stage for hard planning, but a chance to get to know each other on both sides. After all, if you decide to cooperate with anyone on a long-term project, you’re “stuck” with them for a while – it’s a bit like having a roommate. 

Technical plan – a rough draft to help you plan your project and SDLC 

• What is the current working environment – what software does the client have and how does it relate to the current project? 
• What legacy code will we be working with? Does this legacy code affect this project in any way? 
• Project team – who is the project team on your (client) side? Think about providing this info, or at least having it ready: 

• Communication and collaboration process – how/when will you communicate? How will you document communication? What about emergency communication? This includes meetings as well as controlling remote work productivity and progress. 
• Documentation – this includes task documentation as well as reports and QA documentation. 
• Technical stack – a complete list of literally everything in the project. 
• Non – functional requirements – this may include things like currency involved, languages, multitenancy, WCAG (Web Content Accessibility Guidelines).
• Business model – know your project gateway, invoices/ERP, earning model, etc. 
• Testing – where/when/how/why are tests going to be performed? 
• Development process – the big questions – scrum vs. kanban, the definition of done, the definition of ready, team continuity, and other process approaches. 
• Security – technical security, company security, NDAs, and other “people” security.
• Legal – Contracts, licenses intellectual property rights, GDPR, etc.

SDLC step 2 – Start 

At this stage, the team should consist of: 

• A product owner
• Project manager
• Developer
• QA/QAA
• Designer
• DevOps
• Business analyst

Beginnings are beautiful – you have a blank slate, with no mistakes and with everything before you. Time to start the stopwatch – the “Start” part should take no more than a few days. This is also a planning part, but it’s more people-oriented. 

This is where you get all the players into position before the fun begins. 

• Every team member knows what the project is about (client and developer both). 
• Every team member understands their role and feels ownership. 
• Every team member understands the development process. 

The time has come to check the final boxes before actually getting started: 

• The final contract signed
• The final team is in place
• The technical project is approved and signed by the client

This phase is where the big kick-off meeting takes place. This is a sensitive time when the client team and developer team get to know each other and generally speaking, it’s when a lot of time should be spent focusing on the client and their needs. After this initial time is over, most teams go to regular check-ins and scheduled meetings, but these first initial kick-off meetings are better accomplished in person, in a relaxed-pace atmosphere.

At this stage, when the client has any doubts or suggestions about the process, team, or any other issue – they should speak up. This is the best time to resolve any problems or confusion. 

This is also where developers and DevOps prepare staging and production environments. Another important piece of the puzzle is to figure out who is in charge of planning and executing deployments. 

Finally, in this stage, a plan for the repository needs to be created. This can be either on the client’s side or on the developers’ side. If you’re more experienced you already know what you want. If you’re not, it’s a good idea to leave it up to your development team – you can always ask what/why at this stage.

SDLC step 3 – Planning

As if we haven’t planned enough by this point, here comes the actual planning part of the whole SDLC process. Let’s start planning! What can we possibly plan more? Why, the functionality of the software itself, of course!

This is an extremely important stage in the project life cycle. It’s at this point that the team and the client try to refine the functionalities by breaking them down into smaller parts (Epics). In addition to destructuring the process into smaller parts, the PO, together with the rest of the team, determines what the most important aspect is – from a business point of view. 

What priorities should be assigned to particular features of the project? By mixing all of these elements together, we get a roadmap of the project. Initially, this roadmap is going to look like a portrait of the Flying Spaghetti Monster, with time will become a solid foundation for the whole team. 

This roadmap will evolve over time. It will become simplified and flow much better as the process is worked through and refined. Having said that, any changes must be controlled by both the client and the project team.

SDLC step 5 – Implementation

Time to rev your engines and start – this is the part we’ve all been waiting for. It’s probably most peoples’ favorite part because it literally feels like taking that first chip off the piece of marble in order to free the sculpture inside… at least for some developers. 

Everyone knows what to do, the plan has been approved and everybody, including the client, has become familiar with it. Nothing can go wrong now. 

Implementation is the most time-consuming stage of the project. It is during development that the team identifies various risks and takes actions aimed at reducing the damage that may be caused by the arrival of a given risk.  

This kind of unpredictable environment calls for an agile approach. It’s easier to embrace both development and project management in a company with all-channel communication if all team members are fully aware of the current status of the project and its progress. 

Here, the software development process goes through cycles that can be completed quickly and repeated as needed:

• Review
• Testing phase
• Build
• Design

The iterative approach works great here. The project and its momentum are unlikely to be overwhelming if we divide our work into Sprints. They usually last ten working days and achieve the goal in about two weeks. 

Want to know more? Our project manager Marcin Kuśmierz wrote an in-depth article on how to perform an effective daily Scrum. 

What is the product owner’s role in the implementation step? It lies in the Sprint review when the team presents the results of the current iteration. This is the point where the PO can course correct and give feedback before the next Sprint begins. 

SDLC step 6 – Project finish

It’s deployment time! This is what everyone has been waiting for – for months, or sometimes even years. Along with the deployment of the final version of the product, here’s a final checklist:

• The project documentation is given a final check-over and handed in to the client, to be reviewed by the PO. 
• A project summary is usually made – this includes: 
  • Documentation,
  • removing access to development and design tools, Slack channels – a cutting of various umbilical cords,
  • a chance to do a project recap with the client and talk about the whole process.

This finishing stage shouldn’t be rushed, as it gives a great chance to reflect on what went well and what didn’t go so well. This helps both the client and the developer think about what could be improved next time – even if they’re working with completely different teams. 

Now that the project is “done” doesn’t mean that it’s the end of our cooperation. A lot of teams stick around for support. This is where the next stage comes in. 

SDLC step 7 – Support & Maintenance

Apps need maintaining, updating, and generally looking over. That’s a normal part of life. But what happens when something doesn’t go as planned and… that’s normal enough that your dev company should have a plan already in place for it. 

Of course, no one wants or needs these things to happen. But the emergency plan has to be in place, because not having one will make a bigger negative impact on the client’s business than any bug can. 

This all loops back around to the original contract at the very beginning of the project. It’s important to see what kind of support you have written into your contract – it can be something like 9/17, 24/7, or (usually for bigger projects) custom. 

The roadmap to fixing problems may look something like this: 

Other useful resources to wrap your head around the Software Development Life Cycle as a PO

There are a lot of great resources out there to help you understand the role of a project owner in the SDLC. They address some of the most common problems that you will encounter in this role, whether you’re working on an internal project or with an outsourced development team. Some of the most common problems are:

• Lack of ownership in team members
• Bad information flow
• Poor prioritization during sprints
• An overwhelming backlog

In fact, we have written quite a few articles on this ourselves – check them out here: 

Why should you deal with backlog management in software development 

No more fails: what makes a successful IT project? 

Here are 5 questions you should ask yourself when looking for a software development partner

A few tips on improving remote communication culture