Full Cycle Development and Developers

Introduction

Organizations are looking for new ways to speed up the delivery of their digital products.

There are new technologies, tools, team structures and methodologies to help with that.

This time, let me address the new trend in developing digital products called full cycle developers or development.

In this article, I’ll be sharing about a couple of things:  what is the rationale behind the new trend, what are its promises, what are the adoption challenges, and what is its future.

The cycle

Cycle means the software development lifecycle or the wider product development lifecycle.

There are different naming conventions depending on the methodology, but usually we identify the following elements:

• Vision – conceptual phase, about business goals and objectives
• Analysis – more detailed analysis of the requirements (who wants what and what particular goals they want to achieve by doing so)
• Design – finding the optimal way to fulfill the requirements using the available technologies
• Implementation – coding, drawing, writing and creating the artifacts
• Testing – validation of the product, if it meets the requirements and is technically correct
• Deployment – from code, configuration files, images, and content to different environments and in particular the production
• Production – running the system, supporting the system and its infrastructure, optimizing the runtime, and responding to errors and small evolutionary change requests

Different methodologies have slightly different definitions and they start to differ when we go into details, but let’s keep it simple for the moment.

The modern methodologies keep on insisting that it’s indeed a cycle.  Small increments of requirements forming the digital solution that go through this cycle and enhance the product, and are delivered frequently to the clients.

Siloes, siloes, siloes everywhere

The trend was to clearly separate the roles, and many managers enjoyed that and enforced that within the teams. Poor managers, unlike effective leaders, like to divide everything . . . work, roles, and skills, but in contrast they measure everything with numbers instead of focusing on how to improve the efficiency of the product development.

The result of this is the creation of visible and invisible siloes, and as a result of the siloes there are bottlenecks and inefficiencies.

It’s really frustrating for me to see how often, even managers who are supposed to know,  people do not understand the difference between the role of the project team and the role of the actual person.

It’s very easy to simply assign one role to one person.

But it looks so organized and clear, how come someone claim it’s not efficient?

Old habits die hard

Developers were told that it’s impossible for them to validate their own work and that they need separate testers to validate their work; and many of them strongly believe so. Even worse, they silently or openly despised testing and playing the role of a tester.

QA was taught to beat the crap out of the system and find as many bugs as possible, and to see the Developers as the source of all the problems, as being lazy, not focused enough, and making simple bugs.

Developers were taught that they are not administrators nor operators. Do not touch the DevOps machine!

DevOps was told to automate the deployment and to not care if what they deploy makes any business sense.

Everyone was told it’s not their business in the end, and they should focus on their own job.

What is their job then? Is it a set of separated individual efforts that’s going to somehow end successfully?

The promise

The idea of full cycle development/developers is to establish and maintain the full ownership of the solution by the team and all its members.

So there’s no external DevOps team, no external QA team, and no external operations team. The team has all the roles and responsibilities within it and everybody cares about each other and the quality of the product.

Because of all the existing prejudices, it is recommended that organizations start with full cycle development teams (different people in different roles) than a more agile full cycle developers approach, which requires developers with very open mindsets and wide skill sets.

The skillset learning effort is usually exaggerated in order to explain the reluctance to go outside individual comfort zones.

The original idea from Netflix is about full cycle developers who can also do the job of other roles. They learn constantly what the other roles are doing so as to be better in those different roles.

→ Read more on how we at Aveenga develop, implement, migrate and provide support on customer relationship management (CRM) software.

The dream of responsiveness is the dream of efficiency

Developers wait for the Analysts or Architects to finish their tasks, while slowing down their current development tasks as they wait.

Testers wait for the Developers to finish their components.

Testers wait for the DevOps team to deploy the new build in the test environment.

The DevOps team waits for the Testers and Developers to finish their jobs to deploy the new release in production.

The waiting game is bad enough, even worse, it can easily turn into a blaming game.

If the Developers can play different roles, for instance they can test and deploy the application themselves, the waiting games and blaming games days are over.

It does not mean that everybody is an expert at everything; this is what the critics say. It means that everybody is open and can (in a limited capacity) play other roles within the team if needed.

And that’s the key to the effectiveness of product development.

→ Read more What happened to NoOps?

Everything as a code → everybody is a developer

The idea of everything as a code helps with that. Everybody is a coder, so they can learn what other types of coders do in their areas, exchange the skills, have more fun in the process, and avoid the boredom and burnout of long product development processes.

Internal cross-training and mob development techniques help team members to learn new skills very quickly using the product as the best example possible.

Looks very promising to me, but there are adoption barriers. Let’s discuss them now.

Adoption

Siloed mindsets

The most difficult thing in organizational changes is the mindset of the people and the ineffective or old habits that always refuse to go away easily.

I can imagine Developers get frustrated with the role of deployment or testing. It depends on the individual person, but (again) the old prejudices and teachings of the past don’t help.

The path

If there are siloed teams, like general QA team for all the apps and general DevOps team for all the DevOps, it’s even further from achieving the idea of full cycle development.

The first step is to go from siloed ultra specialized teams to product teams with all the roles and skill sets onboard. The next giant leap is to create full cycle developers from application Developers, Testers, and DevOps people.

It’s a long journey but there are rewards in the end – better responsiveness and efficiency.

Future

The meta mindset of the organization can either motivate people to achieve ambitious goals -OR- to find the one who failed and put the blame on them.

Treating people like biological cogs in the machine is not an effective way to deliver digital solutions.

The adoption of full cycle development and full cycle developers depends on this meta mindset and organizational culture.

People who are curious about other roles, are happy to learn new things, and like going outside their usual duties. This, plus leadership that encourages them to do so is the key to the successful adoption of this idea.

Would it help your organization? Do you already embrace this idea? Do you consider it as utopia? 

We encourage you to at least give it a thought – it’s worth it.

Roland Guelle – VP of technology at Avenga

The complexity in the IT world has increased enormously in recent years. Experts are needed who really penetrate and understand the different subject areas and solutions. Solutions are everywhere.

But who is identifying the problems that are in the solutions (and experts)?

FullStackDevs have a good general IT knowledge and know the whole stack with a pragmatic approach. They identify the real problems and where experts are needed.

Product mindset instead of project mindset is an important IT trend, which means that not only the creation but also the operation and feedback from users is important. The solution does not end with the completion of the project, but only with its success with the user – and then it probably never ends.

Here comes the full cycle developer. This role today is mandatory when building your digital product.

One of the biggest problems in today’s IT is not to forget the actual problem because of all the solutions.

Solve this issue with team diversity: Full cycle development, architect, pragmatic FullStackDeveloper, experts, perfectionists, etc.