How Frameworks Are Being Used Now Is Impeding Agile and What We Can Do About It

Part 1: Frameworks are taking our eye off the ball

We cannot solve our problems with the same thinking we used when we created them. – Albert Einstein

How Frameworks Are Now Impeding Agile: Part 1

We cannot solve our problems with the same thinking we used when we created them.

There is no question that Scrum & SAFe have transformed how we work. Both have created a new mindset around work- Scrum focusing on the importance of team & SAFe focusing on the necessity to coordinate teams.

And both have now created new challenges in somewhat the same manner. Each has taken our eye off the real task- working in an Agile manner. This is finding what’s of greatest value, allocating our capacity to work on it, properly decomposing it so it can be built in increments and being able to deploy frequently/continuously. Scrum’s focus on ceremonies has takes peoples’ eyes off of how they do their work – leaving it to the team with the unquestioned assumption that they’ll figure it out (& then blaming them for not doing Scrum if they can’t or change anything in their attempt).

SAFe has gotten management involved but mostly to demand that SAFe be done. SAFe is often led internally by agents who demand that SAFe be followed. Again, the focus is on the framework.

Frameworks were an excellent way to go when we didn’t understand the mechanics of Agile. We do now. We should attend to them or at least drive our frameworks with them.

How Frameworks Are Now Impeding Agile. Part 2 – Scrum

Take a look at the common challenges teams have when adopting Scrum:

  • not being able to write small stories
  • essentially doing waterfall in 2 week cycles-Scrumerfall
  • having many open stories at the end of the sprint
  • difficulties poised by being interrupted in a sprint
  • not being able to coordinate well with other teams

The similarities across widely variant dev groups is striking. Not a surprise since systems-thinking would predict this. While Scrum proponents claim “if you did Scrum these things wouldn’t happen” is likely true, what does that matter? People are doing their best.

We need to attend more to what insights & skills would help us avoid these challenges directly.

The above challenges are due to not attending to:

  • flow
  • managing work in process inside the sprint
  • the team’s part in the bigger picture

Yes, I know Scrum doesn’t say not to do these, but that’s not the same as saying to do them.

In the early days just getting teams co-located, cross-functional & working in small chunks was a major improvement. To go to the next level we need to shift our focus to the work & how to do it.

How Frameworks Are Now Impeding Agile. Part 3 – SAFe

Many people complain that SAFe is too complicated and doesn’t truly get management involvement. I would agree. But why is that?

Take a look at the common challenges organizations have with adopting SAFe:

  • little improvement beyond the program
  • little improvement in the area of portfolio management
  • difficulty resolving conflicting requirements given to platforms and shared services
  • a continuation of top-down management
  • too much work in play overall
  • not being able to get deliveries within a program increment

The similarities across widely variant organizations is striking. This validates systems-thinking’s assertion that the system people are in causes behavior. SAFe proponents claim it addresses the main issues & people just need to fill things in. I would suggest that the way SAFe addresses these issues prevents people from filling things in.

Pre-defining roles & artifacts takes our eyes off of the value stream and the work that is taking place in it. This is exacerbated by SAFe overloading and redefining terms.

In the early days getting a plan for a program & having teams work together towards that a major improvement. To go to the next level we need to shift our focus to the work itself.

How Frameworks Are Now Impeding Agile. Part 4 – The Solution

Actually, if you’ve been following my train of thought here, you’d know there is no solution. But there is an approach that will lead to a solution. It’s using Lean as an overall context for your work because Lean focuses directly on the work. Lean can help achieve business agility – the quick realization of value predictably, sustainably and with high quality.

Lean provides insights to shorten the time from beginning work until value is realized. It does this by starting with the question of what’s value to the customer? Then attending to the value stream so that we can improve it to eliminate delays in workflow and feedback. By attending to queues of work we can see where our bottlenecks are and improve them. Instead of overloading teams we have them manage their work by implementing pull systems. And, because we’re looking at improving our work directly we can continuously improve.

Fortunately, this doesn’t mean we have to re-invent the wheel. All we need to do is look at the outcomes we need at each step of the way and select the best method for us to get there. This is true agility – figuring out how to solve our problems instead of taking canned solutions.

