Join the 85,000 open source advocates who receive our giveaway alerts and article roundups.
The Small Scale Agile Manifesto
The Small Scale Agile Manifesto
These six values enhance agile methodologies to help smaller teams work more efficiently.
Get the newsletter
The “Agile Manifesto” is an umbrella term that describes and governs several lightweight and fuller agile methodologies for handling IT teams and projects. Scrum, Kanban, Lean Development, Crystal, and Extreme Programming (XP) are among the most popular and lightweight agile approaches.
While Small Scale Scrum fits into the Agile Manifesto, six of its additional values, described below, should complement and enhance agile for smaller teams.
Wide communication over narrow communication
Maintaining narrow communication with a project’s manager is essential, but wider communication offers more value. Wider communication includes all of a team’s stakeholders, including the product owner, ScrumMaster, and all team members. Excellence through the application of best principles in every team-to-team or team-to-customer communication is very important. Therefore, team members are encouraged to take time to prepare before meetings to best accommodate changes and ensure productive outcomes. Regularly using the team’s preferred communication channels quickly and effectively creates a welcoming environment.
Team feature delivery over individual responsibility
An individual team member’s responsibility for delivering single features is considered standard practice in software projects. Members of small teams, however, are expected to have much broader involvement in the project lifecycle, so they need to take mutual responsibility for delivering work items. In this approach, teamwork plays an important role, with team members working together as a single unit to ensure the project’s success from the bottom up.
This can be achieved with techniques including support for remote team members, fair workload, pair programming, code review, and shadowing. Remote team members work towards the common goal but are not geographically co-located; fair workload is to ensure that the team’s workload is divided fairly; pair programming is focused on writing and reviewing source code together in real time; code review, also known as peer review, is focused on viewing and reading source code after or as an interruption of implementation; shadowing is on-the-job learning and is commonly used for in-house training.
Quality delivery over speed of development
Rapid development and high-quality delivery are expectations in every customer engagement. While the speed of development is important, quality delivery has a much greater impact on the project’s continuous success. Investing time in quality development and testing by using quality-assurance techniques, tools, mentoring, and training can help the team continuously excel.
Multiple project responsibilities over fixed assignment
Fixed project responsibility where team members typically have one role, with the overall team containing enough skills to be self-sufficient for the roles to be filled, is a standard practice in agile, but the real value for small-scale teams comes from members taking additional roles (within reason). For example, an engineer may become the front-end developer, back-end developer, quality engineer, or user interface (UI) designer.
The idea behind this approach is to ensure that the small team is as self-sufficient as possible. For small teams to adopt multiple responsibilities, the workload must be fair and the project’s processes must be streamlined. This can be achieved by continuously reviewing and improving work conditions and simplifying processes to help the team focus on delivery. Coaching should be offered to give team members guidelines to help them improve their skills.
Accelerating innovation over marginal request-driven thinking
Request-driven thinking where specific business requests are followed strictly, is important in enterprise engagements, but innovation is what customers value the most. In such engagements, the customer is the only stakeholder, and their view and voice are followed to the letter. Planting innovation is critical to get the team and customers to think outside the project’s defined requirements so they can envision the final solution with the most creative and optimal architectures, requirements, and designs.
Customer growth over customer engagement
A successful customer engagement is very important to a project, but it’s not sufficient for building and maintaining a strong and successful relationship with the customer. For small teams, it’s important to approach business engagement from the customer’s business-success perspective. Growth or creation of business is the customer’s highest priority for a software solution; therefore, it should be the team’s highest priority.
A version of this article was originally published on Medium and is republished with permission.