SAFe-ty tips for your Agile transformation

Agile is a concept best suited for creative work. Software development is one of them. Not surprisingly, Development teams very easily adapt to this mode of delivery. Scrum has been extremely successful amongst IT teams.

However, implementing Agile at scale means that Agile concepts need to be embraced by management and leadership. That's where it gets tricky. SAFe provides a framework to do it, but often management may end up using it as a process and can become counter productive.

Here are some of the typical challenges and tips around how to navigate them through:

Agile is a culture, SAFe is a framework … So is Scrum

Agile delivery is not just another framework of delivery. It calls for a significant cultural and mindset shift and promotes radical ideas like variable scope instead of fixed, reduced documentations, team ownership instead of individual accountability. All these are hard to adapt.

Proven framework like Scrum helps a lot in making the transition easier, but we have to be mindful that framework are just the means to the end and not the actual goal. Following scrum, for example, helps the identified product owner to think roadmap instead of Plans, taking decisions using empirical data and promote feature negotiation with the End-user or the Business. Bi-weekly sprints are a means for adaptation if it's a wrong direction and it also helps focussed build activity (remember, creative work requires focus) and helps the team to avoid distractions. 

During small scale agile implementation, often the IT delivery part of traditional projects are converted to agile and not much change happens on the way enterprise spawns and track program and portfolio of work and corresponding funding. This in-affect means that Culture change is limited to delivery Teams. PO bridges the culture gap, abstracting rest of the organisation like the business, finance, PMO etc. It's similar the role an electric transformer plays in step-ing down voltage from the grid before distribution to the city and step-ing up the voltage of outgoing residual current back to the grid. 

Doing Agile at Scale, however magnifies the cultural challenge. SAFe recommends radical changes to Business case process, funding and Business adaptation. This culture change is often much more difficult to implement outside of Development organisation, especially rest of the enterprise that feeds work and money into the delivery engine thus created. Product Management or Value Stream construct should play pivotal role in bridging the gap, while rest of the enterprise adapts. 

 Tip:

For Scaled agile implementation, Consider creating value-stream construct as a team of people who can create a buffer zone. Some examples how this could work:

• Pipeline Management: Convert incoming projects to EPIC. Some incoming projects/initiatives may be easy to adapt, whilst for others the value stream must provide capability to handhold them.
• Funding - Key SAFe idea is to fund the teams, not the project. In reality though, source of funds may be outside your SAFe construct. Value stream must manage project funding and reporting on enterprise side and morph them to team funding on ART side. Innovative accounting can be used to make it work, while rest of the enterprise adapts.
• Value realization - Bride the gap between ART delivery and feedback process with the existing enterprise process of delivery and feedback. Continually negotiate with Change, Release and Business change to evolve a win-win arrangement 

Target being a Chef not a cook: Getting stuck in "Shu" of Shu-Ha-Ri

There is a Japanese technique of learning a skill called Shu-Ha-Ri, which in simple terms means

1. Follow the recipe
2. Understand the reasoning behind each step
3. Make your own recipe 

If you get stuck in Number 1, you will become a cook not a chef.

Following up on this anecdote, the goal of implementing agile is for the organisation to find its own rhythm, its own culture and process that works best for that organization to provide agility. Frameworks like SAFe/Scrum are the means to the end and not the end itself. So, use it to promote product thinking, trust, importance of working software and empowered decision making, but don't make use of framework the only goal. 

The goal is to reach #3 state, where the leadership becomes bottom-up and team tells the leadership how they should operate and continually improve to achieve the vision and roadmap.

Who knows, once your teams are working like well oiled machine, they can tweak the framework to create one hell of an agile dish. 

Organizations implementing Agile frameworks have a tendency to get bogged down into following the framework instead of promoting Agile culture, improving the flow and focusing on the outcomes. 

Tip:

Encourage servant leadership, and seek genuine and honest feedbacks from teams. Guide the teams to appreciate why the ceremonies are important instead of blindly following them. 

Don’t just think about laying the bricks, think about building a house: Define your products & boundaries. 

There is a famous saying that in Agile, time and effort is fixed and scope is variable.

Key thing is that, variable scope does not mean undefined or uncontrolled scope. Best way to manage scope is to have clear boundaries. That boundary defines your product.

Without boundaries, there could be ambiguity in team skills, dependencies and risk management. 

This is relatively easy for a product company but much harder for an operational enterprise. This is because, product company has natural boundary. For an operational enterprise, however, all potential products are working parts of a larger system. Nevertheless, when you are able to define your product(s) boundaries, it greatly helps in managing external dependencies and inter-dependencies. 

SAFe is quite light on product thinking, perhaps because it assumes that teams are already agile and you are simply scaling up. If there are ambiguity at team level, scaled agile will make the ambiguity exponentially bigger! 

