Combined Engineering – a new perspective in agile execution

In a typical software product lifecycle, people with multiple roles and different skills are involved. The development of the product involves UI/middle tier/DB developers, testers, build/ops, project/program manager and the likes. They all have a different vision about product goals (things to achieve, quality, roadmap). Due to a lack of a unified vision (and lack of collaboration across people in different roles), projects often fail to meet the desired schedule and quality.

Realizing this, many product companies have started taking proactive steps to tackle this problem and are gradually shifting to combined engineering.

What is combined engineering?

Automation is one of the pillars of modern agile. It is a crucial element for quality delivery of short agile cycles. Automation may include unit test automation, UI/MT functional test automation and build automation (continuous integration). Effectively this means, you have to write code for everything. What if you treat people in most of the roles as developers? Yes, that’s the interesting idea that combined engineering suggests.

It includes that:

• The same developer should be multi-skilledto write development code for UI or MT or DB, UI/MT test automation code and build script automation code, among other tasks. Ultimately, everything is code!
• At the end of every sprint, automated testsare run at each level to ensure the desired functional/non-functional coverage.
• Developer rotates his role in the next sprint. For eg, in one sprint he learns and focuses on writing code for UI automation. In the next sprint, he writes/updates build scripts and so on.
• We move away from specialized roles like testers and build engineers. Everyone works under the same title - Developer.

Remember that the specific role does not really go away. Someone still has to do testing (may be through writing effective automation tests and executing them manually/automatically). However, the role is now shared across multi-skilled developers.

Another thing worth noting is that the recent concept of DevOps also falls under the model of combined engineering where the roles of Development and Operations teams (post production support) are combined.

Benefits of Combined Engineering:

• Set of multi-skilledresources with knowledge on multiple areas. There are no concentrated ownerships (like UI developer, MT developer build deployment person or tester providing sign-off) and no person dependencies.
• Team members are well aware of the product goals, corresponding architecture/designand dependencies between each other.
• Resources can better understand the challenges in various areas (in development, automation, build) and can help each other to meet sprint goals.
• Flexibilityof task allocation in a sprint or during the sprint. The inefficiencies and dependencies are resolved quickly. This also improves the quality and team velocity.

Limitations:

This is a paradigm shift in the way developers think and work. Owing to this, you can expect initial resistance. A developer may not be ready to write automation as it is ‘not his work’ while a tester may not want to upgrade his/her skill as a developer. Moreover, things are not limited to coding alone. For instance, a developer should be able to think like a tester (in terms of coverage of functionality) which is an implicit expectation, but in the combined engineering model, this is a must. There are no separate testers in combined engineering.

You also need to check the level to which you can combine roles. Clearly, PM and developer roles cannot combine. Also there might be multiple roles which are not mentioned above, such as performance/scale tester and operations roles. These roles cannot be combined as this will result in heavy-duty work for developers. However, you should encourage your team to make a slow start and at least combine similar developer roles such UI/MT/DB developers and testers.