Examples Showing How You Can Scale Scrum
Larger organization often have the desire to use Scrum beyond the team level. This news explores some examples of what organizations do to adopt an agile way of working across the enterprise by scaling Scrum.
In the article maximizing scrum Gunther Verheyen explores how organizations can scale Scrum. He describes the view that organizations often have when they think about scaling:
Over the years, the existing way of working has ingrained the belief that growth (i.e. ‘scaling’) is only achievable by increasing volume and quantity. The desire ‘to scale Scrum’ is a reflection of past views in which growth was only achievable through larger numbers.
Gunther describes the problem that organizations can face when they try to scale Scrum based on this view:
For obvious reasons, organizations are reluctant to touch the existing structures, and keep operating within them. Hence, they look for an implementation of Scrum that fits. This often results in twisted implementations of Scrum, whereby the foundations and principles of Scrum are broken beyond repair. This limits the benefits to be gained from Scrum upfront. The problems are not really solved, at most superficially touched.
He suggest another way for organization to view scaling Scrum:
The primary potential to scale Scrum is not in enlarging capabilities, in quantity and volume, but in improving existing capabilities. Scaling is in the teams, not in adding teams, roles and phases.
According to Gunther you first need to understand and employ Scrum fully before attempting to scale it in your organization. In his article he provides examples of how you can exploit Scrum in a team, and by improving how you use Scrum get more benefits from it in your organization. He call this scaling within single teams. One of the examples he provides is how you can scale the product owner role within a team:
- An IT-person in the role of Product Owner, often a (business) Analyst, has limited benefit. It’s just a way for the development organization to secure control (‘Can’t trust business people!’). However, for many decisions, the analyst has not enough product management or business development insights and needs to revert to product management. That creates waste, waiting times, frequent task switching – there is no flow, no value.
- An IT-proxy for the business works slightly better. Control remains with IT (‘Still can’t trust business people!’) but a Product Owner that is more connected to the business results in less waiting time, and less hick-ups; although many of those remain.'
- It’s a great improvement to have a representative from product management (‘business’) to fulfill the role. There is more direct availability of functional knowledge and stakeholder expectations. Yet, limitations in autonomy still cause waiting times.
- It works better if the person is not only from business, but also has the trust and the mandate to make decisions on the spot. There are less hick-ups, less context and task switching, and largely improved flow. The Development Team can focus more and get things done.
- It is great if the Product Owner is a mini-CEO of the product -- a real owner of the product (what’s in a role’s name, right?) -- a businessperson with full (functional and budgetary) responsibility and a tight connection to all product management aspects (marketing, competition, users, legal, finance). The person’s professional life is dedicated to the well-being of the product. They don’t come much better than this.
In the blog post Scrum doesn't scale! really? Steve Crago provides suggestions that can be used when scaling Scrum. One suggestion is to be prepared for changes of the team members in teams:
When doing any type of scaling, it is important to understand that team members come and go; people quit, are fired, go on vacation, get sick, etc. We deal with these scenarios on a daily basis. Therefore, it is imperative that the structure of the team be fluid and that it allows for worst-case scenarios. When I am building a team, I keep this in mind; and I make sure that no single person is indispensable. Cross training is vital.
Another suggestion is how to coordinate multiple Scrum teams when Scrum is scaled:
Self-organizing teams work with other self-organizing teams in order to determine dependencies, priorities, special skill requirements, etc. Some of this coordination can be done in the Scrum of Scrum meetings, where a member of each team comes together and discusses what has been going on with his/her team. Other discussions and/or meetings can be conducted as needed.
Tirrell Payton wrote a blog post titled scaling Scrum: 4 tips to help with organizational change. Agile is not a another software development life model that you can implement and start getting benefits, says Tirrell:
Scrum does not make you faster, it helps you understand why you are slow. What you do when you gain that understanding is up to you.
Implementing Scrum in a larger organizations differs from implementing it in a team as Tirrell explains:
In the case of a small-group adoption, both problems and solution are very localized in that they can usually be solved at the same level of the organization that noticed them -- provided the organization is flat, as most small orgs are. However, when we look at larger organizations, the problems and weaknesses that prevent complete transformation are usually symptoms of the layers and structures of the organization itself. Scrum makes these organizational problems and weaknesses more visible, and making these problems more visible can make people feel most uncomfortable.
He provides examples of what you can do to adopt the organization when you want to scale Scrum:
- Orient the efforts around products. (…) Take everything you need to take a product from idea to market and build your teams around that singular focus.
- Ensure that company leadership reinforces the Agile vision. When leadership holds a strong vision around where they want to go, it helps inspire the actions of the whole organization.
- Communicate. Communicate. Communicate. (…) It needs to be painfully obvious what the vision of Agility is and why it's important to attain. Communicate with both words and actions, and make sure your actions uphold the vision.
- Create opportunities for short-term wins. (…) Getting a "win" helps maintain everyone's focus, refreshes the energy around the effort, and gives you a talking point when you're measuring the progress of the transformation.
Stephen Younge wrote a guest blog on ZDNet about how agile can work in larger enterprise projects. He gives an example how you can scale by applying agile principles at different levels:
It has been said that as an enterprise or project grows, Agile will cause teams to lose sight of big-picture goals, such as managing demand, architectural runway, database standards, dependencies, and strategic planning. However, Agile has a fractal, scalable nature that allows for growth. In Agile, the same tradeoffs and methodologies apply to different levels of scale in the organization. For example, a single scrum team may consist of seven to nine people and plan in two-week iterations with user stories; whereas a single Agile program may consist of seven to nine scrum teams and plan in one-quarter iterations with customer features.
Do you have examples showing how you have scaled Scrum in your organization?