The Small Scale Agile Manifesto

The Small Scale Agile Manifesto

These six values enhance agile methodologies to help smaller teams work more efficiently.

gears and lightbulb to represent innovation
Image by : 
Opensource.com
x

Subscribe now

Get the highlights in your inbox every week.

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

CICD with gears

Here's how the scrum agile methodology can help teams of three or fewer work more efficiently.

Topics

About the author

Agnieszka Gancarczyk - 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). Apart from software development, her interests lay in project and people management.

About the author

Leigh Griffin - Leigh is an Engineering Manager and Agile Coach working for Red Hat. This role allows him realise his passion for Coaching and helping individuals and teams improve how they work on a day to day basis.