Frameworks should be architected in the same way that software systems are. Both need to be able to evolve without adding complexity, be robust and be clear in how their different components interact. Few frameworks, other than FLEX, however, have what could be called an architecture. Most are collections of value and practices loosely overlaying some principles (which, often enough the framework itself doesn’t follow well).
Category: SAFe
Make your Essential SAFe adoption more effective by adding just one explicit concept
Starting with Essential SAFe does get people working together. But the real problem for most companies is that they can’t sequence work well and are working on too many too large items. This causes thrashing and delays delivery. You don’t have to implement the higher levels of SAFe to get much of the benefit they promise. All you have to do is make explicit a powerful concept missing in all of SAFe – the Minimum Business Increment (MBI).
The Mistaken Assumptions of Essential SAFe and What They Tell Us
From the SAFe site:
- With such a robust framework, the question becomes; how closely does an organization need to follow various SAFe practices to get the desired result?
- [Essential SAFe] provides a starting point for implementing SAFe and describes the most critical elements needed to realize the majority of the framework’s benefit.
SAFe is projecting the word ‘robust’ (which means strong) on itself instead of using the more appropriate ‘complicated.’ This is merely putting lipstick on a pig.
SAFe’s complexity makes it hard to implement as a whole. There are many essential concepts in the higher levels, however. The choice becomes insufficient or overly complicated.
Essential SAFe has Mid to small size organizations (especially those within larger companies) lose the opportunity to solve one of their biggest problems – prioritizing what to work on. Claiming that one should start at the bottom is reckless.
The bottom line is that SAFe is an overly complex framework requiring one to start with only a part of it. But this violates what SAFe claims to be built on – systems-thinking and Lean. It also loses the opportunity of getting the higher levels involved quickly.
Questions to Ask Yourself While in an Implementing SAFe class
Organizations going to Agile at scale are often pretty set on SAFe. It’s a popular framework so it must do some good. And it does. It attends to the key objectives required but gives only one solution when there are several options needed. While alluding to Lean principles, no one can learn how to apply these in just two or three days.
Taking an implementing SAFe can provide key insights especially if consider three things when in the course: Continue reading “Questions to Ask Yourself While in an Implementing SAFe class”
We need to focus on our work, not the framework
A great way to illustrate this is to read imaginary certification question for a framework, vs how to get your work done. Which would you rather be able to answer? My experience is it takes about the same amount of time to learn either one.
“What is a program backlog?” compared with “How does an effective intake process help define responsibilities for product management and make life better for developers?” Continue reading “We need to focus on our work, not the framework”
Be careful with SAFe’s use of the MVP
Eric Ries defined MVPs as “that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
If you are an established company, you already have a customer base, know a considerable amount about your product and you have competitors you are trying to either keep ahead of or catch up to.
You probably spend more enhancing existing products than creating new ones with an unknown market.
Product development in established companies usually starts with initiatives and then seeing “what is of the most value that we can deliver sooner.” This is where the concept of the Minimum Business Increment is useful. MBIs are the smallest part of an initiative that will realize the most value when delivered. It also includes any steps needed for release and support. This is a far cry from the MVP where we start small and extend.
Both MVPs and MBIs are conceptually about value sooner. But confusing their different intentions and implementation approach causes problems if you don’t attend to that they are different.
See more at Minimum Business Increments in my book on FLEX.
How to do SAFe “by the book” better than the book
I hear many C-level folks mandating doing SAFe by the book. This post is for those of you who need to do this but want to take advantage of the fact that SAFe is a framework and can therefore be modified to some extent.
As a former contributor, SPCT & gold partner I can give you some advice you won’t get from SAFe partners.
1) Find an SPCT that is not dogmatic about SAFe. Talk to a former client. Everyone says they are not dogmatic. I can give you a referral with no strings or cost attached as well.
2) Make it clear what an MVP is. The inappropriate use of MVP in SAFe in non-startup environments has caused confusion. If you don’t make it’s meaning clear it will mean everything, and therefore nothing.
3) If you have platform teams, ensure you set up your trains accordingly. SAFe gives little guidance here. Use Kanban to manage their work driven by other teams & prioritize by MVP importance. Chapter in book is coming soon.
4) Take ATDD up front and don’t think you’re getting it in the ASE. ATDD is a collaborative method with POs, devs and testers. By relegating ATDD to 2nd tier training & making it a technical offering SAFe is doing you a disservice. We offer ATDD training with SAFe if you’d like to learn more.
Why SAFe’s Top Layers Are Needed But Overly Complicated
I had hoped they’d fix the underlying flaws of SAFe but am now convinced that will not happen. Here’s why we only help folks doing SAFe but don’t train it anymore:
1) SAFe’s based on levels & not on the value stream. All companies need the concepts in the top levels (e.g., strategies) but these are overly complex due to factors described in the rest of this list so SAFe’s method to achieve them is unusable for many organizations
2) SAFe has tacked concepts together by focusing on roles & artifacts while misusing/redefining previously useful terms
3) SAFe does not have a concise, well-defined concept of the smallest increment of value used to extend an existing product. MVPs are for new products & epics are too large. This makes prioritization across teams difficult
4) there is no simple way to have the org align around value
5) the Lean principles mentioned are used in a superficial way
The result is a pre-defined, over-complicated solution. SAFe can be a massive improvement for companies whose development group is blocked & it provides low cost training materials. But it will not help achieve true agility except when guided by a real expert who goes SAFe to achieve that. SAFe is often used to gain consistency not agility.
These are not idle comments. If you are using SAFe and finding value at the program level but want to improve its higher levels, you will find value in Part IV: Using FLEX to both enhance and simplify SAFe
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: Continue reading “Why I’m So Into Scaled Learning”