How you structure your digital transformation project from the start has a major influence on its outcome. While working on digital transformation programs with clients, our team has learned many lessons that have evolved into an approach to digital transformation that has been successful for us.
In my last article, I explained our approach and how we organize a transformation project for long-term success. I shared lessons learned and what works best for our team. I also talked about the squad model and the build squad structure.
The composition of those squads is extremely important. You have to include the right roles and make their responsibilities clear. So in this article, I'll describe the roles and responsibilities of the build squad that have been successful for our team. While the list of responsibilities may seem long, I want you to have a full list that you can adapt to your work.
Product owner
Every product has one backlog and one product owner (PO). The PO's responsibilities include:
- Representing the needs of the business (interface), including site performance and reliability (operational excellence) and measuring the success of functionality (analytics).
- Creating and managing user stories.
- Prioritizing the backlog.
- Accepting stories.
- Managing and optimizing business outcomes across relevant business stakeholders.
- Representing the voice of the customer and product profit and loss (P&L).
- Using delivery velocity information to plan and manage the product to its release date by balancing scope and time to achieve target dates. If additional resource capacity is needed, breaking down the business domain into smaller, logical P&Ls to include other POs and squads whose aggregate can deliver higher velocity.
- Providing business knowledge, including market size and segmentation, target customer or user definitions, competitive positioning, industry trends, and so forth.
- Updating and tracking the defects database.
- Interacting with the user experience (UX) team.
Squad lead
The squad lead is a pivotal role. This person acts as an anchor developer and an agile coach in a player/coach role. The squad lead collaborates with development team members and mentors the entire team in best practices. There is one full-time squad lead for every squad. The responsibilities of the squad lead include:
- Having deep hands-on software engineering experience.
- Being an agile expert who leads ceremonies, including Inception, Iteration Planning Meetings, and Standups.
- Assessing and adjusting squad talent to improve quality and velocity.
- Acting as a hands-on senior software developer and experienced DevSecOps consultant.
- Having strong management and communication skills.
- Estimating the level of effort at the squad and microservices levels.
- Being accountable for delivery, including velocity, continuous improvement, practices, and principles.
- Leading the team in evolving agile and technical practices.
- Supporting the product owner in running playbacks.
- Defining squad skill requirements with input from the architect and in conjunction with other squad leads.
- Interviewing and selecting developers and site reliability engineers (SREs).
- Helping to articulate and raise team blockers.
- Identifying and leading strategies for technical interdependencies with other teams, products, or services working with the architect.
- Leading the squad's design and coding decisions; engaging help from architects and UX designers.
- Serving as technical lead to developers and making key technical decisions; being responsible for code quality, test coverage, and adherence to standards.
- Partnering with the PO to lead the squad's work and serving as the definitive technical and process leader.
[ Learn what IT leaders are doing to maintain momentum on digital transformation. Read the HBR research report. ]
Full-stack developers
We've found full-stack developers difficult to source. Most developers are specialized in either front-end or back-end development. We have found that pairing a front-end dev with a back-end dev helps move all developers closer to being full-stack.
There are usually three pairs of full-stack developers on every build squad. The responsibilities of the full-stack developers include:
- Communicating, consulting, and developing high-quality software in a team setting.
- Coding in a microservices architecture.
- Knowing preferred front-end and back-end coding languages.
- Being aware of DevSecOps leading practices in code design.
- Bring familiar with leading security practices in code design.
- Writing production-quality code that meets user story requirements, but not writing code for future requirements.
- Applying leading practices and patterns for design and code; writing code by pairing with other developers.
- Writing automated tests (at all levels of the test pyramid), including unit, functional/integration, and end to end tests, before writing implementation code.
- Adhering to coding standards and architectural decisions, including meeting operational requirements.
- Delivering code using continuous integration (CI).
- Providing production support for the product or offering.
- Minimizing technical debt by aligning development to business value and continuously refactoring code as new stories are fulfilled.
- Articulating and raising blockers in a timely manner to the squad lead and product owner.
- Developing resiliency and depth of expertise across the team through collaborative pairing.
- Learning any new technologies used on the project and working independently to fill skill gaps with the squad lead's recommendations.
- Actively contributing to squad interactions and ceremonies.
- Recognizing the value of continuous improvement and seeking opportunities to improve.
- Assisting with interviews for potential developers.
[ Need to fill skills gaps? Get a trial Red Hat Learning Subscription. ]
Site reliability engineers
The SREs are responsible for the availability, latency, performance, efficiency, change management, monitoring, emergency response, and capacity planning of their service(s). The SRE's focus is on the Ops part of the DevSecOps strategy, whereas the full-stack developers focus on the Dev part.
There is one full-time pair of SREs in every build squad. The SREs' responsibilities include:
- Developing the initial on-call playbook and updating it as the product evolves and features are added, removed, or changed.
- Being accountable for change management on the team and developing actionable plans to minimize outage risks tied to changes by focusing on progressive rollouts, quick and accurate troubleshooting, and efficient and reliable rollback of changes when required.
- Forecasting demand and planning for adequate (optimal) capacity to satisfy natural product usage cycles and any surge demands while not exceeding the team's approved computational budget.
- Ensuring load-shifting is completed as required to address usage variations and scheduled maintenance windows
Who does what?
Each team member has day-to-day duties in addition to the general responsibilities outlined above.
Who does application maintenance, such as production bug fixes?
A build squad stays with the product. Once it completes a product, the squad is responsible for adaptive maintenance and fixing issues. It has one product backlog, and production issues are added to it. The PO prioritizes the squad's work and can move a critical production issue to the top of the backlog.
To ensure developers don't get bored and to expand their experience with other products, they can move from one build squad to another. Be cautious when moving developers, as you can't make wholesale changes without impacting the squad's performance. The build squad might also be responsible for more than one product to ensure members are utilized efficiently.
Who does the ops in DevSecOps?
In many regulated industries, the dev and ops teams are siloed to achieve separation of duties. In some cases, that is necessary. Many of my clients benefit from bringing the dev and ops teams closer together and blurring the boundaries.
One of my clients has build squads push to production. Given a microservices architectural style, being cloud-native, and having implemented several resiliency patterns, the blast radius is contained, should something go wrong. This client also leverages canary deployments, so the number of clients impacted is small. If they need to roll back, blue-green deployments make that a non-event. It also follows the "you build it, you run it" approach, where the build squads are on the pager duty list when things fail in production.
Wrapping up
As with any kind of team for any kind of project, you need to ensure you have the right role composition to perform all the required tasks. Everybody needs to clearly understand their responsibilities and what capability they are expected to provide. It is extremely worthwhile to detail all of the roles and responsibilities and ensure that everyone on the squad is aligned. This way, the squads operate a lot more smoothly and aren't missing any skills necessary to get the job done.
Thanks to Kyle Gene Brown and Dhruv Rajput for their helpful review of this article.
This article is adapted from Launching and Scaling a Transformation Organization and is republished with permission.
About the author
Shahir A. Daya is an IBM Distinguished Engineer and Business Transformation Services Chief Architect in IBM Consulting in Canada, where he is responsible for overall solution design and technical feasibility for client transformation programs. He is an IBM Senior Certified Architect and an Open Group Distinguished Chief/Lead IT Architect with more than twenty-five years at IBM. Shahir has received the prestigious IBM Corporate Award for exceptional technical accomplishments. He has experience with complex high-volume transactional applications and systems integration. Shahir has led teams of practitioners to help IBM and its clients with application architecture for several years. His industry experience includes banking, financial services, and travel & transportation. Shahir focuses on cloud-native architecture and modern SW engineering practices for high performing development teams.
He has supported the design and stand-up of several joint clients and IBM delivery centers adopting modern SW engineering practices to deliver modernization programs. Shahir is also responsible for defining the sectors' technical strategy relating to asset development/harvesting, new technical areas of focus, and thought leadership for the specific technology area. He provides technical oversight and direction on critical projects.
Shahir holds a B.A.Sc. in Computer Engineering from the University of Toronto and has co-authored 3 IBM Redbooks on Microservices and Hybrid Cloud Integration. He is an inventor with several issued U.S. Patents. Shahir is a member of the Institute of Electrical and Electronics Engineers (IEEE) and the Association for Computing Machinery (ACM). Shahir is an active mentor in the University of Toronto Engineering Alumni Mentorship Program and the University of Toronto Women in Science and Engineering (WISE) Mentorship Program. He is also a coach for the FIRST LEGO Robotics Jr. League.
You can follow Shahir on Twitter and Medium.
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit