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.
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.
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
I see a need for a new service and wonder how many people would be interested. As many people know, we’ve been on the front edge of XP, Scrum, Kanban, Lean, SAFe, technical Agile and more. We, of course, do assessments and Lean-Agile Transformations. In the course of these proposals I have noticed that many companies don’t have experience selecting who will work best for them Continue reading “Want an experienced person helping you with Lean and Agile proposals?”
From the moment Scrum became more popular than XP, the software dev community has been focusing on frameworks more than Lean-Agile principles. It’s not surprising this has happened. It’s a lot easier to understand a framework than the principles underneath them.
The challenge that occurs is when the framework becomes the goal. Continue reading “Frameworks, proxies and Lean-Agile Principles”
Alignment is critical for Agile. The more you have the more autonomy people can have. It’s what teamwork is really about. At the team level people align around the team’s backlog. But what do people align around at scale?
I like Don Reinertsen suggestion “There is more value created with overall alignment than with local excellence.” Continue reading “What are you aligning around?”
Many Agile folks think of tools as a necessary evil. But they have a definite purpose and done well are essential.
Any Lean-Agile approach should start with getting an understanding of where the company is. Mapping the value streams of an organization is usually a good start. Identifying challenges in workflow and team structure is another. Only then should an adoption of a new workflow or company re-structuring take place. While it is often tempting to take solutions off the shelf it must be kept in mind that no one-size-fits all. Continue reading “The purpose of tools in mid to large scale transformations”
I’m referring to getting large numbers of people up to speed effectively and economically in knowing how to do Agile development. Consider what we know about how people learn: Continue reading “The scaling we’ve forgotten”
After being at Agile 2018 I see more hope for people learning how to become more effective in a more effective manner. People were asking questions and fewer were looking for quick, rote, solutions. Of course, my sample was incredibly unscientific and is anecdotal. But I am an optimist.
I know I have a reputation for seeing the negative in things. But my path has always been: Continue reading “An open invitation for a discussion”