Proponents of Scrum often put the responsibility for failed adoptions of Scrum at the feet of management who don’t want to change. While I believe this is true some of the time, I believe the challenge is that Agile adoptions based on Scrum often don’t attend to management’s needs.
I believe management concerns regarding Agile adoptions are focused on reducing risk, making sure it fits their needs, and to be able to adapt when needed. It’s tempting to say “let’s just adopt Scrum.” But this ignores that we live in a complex world where you reduce uncertainty not by having a preset list of things you must do, but rather by learning to adjust to the situation at hand. These are things beyond our control.
What is in our control is our actions. 15 years ago we didn’t have a solid understanding of the “task work” so to speak of Agile. Why working on small batches were good, why visibility was essential, why managing queues is critical, … Now we do. This enables us to go beyond Scrum effectively.
Adopting Scrum is very often the best place to start. It provides structure & discipline. But get training from someone who knows how to go beyond it when that’s the right thing to do.
Addressing the issue of how to adjust Scrum while not worrying about if it is still Scrum is based on 20 years experience with Scrum and is described here: How to improve or change your Scrum practices. This is part of our larger Scrum Support system. I believe having a framework where being effective sometimes requires you to go beyond it is insidious. I contend there are place in any tech org of more than 50 people that no one set of practices work, particularly in shared services, DevOps, maintenance. We have put this together because we’re not limited to Scrum.
The Scrum Guide tells us “Scrum’s roles, events, artifacts, and rules are immutable”
This presumes people need this structure and can’t think on their own without it. Structure is good, but it can be achieved by specifying outcomes and principles while providing a starting point that can be changed as long as the outcomes are still achieved. Agile adopters should be focused on getting their work done, not on following a single set of rules that some people are advocating for everyone.
If you’re a new adopter of Agile don’t accept less than someone who respects your knowledge and experience. Get a coach, not a shepherd. Coaches provide clarity on the intentions and principles of Agile. Learn the how by doing your work. If that’s not in your vendor’s syllabus, get another vendor. If they say it can’t be done, find someone who does it.
You have more experience in your company than any outsider will ever have. Starting with immutability is the anti-thesis of Agile and it leaves an impression. Avoid the discussion of “Agile tells us we must do …”. It doesn’t. Scrum might but Scrum != Agile.
And it isn’t “Scrum And” over “ScrumBut.” Sometimes you don’t want to do something Scrum says.
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:
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.
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.
Every organization thinks they are different. And in many ways they are. But the principles apply equally to all. So no one size fits all, but there are surprisingly few degrees of freedom, so to speak. This post discusses those degrees of freedom – where choices should be made to best fit the organization doing the adopting.
At the team level
Scrum, Kanban or a blend of both
- cross-functional teams or manage people not on a team with Kanban
At the program level
- how to kick off the adoption (use a planning event?)
- if & how often to do a planning event
- how do we best organize our talent
- where are the product owners for the teams?
- are product managers needed?
At the adoption level
- who is best to lead the adoption?
- at what pace should we go?
This obviously leaves a lot out. I suggest most of what’s left out is somewhat common across organizations. Please provide feedback to tell me what I’ve left out.
Many proponents of Scrum based frameworks say:
- knowledge workers are people who know more than their managers
- we must trust & respect people
- people must self-organize
But then their courses go on to tell people what to do. They say – stick with these rules & then later you can modify them to fit you.
One then hears “shu ha ri” which is a martial arts term meaning to first obey, then modify & eventually transcend. But there are several things wrong with this metaphor.
We’re not in the martial arts where the idea is not to think but to act. Also, in the martial arts you train for a very long time before putting the learning into action & most ppl learn many different styles since different methods are needed for different situations. Also, people who break with what they’ve been taught are called are called ScrumButters or SAFeButters. Not surprising dogma results.
This contradictory logic is often ignored. We’re being told “we need to self-organize” but do “this” & later change, but if you change to something we don’t like “you’re doing it wrong.” And everyone ignores the self-serving nature of this.
What’s needed: training specific to the organization to get them started right.
“Test-first “sounds like it’s about testing, but it’s really about collaboration, shared understanding and better design. Test-first originated with eXtreme Programming (XP) with the focus was on writing tests before code. Fortunately, a natural law of software development is that programs written by first considering their behavior are more flexible and robust than programs written by considering their implementation.
Since then, test-first has expanded to be used between product owners and the team by specifying the requirements in the form of acceptance tests. This is called Acceptance TDD (ATDD)
ATDD requires the collaboration of all parties involved. This collaboration on understanding behavior prior to implementation clarifies what is being required while removing the delay between specification of requirements, their implementation and then their final validation. This both helps ensure the right functionality is built while increasing efficiency.
The benefits of ATDD are
- improved collaboration
- clear acceptance criteria
- prepared for automated testing
- improved developer-tester communication
- reduced time for feedback
- agreement on requirements
- improved code quality
It’s one of the best steps towards building the right thing in the right way.
For more information see:
Benefits of Acceptance Test-Driven Development using Behavior-Driven Development
How to Start with ATDD using BDD
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.
I’ve been delivering talks at conferences & user groups for over 20 years. One question I ask at most of my talks for developers is “how many of you spend most of your time fixing bugs?” Throughout all of these years, I get about 9 out of 10 telling me they do. But they don’t.
I go through this conversation with them:
- Consider a time you were notified of a bug.
- remember the time you spent trying to reproduce it
- and then figured out how to fix it and did that
- And then undid it because it broke something else
- And then found the real cause and fixed it
- Now, how much time was actually spent fixing the bug?
- I’d suggest that most of your time was spent finding the bug.
Now this is not just semantics. Consider from when you write a bug (and yes, do you write them even though you say “I found a bug” as if someone else wrote it 😊 ). And let’s say it was found right away (maybe you have automated testing). It likely wouldn’t take very long to fix, because it’d probably be due to the last thing you did. But if you discover it weeks later, even if nothing changed, it might take you hours or days to find and fix it. If things have changed, it’d take longer. And think of the wasted time you would have caused others.
The moral? Spend a little time so that you don’t have to look for bugs.