Scaling agile

Most of my posts thus far have given you an idea on how to work agile, ideally in smaller teams or companies. This time I'll talk about scaling through the known methods, and I'll introduce you to one of my own.

I'm going to start with a small disclaimer. I'm going to give a little description about some of the scaled agile practices, and I might let my opinion shine through. However, this does not mean some are bad and some are good. Remember, agile is about being flexible and adapting, so every company might have different needs and thus a different best solution to scale. With that out of the way, let's begin!

There are five major players all claiming to be the best in scaling agile:

• Disciplined Agile Delivery (DAD)

• Scaled Agile Framework (SAFe)

• Large Scale Scrum (LeSS)

• Nexus

• Scrum of Scrums

And I'm going to add my very own suggestion:

• Scaling Resources for Agile Projects (ScRAP)

Disciplined Agile Delivery (DAD)

DAD is a funny one. Instead of focusing solely on how to create a product, DAD focuses on the entire delivery life cycle. They start with an inception phase, in which you choose platforms and such. It ends with the transition phase, in which you choose how to deliver. DAD adopts proven strategies from extreme programming, scrum, kanban, agile modelling and others, so you can have an all in one solution. Since it's relatively new, DAD isn't widely adopted yet.

The absolute coolest thing about DAD is that it can implement SAFe within it's own framework!

DAD explains we need to have certain roles, to reach a certain goal. The goal is what matters most, and any solution will do. Be it software, hardware or coaching, the outcome can always change. So the roles to achieve these goals are defined as we already know them: Stakeholder, Product owner, Team member, Team lead, Architecture owner. It also offers some supporting roles such as Testers and Integrators.

This set up makes it possible to implement DAD as a small company, and scale it up to enterprise levels. One hint of advice though, if you want to implement DAD, I highly recommend hiring a coach. This is a complex and often misunderstood framework.

Scaled Agile Framework (SAFe)

As of today, SAFe has approximately a 30% market share when it comes to scaled agile. It is one of the biggest and oldest guides on how to scale. SAFe was built by different members of the agile community, making it a community framework with many of the agile principles and adaptations made through trial, error and observation. Basically you could say SAFe was created in an agile way, in baby steps, by learning from mistakes.

SAFe is mostly about adding value. Value for the product, but also value in the economic sense. It works on small increments with quick feedback loops, to constantly adapt and improve. The biggest criticism on SAFe is that it's too hierarchical and inflexible. While you can quickly adapt your products, it doesn't allow for much flexibility in other areas. This can be seen as a negative or a positive, since it will enforce a certain level of quality assurance.

A valued colleague in the field of agile, Luis Gonçalves, wrote:"

SAFe, LeSS, NEXUS and many others frameworks are sold as “scaling” frameworks. Are they allowing companies to scale anything?  The way how I see it is that they are frameworks that enable parallel work. Let´s be very clear: THIS IS NOT SCALING!!! THIS IS GROWING!"

(full blog post here)

He is absolutely right about this. Luis continues to write that SAFe might be the only one out there right now that is actually about scaling and not just about growing. Now that is something to consider when deciding what way to go for your company.

Large Scale Scrum (LeSS)

LeSS is the most logical or simple form to grow in to. I recently spoke with a large company who started with scrum in one team, and just started adding more scrum teams. They ended up with something that was very similar to LeSS without them even knowing. So this might be the most easy and natural way to go.

LeSS basically let's you have multiple scrum teams, sometimes sharing a scrum master or product owner, and having team ceremonies as well as overall ceremonies. For example you will have a team retrospective focusing on how the team worked, but also an overall retrospective focusing on the collaboration between teams.

There's not much more to say about LeSS, it's simple, it's effective and it's all perfectly explained in the picture below.

NEXUS

This is a framework that took scrum, and focused on having multiple teams adding value to the same increment. The main difference from LeSS is that the different teams all have joint ceremonies with exemption for the daily stand up.

For developers this seems to be a perfect fit, for customers as well. Because which customer doesn't want a working integrated package made by different teams with different specialisations? However, this puts a large constrain on product owners and scrum masters alike.

I personally have no experience with NEXUS frameworks, but I can definitely see some benefits and flaws from this set up.

Scrum of Scrums

A term often misused, Scrum of Scrums tells us to have the workforce split up in scrum teams, each with their own scrum master. The scrum masters, form other scrum teams, each with their own scrum master, and this can go on for as long as you want. From support to production to sales to management to directors. This however will need everybody to fully embrace every aspect of scrum and be on the same page.

Scaling Resources for Agile Projects (ScRAP)

Where each of the above mentioned frameworks puts the focus someplace else, my focus would be on the projects. Let me start by asking you why we ever started working in teams? I believe because we needed multidisciplinary people together, everybody who was an expert and could contribute we would add to the team. Nowadays, the word team is often used in replacement for the word department.

So, something a lot of companies are struggling with when they implement agile is how to run projects. Customers still want deadlines, and you want to run multiple projects at once, and many more questions arise.

Let us create a scrum team per project, with experts of all disciplines necessary for that specific project. So one project might need an architect while the other doesn't, or multiple projects would need an architect. This architect can be one person or several, one person can be put in to different scrum teams. This way you always get the maximum result after each iteration, because all the experts are collaborating on the same product. They all have the same idea, the same vision, the same goal.

You still do every scrum ceremony. You have the big backlog with all the projects. Then a project backlog, then a sprint backlog. You have the daily meetings, you have the sprint planning, the retrospective and the review. As I've explained before in my blog post about how to run projects. So no big changes in the way they're working for your teams, just the team compositions that will change.

You can expand this to as many scrum teams as you need projects to be run simultaneously. If you are one developer short, you can see if it is just for the foreseeable future and hire someone temporarily, or if it's a recurring issue and you can hire one developer indefinitely. This is how you scale, not grow with a focus on projects. Because even though I love agile and growing incremental, there will always be projects and I think we might need to stop focusing on our own processes and products, and start focusing on the projects we need to deliver to be a healthy company.

There is just one role I would like to add to this scenario, the role of a resource manager. Someone needs to do the planning of the projects and the people, so you always have enough people running in teams to deliver the projects and you always have enough projects to keep your company running.

I tried to make a graph of this proposed framework as well. I hope this might clear up some remaining questions. If not, feel free to reach out to me.

---

#AgileMonkeys #Agile #Scaling #ScRAP