February 18, 2015
How to Scale Agile by Adapting Basic Methodology
Two of the main tenets of agile methodology are the importance of sticking with small teams and having all the members working in one place.
These two characteristics stem from the emphasis put on collaboration and it’s fundamental precondition, open communication between all team members.
However, with more effective methods to stay in touch with each other online it has become extremely feasible for organisation to have employees working remotely or in distributed teams working on a project.
This has led many organisations, particularly large enterprises, to try to scale agile and adapt the basic methodology to multiple teams working concurrently on the same product.
Three main challenges organisations face when scaling agile
You don’t have to work in a big organisation to implement the ideas in this article. Even smaller companies are finding that having all their employees working together is something they cannot afford in order to stay competitive.
Which are the main challenges organisations face when scaling agile to work with distributed teams? There are three main ones which need to be addressed in order to scale agile successfully:
The need to proactively manage inter-team dependencies;
Conducting iteration planning; and
Coordinate work between teams based in different locations and time zones.
We shall discuss ways to avoid the common problems that companies face when implementing agile with larger teams and thus smoothen the transition from having a single team to working in an environment with multiple team cooperating together on a project, no matter how far apart they might be.
A strategy to scale agile
To scale agile successfully you must first develop a strategy that reflects the work processes and organisational structure of your organisation, optimising them on a wider scale and gain a better insight into the new practices you’ll have to take aboard or the old ones you should abandon to make agile work with multiple teams.
A proven strategy for scaling agile effectively is based on the following three points:
Respecting basic agile principles. Even though the context is different, agile methodologies like Scrum remain the main source of practices, principles, and strategies that inform the development of scaled adaptation. Though the actual implementation of the techniques will vary from the typical way of doing things with a smaller team, the spirit of agile is still evident when scaling.
Using a process decision framework. A bigger organisation has more moving parts and therefore has to allow for a more dynamic environment which allows individual members and their respective team to function with the least amount of friction between team. Disciplined Agile Delivery (DAD) and Scaled Agile Framework (SAFe) are two such mechanisms that provides an end-to-end approach for agile software delivery in large IT enterprises based on process goals.
Scale in a context-driven manner. Teams have to address scaling factors that are specific to their organisational and geographic constraints. Stretching resources too thin will cause the system to collapse at some point, or at least function at subpar levels and leading to severe financial repercussions.
The scaling process is a serious challenge that cannot be taken lightly. Thanks to frameworks like DAD and SAFe, distributed teams can make more effective decisions that best address the situation at hand and enable them to navigate successfully the transition to a scaled agile environment.
Issues encountered when scaling agile
The need to expand and scale their agile practices to a wider context causes a great deal of consternation to organisations, even though it represents a phase of natural growth of the business which reflects the success in its field.
To make the process of troubleshooting the scaling of agile easier, I’ve grouped the main problems faced by companies into three categories:
Enterprises need to proactively manage any dependencies that arise from having multiple teams working on the same project and ensure there is a free flow of information and personnel as necessary. Having members moving from one team to another can be a useful way to ensure information and expertise is being shared equally, but in some cases this may not be cost- or time-effective.
Alternatively, dependencies can be managed by setting up an integration team, a sort of ‘meta-team’ that comes together only when necessary (it could be a permanent working groups in larger projects) whose job is to connect teams with the resources they need whenever gaps arise.
Finally, planning ahead for a long time period may not sound terribly agile, however rolling look ahead planning are proven to be an effective way to keep multiple teams on the same page. When a team needs to integrate its work with the work of other teams, all teams involved will usually benefit from rolling lookahead planning.
A team using rolling lookahead planning will plan its next iteration as usual, spending two to five hours to plan the sprints that will make up the two- to four-week iteration. Once the current iteration has been planned the team plans two more ‘tentative’ iterations, however less detail is necessary for this phase, therefore it takes considerably less time to accomplish and the team does not have to commit to carry out future iterations in exactly the way they are discussed.
2. Iteration planning
Iteration planning is one of the hardest things to scale as the complexity of having everyone on board during the meetings and actively contributing increases exponentially as members and teams are added to the organisation.
The two general approaches taken by product owners and team leaders in general is either to stagger meetings with different teams (or clusters of teams) during the day or week, or else to block a certain time in everybody’s schedule to hold so-called ‘big room’ meetings where everybody’s present in the same physical location but having each team occupying different areas of the room.
3. Coordinating teams
Coordinating teams requires primarily the setting up of effective communication channels that are regularly used by the team members to brief each other of their progress: ensuring that the project is developing on schedule and that each team is aware of any recent changes in direction.
Providing teams with tools like ReQtest allows them to operate more flexibly and independently, while boosting the ease with which they can share documents and communicate critical information to colleagues in their team or in a different one.
Rather than distance being the main problem with distributed teams, it is the difference in time zones that can be the biggest hurdle in coordinating their efforts together. Product owners and team leaders alike need to decide how to distribute the teams, create coherence within and between them and find a way to communicate effectively across time and space.
We need to view scaling agile for what it truly is: a proud moment in an organisation’s life cycle when the business has grown to the point of requiring (and attracting!) the skills and talents of professionals globally.
With a strategy built on timeless agile principles and tailored to the unique context of your organisation you can scale agile more safely.
Moreover, preempting the three main types of challenges mentioned in this article will offer a fair degree of resilience in the face of this transition and help you coordinate more efficiently the efforts of multiple teams in the delivery of high quality products for your clients.