Why I’m So Into Scaled Learning

Live training always sounds great, and sometimes it is. But except when has your teams work together, or the materials requires a lot of interaction, it’s often not the best way to do things.

Consider the following:

1. most of concentrated training is not retained and the concentrated delivery prevents you from trying things in your job & coming back into the class for guidance

2. it takes time away from your work

4. there is no method of having you learn the material over time unless your company can afford a coach

5 live training is expensive and often involves travel costs

6 you often don’t know who you are going to get as an instructor

The bottom line is it’s expensive and not always effective.

Universities have known this for centuries – spreading work out over 3-5 months. They are also adopting flipped classroom style where you read/watch something every week. Try it, interact with the instructor, try again, get questions answered and then go onto another lesson.

This is more effective and can even have remote teams learn together.  The bottom line is several times more learning at significantly less cost.

If you’re interested in learning more, please message me (classes in Advanced Scrum Master/ Kanban) and Agile at small to mid-scale.

Want some free advice on solving adoption challenges in SAFe? Help me with my book

I am close to finishing “Adopting SAFe® for Your Organization: Achieving Business Agility from Small to Mid-Scale.” We take our own FLEX approach (FLow for Enterprise Transformation) and apply it to SAFe to help solve virtually all of the challenges we’ve seen small to mid-scale organizations have when trying to adopt SAFe. The result is using the core of SAFe while fleshing it out with Lean-Agile principles and patterns of adoption to create a simpler framework, albeit perhaps no longer SAFe, to use.

The list of these challenges is at https://goo.gl/Zcx7cu
Please take a look at let me know about any others.

Why Net Objectives Is No Longer Providing SAFe Training

Why Net Objectives Is No Longer Providing SAFe Training

After 6 years of being a contributor to SAFe in technical Agility and Kanban, my having been the first SPCT outside of SAI and us being a SAFe partner, we are amicably breaking off our relationship with SAI. I believe that SAFe has expanded the understanding of Agile at Scale and incorporates many needed practices that are not found elsewhere.

The reasons for this move include:

  • SAFe has grown considerably more complex than it needs to be
  • Many small- to mid-scale orgs (technology <1000 ppl) are looking to Essential SAFe even though it is not a good solution for them
  • Many orgs are looking to take “SAFe out of the box” which has never been our approach
  • SAFe training is not tailored to the size of the organization that will use it

While taking Implementing SAFe 4.6 a couple of weeks ago I realized that SAFe and Net Objectives are on divergent paths. We like to work with small- to mid-scale companies that want a focus on their specific challenges and not just adopt a canned solution.

We will continue to offer consulting and training to those who do SAFe using our own materials.

If you want to see how we do Agile at scale, check out The Essence of FLEX (FLow for Enterprise Transformation). If you are still interested in SAFe, check out these two articles from my upcoming book Achieving Business Agility at Small to Mid-Scale:

The State of Agile, overview of a 5 part series.

This is an overview of a 5 part series starting tomorrow.

Agile adoption is often more difficult than it needs to be because most people settle for pre-packaged frameworks instead of what their particular org needs. This has people focus more on a framework than on the actual skills their ppl need to get the job done. Follow up training for these skills (eg ATDD) usually doesn’t happen. Resistance often sets in because people are put back in their jobs with higher expectations but no higher skills. This is made worse if the framework doesn’t match what’s needed close enough.

What keeps this in place is the focus on certification. While a good amount of what works in one place does work in another, the transition to these practices takes one of several paths. Many consultants offer only one type of framework, forcing them to push it only & blame their clients for not following it if it doesn’t work

What’s needed is to be guided to understand their problems, the root causes of these problems and a set of proven practices that can solve them. This is harder to manage, but the results are worth it & the cost is much less over the long term. It is also more likely to be sustainable as people actually learn the skills needed.

The Challenges of Essential SAFe

This is an excerpt from Adopting SAFe at Small- or Medium- Scale a chapter from my upcoming book “Achieving Business Agility at Small- to Mid-Scale.