Tip:

Identify your products before you identify your PO and groom them accordingly.

Clarity on products will help accelerate decentralizing decision making.

Some products may be thoroughly technical e.g. shared platform - Your PO needs to be technology focussed

Some products may be Business products e.g. Digital App - Your PO needs to be customer focussed

Allow PO(s) to take decisions, allow small failures to help them learn ownership of the product. 

Build your house the way you want - But respect the council

 Depending on which flavour of SAFe you are implementing, there are bound to be multiple "touch points" with rest of the enterprise. These touch points could be in

• The "flow" of work : Both input and output.
• Product Boundaries.

We need to clearly identify and work through the rules of engagement if you like, around those boundaries otherwise you risk creating bottlenecks. Few examples:

Funding: If your portfolio funding is not mature enough to be adapted to light business case approach or incremental funding, then there is a significant risk of impacting the flow due to delays in funding or prioritizing incorrectly, for instance if an important project got stuck in approvals! Potential Mitigation for this is

• to create a management construct that can protect the ART(s) from such shocks
• Organize BAU funds to maintain the steady flow of work. 

Integrations: If your architecture runway requires integrations to products/system which are NOT part of your ART then there could be a risk of blockers. Other team may be working on different cadence, they may not be agile at all, they may have months of lead time.

Mitigations: Depending on the circumstances,

• Product management has to think ahead in their roadmap and may have to start funding the external capabilities for future items by taking calculated risk.
• Tactical solution may be required or feature breakdown may have to be done keeping external constraint in mind

Change Management: Release on demand!! Sounds great. But there may be constraints in your organization like

• Your devops capability - internal or external is not mature
• You may have to follow a delivery schedule defined by external factors

Mitigation: Add these factors in your Sprint and PI planning. Define Acceptance criteria to a point where you have control of and leave capacity for supporting rest of the Change/release management 

Tip:

Just start with what you know, but measure the flow and bottlenecks/blockers.

External blockers are the tell tale signs of where innovative fixes are required. You may fix the blocker by escalations and extraordinary support form leadership, but ensure that your value-stream fixes the process so that next time escalation is not required.

Have a backlog of these process gaps to work through them and resolve them for good. 

Suppliers and vendors: Don’t use canon to shoot a rabbit

In an enterprise most IT delivery involves COTS products and most IT Solutions require integrations to externally provided services. SAFe deals with Supplier and Vendor at a Solution train level, where economies of scale can be leveraged.

However, at the ART or team level, there are scenarios where supplier/vendors are required but in short bursts. Involving them in full PI, for instance may be rather costly affair. 

Tip:

Monitor your roadmap, identify external touch points in advance and discuss engagement in advance.

Negotiate and brainstorm engagement pattern with them that is a win-win financially for both parties. 

Vision: "Why" is always more important that "How" and "What"

In ideal SAFe, all the work ties to the identified vision. In reality however, work is funded by different projects that may be driven by different vision that might as well be contradictory to your vision.

A conflicting vision, can cause toxic culture and we all know a good agile implementation is all about culture.

Therefore, build your vision wisely - a neat balance between too vague and too specific.

Tip:

Figure out a way to Tie your vision to your company's vision! 

Roadmap: Plans are worthless but Planning is everything

While Agile teams are busy sprinting every 2 weeks, somebody has to sneak peak into the future and plan (Yes! Plan). PO and Product Manager typically are more valuable in planning the roadmap than day to day delivery. In fact, more clear their roadmap is, better will be their ability to take delivery decisions.

As mentioned before, a roadmap also helps identify future roadblocks that may require upfront planning. 

Tip:

Formally publish road-map of products to rest of the Enterprise.

Plan alignments using roadmaps. Share the intent using roadmaps.

That way, there will be stakes on the roadmap and rest assured genuine feedback will come from exited and concerned stakeholders 

Enabler are nothing without dependent features: You can get a broadband, but you still need to subscribe to Net-Flix 

In SAFe, there is an elegant concept of enabler and features to distinguish architecture driven and user driven work. However, often the PO(s) fall into the trap of assuming that enabler would deliver everything that they need, only to be surprised later on.

It needs to be kept in mind that enabler is to reduce future costs, so it should be generic and hence need to have plug points to user features. Meaning that, albeit small, there has to be feature effort in making the enabler useful. 

On the flip side, this does not mean that enabler has to be future proof from day 1. Depending on need of the hour, architect may define simple enabler to fast track consumption to start with (capability mvp if you like) and then it can be enhanced later by another enabler on in the roadmap (akin to transition architecture approach) 

Tip: Measure!

Architecture shall keep track of business features that use the enablers overtime. Collect data on utility of enablers.

It will be valuable for architects to learn specifying better enablers in future.