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
Continue reading “The contradictions in many Scrum-based Framework Training (Scrum, SAFe, …)”
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.
Scrum presumes it is effective to give all teams a simple preset, immutable framework that each team must follow until they figure out how to manifest it.
Scrum is designed for and requires cross-functional teams doing work that is plannable. If these conditions aren’t met it is presumed that manifesting Scrum’s rigid framework will achieve Agile in all situations if people are motivated.
An underlying believe is that teams can’t initially understand what they are supposed to do so must be given a predefined set of rules that must be implemented without change until the team understands what’s happening.
While this approach works when cross-functional teams can/should be created & work can be planned, it can causes resistance & abandonment of misunderstood practices when teams have challenges adopting the framework or attached to their roles.
Have expert have 2 hr discussion w/ team&their management to see what alternative or additional practices would be useful. Use these to provide a set starting point and provide teams a guide on how to improve/change practices when they encounter challenges. While coaching still advisable, significantly less will be needed.
I invite people to discuss these alternatives.
I’m often hearing how Agile is failing because leadership and management won’t adopt Agile values & principles. I would much rather they just keep some basic agreements:
Let’s stop for a minute and ask ourselves, do we want them to ‘be’ Agile or to do the following:
1-create clarity on what the most important work to do is
2-define these as a sequence of small increments for which we can realize value. Have each of these increments include technology &any other groups needed to realize value
3-provide technology clear acceptance criteria on these items
4-provide guidance across business units as to which are most important based on cost of delay
5-allow technology to self-organize & pull the work to be done in the sequence of greatest importance when technology has capacity
6-have an agreement with technology on how to handle emergencies
7-provide feedback when needed
We have come up with the following agreements we call the guardrails:
* Focus on realizing value
* Collaborate with each other in order to maximize the realization of value
* Make all work visible
* Sustain or increase predictability.
* Keep the work within capacitythroughout the value stream
* Encourage everyone to strive for continuous improvement.
For more information on the guardrails, go here.
To see guardrails tailored for leadership and management, go here.
This blog is an excerpt from my upcoming book –Achieving Business Agility at All Scales
In my earlier post I discussed the relationship between visualization and reorganization & discussed how orgs should not limit themselves to visualization but should reorganize after visualization as appropriate. But in some situations reorganization is often not a real possibility.
Consider when vertical applications drive horizontal support systems & at scale. In a financial company one might have verticals for – banking, credit cards, signature programs, loans. These feed horizontals such as – payment processing, transactions across accounts, client account setup and maintenance …
In a situation like this, splitting up the horizontals into trains to work with the verticals won’t necessarily work well – either when you run them as separate trains or as part of the vertical train. Running the horizontals as separate programs doesn’t solve the problem either as they are each pulled in multiple directions.
In these cases, it is often best to create visibility on the work to be done by using Minimum Business Increments as the guide for what to work on across the organization.
n is often not a real possibility. Consider when vertical applications drive horizontal support systems & at scale. In a financial company one might have verticals for – banking, credit cards, signature programs, loans. These feed horizontals such as – payment processing, transactions across accounts, client account setup and maintenance … In a situation like this, splitting up the horizontals into trains to work with the verticals won’t necessarily work well – either when you run them as separate trains or as part of the vertical train. Running the horizontals as separate programs doesn’t solve the problem either as they are each pulled in multiple directions. In these cases, it is often best to create visibility on the work to be done by using Minimum Business Increments as the guide for what to work on across the organization.
This blog is an excerpt from my upcoming book –Achieving Business Agility at All Scales
This is an excerpt from a chapter my new book Achieving Business Agility at Small to Mid-Scale.
Scrum.Org defines “ScrumBut” as meaning “that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team.”
Continue reading “Rethinking ScrumBut &ScrumAnd”
This is an excerpt from a chapter of my new book Achieving Business Agility at Small to Medium Scale.
An advantage of using Lean-Thinking behind both Scrum and Kanban is that both tend to ignore one or the other in their own manner. Scrum prescribes reorganization into cross-functional teams while LKU Kanban says reorganization is “orthogonal to Kanban” most likely because LKU Kanban is based more on theory of constraints which does not focus on reorganization.
Lean-thinking suggests using cross-functional teams in product development. But you should only do this you can see what is happening. This delay may be measured in hours or months.
You don’t need to reorganize when you use Kanban, but that doesn’t mean you shouldn’t when it’s appropriate. Don Reinertsen tells us “flow when you can, pull when you must.” Reorganization to achieve flow instead of needing kanbans is a tenet of Lean.
Lean suggests the use of ‘workcell’s (teams in product development). This enhances flow while enabling more innovation. Reorganization when guided by visualization & the theory of flow can be a very effective tool. It should not be ignored.