Essential SAFe, the smallest option of SAFe, was designed for programs within a large organization. It was not designed for an entire organization that is the size of a program. Here are examples of challenges that come with this.

  • The planning pace for SAFe is two to three months. At the small-scale, it is more reasonable and Agile to plan one to two months ahead.
  • Different type of organizations often require different methods of planning
  • Having an innovation and planning iteration should not be required at small- to mid-scale (not to mention that the cost of it would be proportionately long given the shorter planning increments.
  • Many concepts needed at small- to mid-scale are not in Essential SAFe (in particular, how to go from strategy to the product backlog)

Fortunately, what to add, modify or leave out can be guided using Lean-Agile principles – most of which are ironically included in Essential SAFe.
This enables those wanting to use Essential SAFe as a core to have a framework that is effective, efficient and most importantly, is the right for them.

Unexamined Assumption: use Essential SAFe for small and mid-scale companies.

The following is an excerpt from the chapter  Adopting SAFe at Small Scale in Al Shalloway’s new book – Achieving Agility at Small to Mid-Scale

The Challenge of Essential SAFe

SAFe proponents suggest Essential SAFe be used for small companies. The reason for this is that small companies don’t need the complexity that full SAFe entails. But even small companies have the issue of taking their strategies to fulfillment. This means that the concepts of strategies, epics, solutions, capabilities, and MVPs are still needed. The challenge, of course, is that these are defined at the levels above Essential SAFe.

Most small companies adopting SAFe are mostly attracted to:

  • the program increment and its planning event
  • the role of the release train engineer (RTE) to coordinate teams
  • having teams work in cadence with synchronization

These can be used as the cornerstone of their SAFe adoption. However, a simple Agile Product Management approach that takes the company from strategy to realization of value is still required.

See chapter above for more.

Simplifying SAFe w/MBIs

SAFe has many concepts across its levels-strategic themes, epics, solutions, value stream, MVPs, MMFs, capabilities, stories & several backlogs.

While SAFe nobly attempts to present all needed concepts it does not explicitly call out the most important one–the smallest chunk of work that will provide the most value for the time it takes to build it. We call this the Minimum Business Increment (MBI). It is very similar to Denne& Cleland-Huang’s Minimum Marketable Feature (MMF), which, unfortunately, SAFe changed original meaning of to represent “the minmimum functionality that the teams can build to learn whether the benefit hypothesis is valid or not.” This concept is already part of Agile which always suggest to build in vertical slices to test our hypothesis.

SAFe definitely intends to have the concept of the MBI, but its use of overloaded &redefined terms make it hard to see. MBIs encapsulate the intention of solutions, MVPs, capabilities & SAFe’s re-defined MMFs. Realizing this can simplify SAFe by starting with initiatives that are consistent with our strategic themes & defining a sequence of business increments for them. These business initiatives can then be refined into MBIs which create the context for everything needed to manifest value.

The Most Important Part of an Agile Framework Is How it Is Adopted – Day 4 of #SAFeSummit countdown

There are many lessons we can learn from the challenges incurred in adopting Scrum. I suggest the significant amount of bad Scrum in the world is due to the approach in teaching it.

The most popular method focuses on the framework itself. It usually consists of a CSM taught to a team. Some guidance is provided on how to write stories, but the attendees spend virtually no time writing their own stories past the ubiquitous “as a user…” method which is insufficient in the real world.

Another method focuses on Agile analysis by having teams create a backlog of their own stories using some aspects of ATDD. Only minimum training on Scrum is needed since it is now in support of what the team’s work & they already have an understanding of the why for feedback.

We have found the 2nd approach to be significantly more effective because people leave the workshops actually doing Scrum & don’t have to figure out parts later.

I see the same thing happening with SAFe with different ramifications. The SAFe framework alone often improves orgs’ agility because of the quarterly planning event. But working with product managers prior to the event & teaching teams more ATDD & less SAFe is critical.

Why teams starting out with SAFe need little SAFe training but do need ATDD up front – 6 days to #SAFeSummit

I remember my first SAFe implementation – Northwestern Mutual (you can see a case study of it on the SAFe website). I remember that my main focus was on training the managers, product managers and shared service managers. While I did do a SAFe/Scrum course for the train, I wasn’t particularly worried about them. Continue reading “Why teams starting out with SAFe need little SAFe training but do need ATDD up front – 6 days to #SAFeSummit”