Back to resources

Software Development Life Cycle: A Product Guy’s Perspective

Product
Productivity
Team Processes

7 July, 2021

Sarper Horata
Sarper Horata

Product & Project Management Author at Pluralsight

Sarper Horata, Product & Project Management Author at Pluralsight, uncovers how we introduced a proper software development life cycle in a company he was hired in a product role.

Problem

I joined a new company for the first time in a product role. Prior to that, I was working as a developer and had extensive experience in software development. That being said, I knew exactly how the software development life cycle should look like, and what I found at my new company didn’t even remotely resemble it. When the business or internal stakeholders would need something, they would write it down on a post-it note and hand it over to the development team by sticking the note on their monitors. Needless to say, this ad hoc, structureless approach directly impacted output quality.

I immediately voiced my concerns over the lack of planning, quality control, and evaluation. I soon realized that this was not something exclusive for Product but that the whole company operated in the same way. To no surprise, when I managed to successfully implement changes to the software development life cycle in my team, everyone used it as a model for their own teams.

Actions taken

For starters, I was very explicit to internal stakeholders: no more rushing to developers to deliver your requests. They could approach me or use a template I created to write down their requirements, and I would be notified by email at once. From there on, I would make a plan on how to implement this, or I would get back to them explaining why we can’t implement it. I had to protect my developers from any undesired interruption.

Some companies would physically separate developers from the rest of the company to minimize interruption. I even saw a poster at one of the doors saying, “Don’t disturb engineers; they are fearful and fragile like gazelles.” The writing was meant to deter random requests and allow engineers to work on things planned. I was not that strict. I established a certain procedure, but I had to stop people writing or pinging developers personally. Therefore, I instructed developers to ignore any messages unless they were coming from PMs.

Another thing I noticed was that developers were not reporting on their progress. They would write code, deploy it to the repository on Bitbucket and push it to live. We could not see how it was done or if it needed to be tested. I had to implement project tracking asap. I explored some alternatives, and ended up with Jira, which was met with approval from developers. Then I created workflows on Jira and explained how we would organize our work. I would first analyze all the tasks that were submitted and assess if they were worth our effort. If yes, I would prioritize them with also gathering the technical cost from the developers. Once that would be done, developers could start working on tasks, after which two of their peers should do the review. I applied the approach to Design, which proved quite successful too.

That allowed us to say to stakeholders that we implemented a feature they requested, that it is deployed on testing, and we would encourage them to check it out and share their feedback. Some clients, as well as myself, also did some testing, and we made updates accordingly. If everything were okay, we would deploy it to production, and if not, we would submit the task in Jira and remove bugs/work on improvements.

After I introduced the changes, all of the 15 developers I was working with became much happier. Their work was more transparent and of better quality, and upper management had complete visibility into the developers’ work and their progress. It also made it easier for us to report to upper management. In addition, upper management also proposed integrating our processes with a tool that would measure engineering effectiveness. In the end, we were able to use a software development life cycle to calculate the effectiveness of every individual engineer. Also, soon other PMs followed our initiative and replicated it in their teams.

Lessons learned

  • Oftentimes, teams are dispersing their efforts and are much less productive than they could be. I felt that by making those changes, I could increase productivity and output quality. As it turned out, my assumptions were right.
  • Software development life cycle is so fundamental that if that is not functional, nothing else will be. I decided to go straight to the core of the problem, and I was not mistaken. It was a massive change, but with tweaks here and there, I would not be able to create the same effect.
  • The hardest thing I had to deal with was restraining other stakeholders from approaching developers and asking them to build something for them. When people develop their habits, it takes more than introducing some new rules. Moreover, our new processes were somewhat more difficult for them -- they had to fill in a template rather than sticking a post-it note.

Discover Plato

Scale your coaching effort for your engineering and product teams
Develop yourself to become a stronger engineering / product leader


Related stories

The Art of Asking Why: Narrowing the Gap Between Customers and Users

24 May

Jord Sips, Senior Product Manager at Mews, shares his expertise on a common challenge for product managers – finding root causes and solutions.

Customers
Innovation / Experiment
Product
Personal Growth
Leadership
Stakeholders
Users
Jord Sips

Jord Sips

Senior Product Manager at Mews

Managing Remotely: Balancing Team Cohesion and Focus Time

26 May

Jonathan Belcher, Engineering Manager at Curative, explains how to balance team cohesion and individual focus time, tapping into his experiences of working remotely for seven years.

Remote
Micromanagement
Meetings
Internal Communication
Productivity
Psychological Safety
Performance
Jonathan Belcher

Jonathan Belcher

Engineering Manager - Patient Experience at Curative

Streamlining Product Processes After a Reorganization

16 May

Snehal Shaha, Lead Technical Program Manager at Momentive (fka SurveyMonkey), details her short-term technical strategy to unify processes among teams following an acquisition.

Acquisition / Integration
Product Team
Product
Building A Team
Leadership
Internal Communication
Collaboration
Reorganization
Strategy
Team Processes
Cross-Functional Collaboration
Snehal Shaha

Snehal Shaha

Senior EPM/TPM at Apple Inc.

Navigating Disagreements When It Comes to Priorities

9 May

Pavel Safarik, Head of Product at ROI Hunter, shares his insights on how to deal with disagreements about prioritization when building a product.

Innovation / Experiment
Product Team
Product
Dev Processes
Conflict Solving
Internal Communication
Collaboration
Convincing
Strategy
Prioritization
Pavel Safarik

Pavel Safarik

Head of Product at ROI Hunter

The Optimization and Organization of Large Scale Demand

4 May

Kamal Qadri, Senior Manager at FICO, drives the importance of setting expectations when optimizing large-scale requirements.

Managing Expectations
Delegate
Team Processes
Prioritization
Kamal Qadri

Kamal Qadri

Head of Software Quality Assurance at FICO

You're a great engineer.
Become a great engineering leader.

Plato (platohq.com) is the world's biggest mentorship platform for engineering managers & product managers. We've curated a community of mentors who are the tech industry's best engineering & product leaders from companies like Facebook, Lyft, Slack, Airbnb, Gusto, and more.