We are relentlessly expanding our tools set

We at AgileSparks help companies create effective, efficient, and happy workplaces. We do this by applying Agile and Lean principles. We understand that every approach has advantages and disadvantages. We believe that the best way is to understand what are the options, consider the context and the pain points of the organization, and then apply a best-fit approach (that can sometimes be a mix of approaches) and keep adapting and evolving it. Tyranny of thought and forced solutions are the root cause of many failed Agile implementations. Going Agile is hard enough; choosing the right process and the right pace increase significantly the organization’s ability to adopt true Agility rather than end up in an “Agile Theater” mode.

Even if you like (or know how to operate only) hammers, you will find both nails and screws in the world, so screwdrivers are needed as much as a hammer. We do not rule out any method or tool that may assist an organization in becoming more (truly) Agile and tirelessly look for more tools and ideas.

We worked with hundreds of organizations

In our 9+ years of existence, we worked with more than 200 organizations. That’s a huge number by any standard, which means we have tons of experience. We have seen small companies with just a few teams, mid-sized organizations with dozens of teams, and huge ones with more than 100 teams. We have seen organizations that struggle with different pain points: Time to market, predictability, quality, team morale, alignment between Product and Dev, and working in a highly regulated environment – just to name a few – and we understand that every situation is unique and there is no one approach to fit all. This is exactly why we always start an engagement by thinking. This might sound strange… and you may ask: With all your experience, don’t you know what needs to be done? Good question!

We start by thinking

If there’s one thing we learned in our implementations it is that without real support from management culture will not change and Agility will be superficial and volatile. Year after year, the State of Agile report from Version One states that the biggest impediment to Agility is culture and management support. To get this crucial support, managers need to understand Agile and Lean and their roles and make a mindset shift towards Agility. This can not be dictated. Telling a manager that “This is a successful framework and we believe you should adopt it” will result either in compliance (if the superior management expects the manager to “agree to transform” which usually results in a “Theater”), or in resistance  (the manager will easily explain why this framework is great but simply not applicable in this case), or both.  

The only way to achieve real support is through mutual open dialog and a thinking process with peer managers that review possible options and jointly agree.

This is exactly why we start with a thinking session – the Management Workshop.

We apply (and maintain) the AgileSparks Way

We developed our “Way” based on our vast cumulative experience, and keep adapting and improving it with things we learn along the way. It is how we facilitate and coach organizations to change and develop an Agile DNA. The AgileSparks Way is full of good and proven practices and is not tightly coupled to any Agile framework such as Scrum, Kanban, Scrumban, SAFe, or Less. DAD and more, all of which are options and sources for good ideas.

What options for scaling Agile are we considering?

There are quite a few approaches, here are the most notable ones:

• SAFe – the Scaled Agile Framework
• “Spotify”
• Program / Portfolio Kanban
• Less
• DAD
• Nexus

Each approach has pros and cons that need to be considered and evaluated against the situation. There’s no “cookie cutter” solution.

For large enterprises, we have had a great experience with SAFe in the last few years. SAFe continues to evolve and with “Essential SAFe” we believe the framework is making good moves to fit smaller organizations as well.  

SAFe is a great template to start with

SAFe is meant to serve as a template you can start with, but you are expected to inspect and adapt constantly and relentlessly. Some people out there do SAFe a disservice by teaching and implementing it as a prescriptive methodology rather than a configurable framework. The same is going on in the world of Scrum. This gets back to my earlier point – it’s about the pragmatic experience and using frameworks rather than methodologies, and making sure you start with thinking specifically in your context – ideally together with someone who’s “been around the block” a few times, has used a variety of approaches, and can help choose the right one.

With SAFe you plan ahead but are able to deploy frequently

SAFe follows the principle of “Develop on Cadence – Deliver on Demand”.

Planning does look forward (as is needed by a responsible enterprise) but leaves room for Agility and adaptations. One of the biggest pitfalls, that we warn against and make sure our clients don’t fall into, is committing to a “queue” of stories. The commitment is to the Objectives not to stories (or tasks!).

Customer collaboration is at the heart of SAFe

SAFe defines several levels of Customer engagement based on their impact on the solution. SAFe is inherently based on core Agile and Lean principles and the whole idea is to organize execution around value for customers. SAFe 4.5 goes further to include Lean Startup principles and is all about getting feedback from customers as early as possible and adapting according to the market and Customers’ needs.

So, is SAFe the only good framework for scaling?

SAFe encapsulates some very good practices that based on lessons and experience from hundreds of companies in the industry…. but if you are really asking this question, you haven’t paid attention to what I wrote so far  😉

In summary

As Agile consultants, our biggest challenge is helping our customers achieve real Agility, not perform ceremonies or follow a specific method. Learn fast, continuously improve product requirements (by understanding these are actually hypotheses we need to validate or pivot away from as quickly as possible) to deliver the right things, and build quality in — these are the things we are after. We understand this requires significant cultural changes and mindset shifts. It’s hard, and adapting to the specific context while exploring all the possible options is crucial. This is exactly why we insist on challenging ourselves to explore more and more options and to enrich our toolset, either by internal work (our team meets weekly to work on this), or by learning from thought leaders around the world. We do this to make sure we have as many tools in our box. This is why you will not hear anyone at AgileSparks talk negatively about any idea or path that may lead to true agility.