People are the workforce to build everything we know, software included. A software development team is in charge of every existing software. From the tiniest piece of code to the most complex systems. Software development teams need some kind of management and exact team structure, like the development process itself. There are several development methodologies and development life cycle variations (even for processes not related to software).
In this article, we will talk about the agile methodology team structure including the most important software development team roles.
The development process
Before talking about agile methodology specifically, let’s explore the development life cycle first.
Software Development Life Cycle
Development life cycle concept could be used in every process that is supposed to lead to a final product. It gives order to the chaos that could be a development process. Every business needs a certain level of order to maintain its operation during the development and even after releasing the final product. We can mention Henry Ford, who invented the assembly line for his car factories. The assembly line enhanced the process of producing a car from taking more than 12 hours, to 1 hour and 33 minutes. The modern “assembly lines” are different (and more efficient) nowadays, but Henry Ford established the first steps for improved development life cycles and more effective production lines.
In software development, production lines are not so different from creating something tangible like a car or a toy. There’s a product that must be planned, designed, built, and released.
Development Methodologies
After some preliminary steps for the project to get on trail, we start with the process itself. We’ve got the product idea, the people, the needed budget, everything necessary to start. Depending on the methodology, the initial steps of project conception can be part of the process, like iterative methods like RUP (Rational Unified Process). Also, the software development team structure is crucial. Some of the methodologies specify the software development organizational structure, assigning different roles and purposes to the people involved in the project development.
Iterative methodologies (also called iterative and incremental development approaches) try to break the project into smaller parts, making it easier to manage and to avoid inherent project risks (meaning that every completed part of the project is theoricaly isolated).
The word iterative implies the execution of repeated established cycles and at the end of every cycle, there is a final result, a new version of a product to be released. Every cycle produces an increment, until the project is finished.
There are several more methodologies to talk about (like Waterfall and Rapid Development), but most of them are rigid for the software development industry. Practice has demonstrated that they are not practical due to their stiffness to changes and their heavy reliance on initial documentation.
One of the strongest features of agile methodologies is its flexibility, completely the opposite of the traditional method. As the industry of digital products changes rapidly, being flexible and quickly responding to emerging changes is a must. This is why Agile for software development is a perfect fit. That’s why old and traditional methodologies have been replaced (or mixed with) by more flexible methodologies.
Agile
Moving from rigid to flexible methodologies was the spark needed by companies and developers. The new methodologies directly address the problems of approaches that were before.
Agile software development (often called just Agile), is a set of practices that promote teams to evaluate requirements and objectives constantly, including discovering new requirements and improving solutions, often through cross-functional teams where client and development team are constantly on communication. These practices provide flexible responses to changes and a good understanding of the problems to be solved. Agile best practices are fully described in The Agile Manifesto.
We can’t talk about Agile without mentioning their most famous software development frameworks Scrum and Kanban. In fact, Scrum and Kanban inspired The Agile Manifesto.
Note: Why framework and not methodology? The definitions don’t seem far from each other, that’s why it is a bit difficult to differentiate them. Methodology is a system of methods used in a particular activity. A framework is the basic structure of something. Following a methodology is just using the methods that it provides, not specifying how, when or by who. A framework describes specifically who should participate, how, why and when. A framework encourages the users to follow it to the letter.
Scrum
To talk about Agile is almost a synonym of talking about Scrum (or mostly any Kanban variation). Now that we’ve described pretty much the basis of development methodologies, now is the time for describing Scrum and how to build an agile software development team according to this framework.
Scrum is a framework for managing design, development, and maintenance processes, including evaluating requirements and objectives constantly, continuously delivering different kinds of increments to the project. Scrum teams break their work to smaller goals to be completed within time-boxed iterations, called sprints. The length of a sprint can be just one week or an entire month, being two week the most common sprint duration. The sprint duration can change during the process if it’s convenient.
To report progress, the agile team performs time-boxed daily meetings of 15 minutes or less, called daily scrums. These daily scrums are for reporting progress in the task being worked within the sprint, also for reporting problems and calling for help (Scrum encourages teamwork and collaboration by continuously assessing progress).
At the end of the sprint, two meetings are performed: sprint review and sprint retrospective. The first one is to show the resulting increment of the sprint to the stakeholders. The second one is to evaluate the sprint’s performance, which enables the team to reflect and improve.
This is only an overview of Scrum definitions. There are plenty of concepts that we didn’t mention like a step by step workflow or Scrum artifacts – you can read about them in detail by following the link.
Further we are going to focus on the Agile team structure and the team members: the people involved in the process ( stakeholders, Scrum master, developers) and their exact role in the process.
The Agile team structure
First we need to know what a Scrum team structure has to look like. Usually, a Scrum team is small so it can be more manageable.
There are three essential roles in a Scrum software development team structure:
- Product Owner: As its name suggests, is the “owner” of the product being developed, the main decision maker of the agile software development process, the one that cares for the interest of the stakeholders. It sets the expectations of the result of the development process (and its iterations). It can be part of the development team itself or a representative of the stakeholders. The way that this role is performed varies widely across organizations.
- Scrum Master: In short, this is the person that has as objective the accomplishment of the Scrum framework to the letter. It takes care of the process every iteration, being sort of an intermediary between product owner and developers. It helps both the Scrum team and the organization to adhere to Scrum. Also, it accounts for the team’s effectiveness, by using the Scrum framework to improve. The Scrum master role can be assigned to any of the Agile team members with respective experience and knowledge.
- Developers: Basically, the ones who build the product. The developer role in Agile is clear: individuals are in charge of executing the necessary work to accomplish the objectives of every sprint. This covers any profession that’s required to create an increment: programmers, designers, engineers, or QA personnel, etc.
Note that the Scrum framework initially doesn’t mention anything about software. This is because its application is not limited to software development. Nowadays, like we mentioned before with development methodologies, it’s used widely in other development processes for different kinds of products.
Hiring the People
Now that we know the roles, we can finally describe how to create a Scrum team in terms of software development. Depending on which would be your role, you’d just have to hire new people for your team roles you are missing.
The Developers
Let’s say that you’re the senior developer on a project and you need to build a Scrum team. If the project is already in development, there are probably people you can involve in your Scrum team. But if you are building Agile team from scratch, you have to hire your developers first. Remember that your team must not be bigger than 15 people IN TOTAL, meaning that you should only hire 10 to 12 developers, so choose wisely the people with the right aptitudes for the project.
The Product Owner
After you’ve got your developers, a product owner should be designated. It could be you, if you own the product idea or are in constant communication with the client, or it could be someone designated by the client. The product owner is a role that is pretty dynamic. The point is to have someone that talks to both the developers and the stakeholders and reach agreements between what must be done and what can be done. Who is going to take the role and how is going to do its work is up to you and the project’s requirements.
The Scrum Master
Now you should fill the Scrum master position. Maybe this is the most important role (at least at the beginning), since this person is here to kickstart and organize the work of the whole team. Both developers and the product owner are not necessarily Scrum professionals, so one of the tasks of the Scrum master is to help the entire team to understand the Agile approach. Then, another of its tasks is to accomplish Agile to the letter. He is the one that schedules and moderates the respective meetings. This role should be designated to someone that knows Scrum inside out and has already accomplished a few projects in this framework.
Some organizations have taken the Scrum master role and changed the way it is set. By the book, the role of Scrum master must exist and it should always be the same person. But there are certain organizations that like to switch the person in charge on a regular basis. However, if the role is not permanent, Scrum must be applied to perfection, otherwise problems may occur. If you are not sure whether you can achieve this in your Agile team, Scrum master role should not be rotated.
The only thing that remains to say is how to build an agile team if you don’t have people on hand. In that case, you should consider checking job portals like LinkedIn, Indeed, or crossover. There’s quite good programmers (and even dedicated scrum masters) that are open to new jobs. Also, there are freelance platforms like freelancer, Fiverr, Upwork, Envato, etc.
Another option is to outsource the project to a software development company, where they’re ready with all the tools and professionals needed to carry out the project.
Check out all the software testing webinars and eBooks here on EuroSTARHuddle.com
