The Small Scale Agile Manifesto

These six values enhance agile methodologies to help smaller teams work more efficiently.
146 readers like this.
gears and lightbulb to represent innovation

Opensource.com

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.

Download the Introduction to Small Scale Scrum guide

What to read next
Tags
Avatar
Agnieszka is an Associate Consultant working for Red Hat App Dev Center of Excellence and developing software solutions for customers in small 1-3 person Agile teams. She spent a year researching Small Scale Scrum for her final thesis and has recently graduated with MSc in Computing (Communications Software).
User profile image.
Leigh is an Engineering Manager and passionate about process improvement and researching new ways to approach problems. He is an accredited ICF Coach and has led several Agile transformations within Red Hat.

1 Comment

Interesting insights on the subject, the more you read, the more you learn, the better your apply. Thanks for sharing.
Talking about this subject, we wrote an article about it on our blog at Zenkit, we'd love to have your opinion: https://zenkit.com/en/blog/uncovering-the-agile-manifesto/

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.