The great shift left - understanding the cognitive load of making single title engineering teams own everything
There is a great shift left movement in software engineering that is in some ways the natural outcome of the Agile movement. Everyone wants to push more power and responsibility onto engineering teams removing roadblocks and shortening cycle time for making changes and creating products. This increases the number of tasks and cognitive load on those teams as a tradeoff for shorter cycle times and other concerns.
The idea is that you push ownership of every facet of a product to the lowest level possible. People often use Amazon AWS as an example of success in this area. Originally shift-left was primarily an engineering function where you pushed all of the technical responsibilities to a single team. The team creates better products because they own the entire lifecycle and any of the cycle times. Organizations have eliminated adjunct positions creating a staff single developer type that owns the previous test, DevOps, CI/CD, data, and all development disciplines. There can be multiple skills or ranks but everyone is a developer. This has been very successful for a set of scenarios.
Some organizations have taken the next step pushing semi-technical and non-technical roles onto the development machines. Business and Technical analysts and other product or business-related positions are eliminated and replaced with additional engineers.
Help me find the missing responsibilities. I'm open to suggestions.
This is explained in the video. Additional content may be added here in the future.
Click here to expand
Click to expand
Doing Everything - All The Time
What exactly are we asking of the software or other engineers? People talk about shift-left and collapsing the workflow but what type of engineers do you need? How do we expect them to organize?
This chart tries to give a feel for the range of capabilities we expect from the engineering teams. Engineering teams own these responsibilities and must have these skills and build tooling relating to the items in this diagram.
I'm happy to update or clarify this chart if people find errors or think of missing items. I suspect most of the feedback will be around missing responsibilities.
Click on the diagram to see a larger view or scroll down
Bubbles are all sized the same for appearances and do not imply that the items are of similar effort and complexity!
Teams and Org Collapse
Shift-left means eliminating or reducing support teams. Some of this is made easier by moving to the cloud and cloud automation because the cloud can make some skills less mandatory. Companies see this type of team reassignment or elimination in these "move left" efforts.
| Old Team | New Team |
|---|---|
| Development | Development |
| Shared Services | Development |
| Analysis | Development |
| DevOps | Development |
| Testing | Development |
| Data | Development |
| Operations | Development |
Roles Collapse
Shift left often means the elimination of a wide range of titles and specialist positions. They are replaced with the general role of developer. Here we have an example list of roles that could be collapsed into the Developer role on Delivery or Stream-aligned teams. This is the purist view of how this works.
| Old Role | New Owner |
|---|---|
| Developer | Developer |
| User Experience | Developer |
| Business Analyst | Developer |
| System Analyst | Developer |
| DBA | Developer |
| Data Designer | Developer |
| Tester | Developer |
| DevOps | Developer |
| CI/CD | Developer |
| Infrastructure Triage | Developer |
| Tier 1 Support | Developer |
| Security | Developer |
The reality is that there will need to be specialization because everyone can't be great at everything. Each of these roles may now be represented by a primary and a secondary but they cease to exist as a standalone. Teams have to operate this way because the average SCRUM or other team is probably 8 people or less. You can't afford to have half the team as specialists that don't contribute to the main line code base or development process.
Video
This topic is covered in this YouTube Video!
Process
This group represents the work done to synchronize inside the value stream or with a program or product workstream of multiple teams and with the work done to support a manageable and clear backlog.
This is explained in the video. Additional content may be added here in the future.
Outward Facing
This group contains the tasks done to synchronize with external teams. This is the entire lifecycle from initiating conversations, reaching interaction agreements, negotiating interactions, and troubleshooting difficulties in the development and integration process.
Pre-Construction
This group contains the tasks and responsibilities required to define the work required, reach decisions, capture non-functional requirements, and define how systems our subsystems will be built. This is the high-value part of the technical process that must be done well to build a robust system that meets regulatory requirements and protects the customer and enterprise.
This is explained in the video. Additional content may be added here in the future.
Construction
This section contains the skills or work areas when actually building software. The testing here is the most inside the development portion that is tightly integrated with the development process. Some things here are actual tasks. Others are required skills that may stretch a person's capabilities or may not be possible for one person.
This is explained in the video. Additional content may be added here in the future.
Quality
This section describes a lot of the quality assurance tasks and capabilities that the development team owns when in a You Build it You Own Everything About pattern. The engineering team owns all testing and all quality analysis functions. Most of these tasks must happen every sprint in a truly agile / SAFe shop.
Click on the image to expand
This is explained in the video. Additional content may be added here in the future.
Operational Excellence
This area is a bit of a dumping group of the skills and tasks required to create a maintainable and supportable system where the company knows what is actually happening. They don't feel related but they can all impact operational excellence.
This is explained in the video. Additional content may be added here in the future.
Less than Excellent
The flip side of operational excellence is the problem resolution, triage, and fixing processes and responsibilities. These are in some ways all after-the-fact actions taken to remedy problems that got through quality or where other systems caught issues or requirements weren't known.
Things like "fail forward" overlap this area and others above.
This is explained in the video. Additional content may be added here in the future.
Continuous Everything and Everything as Code
This area has been a major focus of agile and the drive for automation. Teams and companies can only move faster if they can reduce cycle time and increase reliability in the assembly, test, and deployment functions. Teams now own these tasks as the staff in supporting roles is reduced.
This is explained in the video. Additional content may be added here in the future.
Compliance Governance Security
Software and technical products must meet internal and regulatory guidelines. The development team must implement those guidelines and policies in order to create a secure and correct system. Some of these boxes need to be re-labeled but they give a general idea of the scope.
This is explained in the video. Additional content may be added here in the future.
Corporate
This area represents the general overhead of being an employee and all that entails. It represents some percentage of time that does not directly apply to business or technical deliverables.
This is explained in the video. Additional content may be added here in the future.
References
to be added
Revision History
Created 2023 01
Comments
Post a Comment