In this blog we’ll address the historical evolution of the modern Agile software development team as a true collective that supercedes its individual members as well as breaking down many of the roles that make up that team.
From mobile and web apps to embedded software our cars and robot vacuums need to work, the contemporary world runs on software. The vast majority of those millions of pieces of software are not created by not a single programmer working alone but a software development team consisting of a variety of different roles, tech stacks and competencies (hard & soft).
The construction of a building involves a team of different competencies and skills. An architect, a structural engineer, a foreman (or woman), construction workers with various skillsets, electricians, plumbers, interior designers and decorators etc.
There are many parallels with modern software development. Software systems and products have developed in their complexity and sophistication over the years, with the advent of cloud computing a major inflexion point. In parallel, the tech stack represented by software development teams and methodologies and frameworks used in their effective management has also evolved.
The average software system represents a combination of front end, back, testing tools operations tools and technologies as well as UI and UX expertise and design. As such, the members of a software development team tasked to build a software system have to represent experience and competence across that diverse range of tools and technologies.
Every member of the team must also be willing and able to embrace and work effectively to the, usually Agile, methodology or framework selected to best organise and encourage their work. And to maintain the balance between quality and velocity, while stretching expectations of both.
The importance of methodology to the contemporary software development team
The mainstream adoption of Agile software development methodologies and frameworks over the past twenty years or so has placed a new emphasis on the software development team. The culture and practices of the team prescribed by Agile approach are designed to simultaneously tighten team relationships and empower individual members through responsibility and accountability.
The software development team is no longer a collection of individuals, each executing their assigned chunks of a software system before handing them over to the project manager or testing team and then walking away. The team, not just the project manager or technical lead, is collectively responsible for the quality of its output and each member is expected to take personal responsibility for that team goal.
Agile and DevOps methodologies have placed the software development team front and centre. Their principles and practices are designed to help a team becomes more than the sum of its parts. Like a well-coached and motivated sports team reaching heights beyond those achievable by less well-orchestrated rivals, even if they boast more impressive individuals.
The evolution of Agile and DevOps software development teams
Design thinking systems have been influential in attempts to improve the efficiency of production processes and the quality of their output since the 1940s. These systems, like The Toyota Way or Lean methodology as it became better known, were first used in manufacturing but also began to inform software development processes as the digital transformation got underway in earnest in the 1990s.
Several influential books and papers arguing for and outlining iterative rather than linear approaches to software development that became or influenced the various frameworks under the umbrella of Agile software development had been published in the 1980s. They addressed the growing problem of increasingly large and complex software development projects taking so long to build they were obsolete by the time they were released.
Those software systems that did still serve a purpose were often plagued by serious deficiencies in usability and functionality design. Their size made their design and development an unwieldy, difficult to coordinate process and quality suffered.
At the time, most software systems, large or small, complex and simple, were developed to the linear Waterfall methodology. Each stage, from detailing requirements to design, development, testing and release, was completed one after the other with only a little overlap.
A sprawling, hugely complex software system, such as for the military or government departments, hospitals etc., would be designed in its entirety and to the smallest detail at the beginning of the development life cycle.
Software developers would then create the code to realise the detailed specification provided. Each was mainly responsible for their own designated chunks of the total software system allocated by a project manager and wouldn’t necessarily have much work that overlapped with other team members.
As software development projects grew in scope and complexity it would often take years for them to be completed from start to finish. That meant a huge amount of pressure was put on the planning stage to get things right. If 2,3 or 5 years later it turned out there had been mistaken assumptions, going back and making changes was difficult.
An increasing number of influential thinkers in the software development space started to argue that linearly developing software systems wasn’t the optimal approach. And that for those above a certain size it simply doesn’t work. The connection was made to one of the main strategies employed in the Lean optimisation of manufacturing processes – limiting the amount of work in progress (WIP).
The alternatives championed were iterative approaches to software development that prescribed first boiling a project down to its bare bones – the smallest, simplest package of core functionalities still enough to provide value to the software’s users. Once released work would begin on the next iteration, involving fixes and improvements based on user feedback, and adding new features and functionalities.
These Agile software development methodologies and frameworks now dominate the sector. As well as prescribing the practices and processes a software development life cycle consists of, they also inform the roles and responsibilities that make up a software development team.
How DevOps extended and improved the Agile software development team
DevOps and continuous delivery (CI) extend the team into IT operations (mainly through the introduction of automation). A DevOps team helps avoid the common issue of the development team handing what they consider a working iteration on a software system over to a separate operations team. And the operations team then struggling to get it to run in the same way in the production environment because it isn’t exactly the same as the development environment.
In a DevOps team, the whole team, development and operations roles, is responsible for how a software system runs in production. Developers and DevOps engineers have to work together to ensure new iterations on a software system run the same way in production as in staging.
Breaking down the silos between development and operations roles through a DevOps team approach has been shown to support and amplify agility, responsiveness, and faster time to market throughout the software delivery lifecycle.
Roles and responsibilities within a software development team can differ slightly and have different titles depending on the Agile/DevOps methodology or framework adopted by a software development team. The core ‘software developer’ role can also come in a variety of flavours of seniority and extent of specialisation in a particular technology or coding language.
Agile and DevOps software development team roles
As the most common Agile methodology contemporary software development teams are built for and work to it makes sense to start with Scrum team roles.
A Scrum development team has three core roles defined:
- Product Owner
- Scrum Master
- The Development Team
The development team is further broken down into specialisations including:
- Front-end Developers
- Backend Developers
- Dev-Ops Engineers
- QA & Testing Experts,
- Business Analyst,
- Database Administrator or Engineer
However, in Scrum, all of these roles are referred to as Developers. The Development Team should also not have sub-teams defined within it like the testing team, requirement specification team etc. This is to avoid hierarchies within a software development team and foster a culture of collective responsibility.
Scrum team overview
A Scrum software development team’s roles and responsibilities are designed for self-organisation, which means it decides on the best way to complete its work internally, within the Scrum framework. It should also be a cross-functional team that represents all the skills needed to realise the software system it has been tasked to develop without the need to bring in outside help.
It is recommended that a Scrum team should consist of between 3 and 9 development team members plus the Product Owner and Scrum Master. Especially in smaller project, the role of Scrum Master can be taken on by an experienced developer in addition to their development team role and responsibilities.
Larger projects that necessitate more specialists working on them are broken down into chunks allocated to different teams. Dependencies between software developments teams working on the same software system are managed through scaled Scrum frameworks like Scrum of Scrums.
Scrum team roles
The two unique software development team roles prescribed by the Scrum Agile methodology are, as already mentioned, the Product Owner and Scrum Master.
Product Owner
An Agile software development team is all about joint responsibility and a flat structure. But as a decision-maker at the macro level, the Product Owner in a Scrum team does shoulder the most responsibility for a software product’s quality. The role is to balance business needs with market trends to define a business strategy and product vision that will satisfy user needs.
The Product Owner must make prioritisation decisions on the product backlog and determine when market changes or customer feedback should change requirements and workflows.
The role of Product Owner in a Scrum team has plenty of cross-over with the responsibilities of the Business Analyst role in alternative software development team structures. The main difference is a Business Analyst role usually puts more emphasis on the technical implementation of the vision while a Product Owner is more customer focussed.
Scrum Master
The Scrum Master role is most often an additional set of responsibilities taken on by either a member of the development team or sometimes a project manager. The Scrum Master is responsible for making sure workflow is organised within the Scrum framework and the team sticks to its rules and processes and generally adopt an ‘Agile mindset’.
One of the most important element of the Scrum Master role is removing impediments to the work of the software development team by making sure they have what they need, when they need it.
There is cross-over between the Scrum Master and traditional Project Manager roles but also important differences. A Scrum Master’s priority is the team itself and following the Scrum framework while a Project Manager works at a higher level of abstraction. Their priority is more about distributing the resources and logistics necessary for a project to work like risk management, contract management and budgeting. A project manager doesn’t necessarily even need to know much about the actual product being developed.
Most Agile software development frameworks include the Product Owner and Scrum Master roles or roughly comparable equivalents. The Extreme Programming (XP) framework, for example, defines the roles:
- Customer
- Manager
- Coach
The Customer role is something like a cross between a Scrum Product Owner and Business Analyst. An XP Manager takes on some of the responsibilities that would normally be associated with a project manager and others more like a Scrum Master’s. The XP Coach has a lot of similarities to the Scrum Master role and is responsible for team culture and that the methodology’s practices and rules are being kept.
Development team tech stacks and specialisations
Outside of these specialist roles, the bulk of a software development team is of course made up of the IT specialists that technically design, code, build, test and run a software system. While most Agile software development team structures don’t define different technical skillsets and tech stacks as ‘roles’, it is worth mentioning the main categories of ‘developer’ as defined by tech stack and areas of responsibility.
Software architect
A software architect is almost always a senior, usually full-stack, software developer with enough breadth and depth of knowledge to make good decisions. Based on the software requirements provided by the Product Owner or Business Analysts, the architect will, like a construction architect, create diagrams and documentation that define how the final solution will be practically achieved in line with business requirements. The architect is responsible for high-level design decisions and the framing of technical standards including tools and platforms to be used and software coding standards.
Tech Lead
The software architect can also, though not always, be the software development team’s technical lead. Like an architect, the Tech Lead is focused on the technical aspects, or the “How” of realising the requirements. But the Tech Lead is much more involved in the actual development process and uniting the team towards a common technical vision.
While each developer is responsible for the quality of their output and in supporting the quality of their colleagues’ output where possible, the Tech Lead is accountable for the quality of the whole team’s technical deliverables.
Front End Developer
A front end developer is responsible for coding the user-facing side of a software system – everything that is seen and interacted with by a normal user. They are usually experienced in one or more front-end programming languages like HTML, PHP and JavaScript or its popular frameworks and libraries like React, Angular and Vue.js. Or mobile-first and native languages and frameworks like Flutter, React Native, Ionic, Java, Kotlin or Swift (iOS).
Back End Developer
A back end developer is responsible for building all the parts of a software system the user doesn’t see and interact with but allows everything on the front end to work. If we return to the construction metaphor, the back end of a software system is the equivalent of the foundations, plumbing, electrics, gas installations etc. in a house. None of it’s usually visible but its smooth, effective functioning goes a long way to determining the quality of the living experience the house provides.
Popular coding languages used in back end development include Python, Ruby, PHP, Node.js and Golang. The most popular backend frameworks used in mobile app development are Django, Ruby on Rails, Express/Koa/Sails for Node.js and the Google-developed BaaS (Backend as a Service) tool Firebase.
Full Stack Developer
A full stack developer has expertise and experience in front and back end coding languages and technologies and experience building both the front and back ends of software systems. Most developers evolve into full stack developers as they gain experience and seniority and learn new skills as their career developers.
As a role in a software development team, a full stack developer will take responsibility for or contribute towards both front and back end tasks from the product backlog.
In any given software development team, a nominally full stack developer may work as a purely front end developer, or only on back end backlog tasks, or both. And in an Agile software development team the original plan might change with requirements and see a developer originally earmarked to contribute to the front end pick up back end tasks, if their stack allows.
The range of skills and experience represented by full and fuller stack developers can offer invaluable flexibility within their development team. Out in the wild, it is rare to find a senior developer who is not full stack and purely has front end or back end skills. Reaching senior level is typically only possible through building up a T-shaped or Comb-shaped tech stack.
UX Designer
A UX (user experience) designer is responsible for making a software system as intuitively usable as possible. They create user personas and scenarios and use those to inform the layout of individual screens of an application as well as the flow of information across the site.
They’ll design wireframes and prototypes that show the layout and ‘feel’ of a software system from the point of view of a user. If you’ve ever felt irritated because a favourite app has been updated and no longer works in the same way it did, or elements have changed, but the functionality and features are the same as they were, that’s the result of a UX design update. Often given a little time to get used to the new layout or navigation we find it is actually an improvement on what we initially missed.
UI Designer
The UX designer is responsible for the layout and user journeys within a software system and the UI designer creates its visual feel – how it looks and and how the user interacts with it. The UI designer will choose the design style, usually within the framework of style guidelines which are often company-wide. In smaller or younger organisations, the UI designer might also be responsible for developing branding and style guidelines.
While UX and UI design involve different skill sets some UX and UI designers have expertise across both roles and can combine them.
DevOps Engineer
The role and responsibilities of DevOps engineer can vary between software development teams. But broadly speaking, a DevOps engineer is responsible for the integration of DevOps processes, tools and methodologies throughout the software development life cycle with an emphasis on test suite automation and CI/CD tooling. Their work is designed to facilitate cooperation and teamwork between development and operations teams.
DevOps engineers are typically responsible for release engineering, provisioning and maintenance of infrastructure, system administration and security and can come from a development background or an operations background. The emphasis of their role in a particular software development team will usually be determined by that background. A DevOps specialist with a development background will be more focused on automation and instilling a DevOps culture and processes within the team. A DevOps specialist with a systems admin background would be expected to take on more of an operations role.
Quality Assurance (QA) Engineer
QA engineers or specialists are often confused with software testers but there are meaningful differences between the two roles. Quality Assurance is process oriented and ensures the processes used to manage and create deliverables work to prevent defects. A QA engineer uses audits and metrics as tools to monitor these processes.
QAs work out and integrate methods, often based on DevOps automation, to prevent bugs from appearing in a software system and that code produced by developers meets set standards.
Testing Engineer
A testing engineer is responsible for Quality Control (QC) rather than QA. While QA is process oriented, QC is product oriented – the processes and tools designed to uncover bugs, poor usability and other defects. A testing engineer’s responsibility is to find any defects in a software system that have made it through QA processes and tools.
A testing engineer role is mainly focused on setting up automated testing systems. Usually manual testers are also brought in to methodically work their way through user stories (usually to a system designed by a testing engineer or senior manual tester) and find any bugs or other issues missed by automated testing.
As software systems become increasingly sophisticated, the role of the ‘software development team’ as the foundation of their success or failure, rather than the performance of individual members of that team, becomes more pronounced.
It’s no coincidence Scrum was named in honour of a rugby scrum. The Agile methodology was one of the first to put the joint output of the collective as more than the sum of its parts at the heart of the software development process. It’s a philosophy and culture that now underpins almost every successful software development project of any scale.
