Why we need adaptive frameworks
Most frameworks are adopted in one way. Scrum has immutable roles, rules, events and artifacts so any start will attempt to have those. While you may vary things inside of it, this makes it somewhat of a static framework. SAFe’s implementation roadmap is the same regardless of the organization using it, taking a bottom level up approach since that is supposedly simpler. Neither take a look at where the organization is with the exception of some minor adjustments within the framework.
Taking this approach has the following disadvantages I’ve mentioned before:
The result is that they only fit a certain number of organizations and those are typically the ones where teams are easy to form. A framework that adapts to the organization adopting it is critical. This increases adoption speed and value achieved while avoiding resistance.
Creating a starting framework
It is important that people be given a set framework to start with. However, this framework must be tailored to the organization. This is not difficult as most companies follow reasonably well known patterns. The method used to create a starting framework can also be used to adjust the framework as the organization evolves. This is FLEX’s approach – start with something specific to the organization adopting it and provide guidance on how to further improve.
The starting framework is decided upon by looking at both where the organization is and including these factors:
What parts of the value stream should be focused on in the initial adoption
While systems are not a collection of their components, it is useful to think of FLEX as a set of different areas you can start with. These are shown in Figure 1.
These areas each have their own set of improvements. While we’d like to start as early in the value stream as possible, we may not have the support of the required people. Figure 2 shows the improvements that usually make the biggest difference to an organization.
It is best to start as far up the value stream as possible. When a company is focused on its strategies everything works better. Alignment is easier to achieve and efforts don’t get as distracted working on things that are not of greatest importance. We, of course, don’t want to do everything we can at all levels. “Boiling the ocean” is virtually never a good thing. But because each of the parts of the value stream affect all of the others, it is important to consider that the earlier in the value stream we start the more positive change we can make. The trick is not to overload any role but to select those changes that will work together in a synergistic fashion.
When changes are made how they will impact other areas must be considered. Although all of these recommendations have patterns of success and science underneath them, they should always be considered to be experiments as organizational improvement is a complex undertaking.
The areas of FLEX adoption
If you’ve got sponsorship from the C-suite or business stakeholders start at the portfolio level. This doesn’t take a lot of effort on their part, but doing so will enable tying the work being done to the strategies of the company. See now Strategic Planning & Lean Portfolio Management solves many of the common challenges the organizations face.
FLEX product management
FLEX Product Management incorporates taking both work from initiatives as well has defining an effective intake process that captures all work in the organization. This involves both decomposing initiatives and combining this work with the rest of the work the development group must do. The end result is a backlog of sized (mostly MBIs, some MVPs and MVRs) and sequenced work.
See Have an effective Intake process for more.
The most common place to start is with the development group.
Getting software developed does no good if the customer doesn’t realize value from it. This requires including ops and marketing during development so that they will be prepared to release and market the products/services as well as support them. Telemetry to validate the value achieved should also be prepared for.
What else to include
Wherever you start, all parts of the organization downstream from there in the value stream should be included. However, this is sometimes not possible. Understand that when that happens you will need to create visibility on the interaction between the parts being improved and those that interact with it but are not changing.
What practices should be used
Each area will require a different set of improvements. For some of these, there are best practices that we can use. But for many others there will be a fair number of options that depend upon how the challenges of the organization. Therefore, when considering what changes to make, the practices selected should be those best suited to where they are being adopted.
The order and speed of adoption the improvements are done is important
While there are patterns to the order of improvements, there are variations depending upon:
To properly decide on what actions to take you need to understand what your challenges are. Figure 2 shows the challenges most organizations have.
It is best to learn this by example. Print out the figure above and take a few minutes writing down which of the above challenges your organization is experiencing. Fill out the upper right box leaving the line blank if it’s not a problem, 1 if it’s a serious problem, 2 a moderate problem and 3 a minor problem. Then, go through each of the potential actions that follow and see which ones will help the most.
Potential actions to take
Getting leadership and management involved is critical. Leadership’s involvement is mostly approving of requests made to make the organization more Agile. Management’s involvement is to create the environment within which people can work better.
Lean leadership and management is required to ensure that everyone in the organization agrees to abide by the guardrails. This sets the stage for all improvement. But in addition, Lean leadership and management helps reduce the following challenges in different ways.
Ineffective budgeting can be improved by committing the organization to working on what is important to it and agreeing to organize the teams around the company’s products and services.
Shadow IT is not necessarily bad. However, it has to tie into the support systems of the organization.
Poor discovery intake process can only be improved with management requiring whatever is agreed to to be followed.
Working on too many things requires managing the amount of work in process.
Insufficient specialized skills can be improved by adding more capacity to the skills needed and by ensuring that the demands on these people are managed properly.
No line of sight to strategies and OKRs makes it hard for teams to align. But to create this requires both a commitment to necessary tools as well as a management creating a system that can create this line of sight.
Lack of visibility of workflows causes significant waste. Teams are sometimes concerned about having this for two different reasons. Sometimes they are concerned it will lead to micro-management. And sometimes they don’t want to create the habits and discipline this requires. Either way, management must get involved.
To improve lack of coordination between teams requires clarity on what the organization considers important. This requires management align to help the teams align around what’s most important. Otherwise they will be pulled in different directions.
Integration errors are really teams getting out of sync with each other and not discovering it until they try to integrate. The longer it takes to integrate the more effort it will take to fix this. Management creating a bigger picture for teams to work in often goes a long way for integration taking place earlier than it would otherwise.
Problems discovered late is usually caused by not keeping the bigger picture in mind. Another job of management is to help create the templates and workflow that helps avoid this trap.
Ops blindsided and pulled in many directions occurs when priorities are not clear and visibility between develop and ops is not maintained.
Marketing needs left out can be avoided with the bigger picture view that management must provide.
Ineffective budgeting can only be improved if you can see what is being worked on.
Shadow IT has two forms. The first is when business stakeholders start their own projects. The second is when requests are made directly to developers and no one else knows that the work they cause is taking place. Creating visibility exposes both.
A poor discovery intake process can only be improved when all of the work can be seen.
To manage working on too many things you must be able to see what you are working on.
To manage having insufficient specialized skills kanban boards can be useful to manage the requests for them. Having an explicit workflow enables avoiding starting work that will require specialized skills when they are not available.
No line of sight to strategies and OKRs makes it difficult for people to make decisions in the context of the bigger picture. Creating visibility means having it be clear where all work originated from and why it is important.
Lack of visibility of workflows is fixed by having explicit agreements about how work is done.
Lack of coordination between teams ican be improved when all of the teams can see what each team is working on.
Integration errors occur when teams have misunderstandings about who they are going to work together that aren’t found until integration. Creating visibility won’t avoid these, but can make integration take place more quickly. This would have them cause less damage.
If problems are discovered late, having visibility on what’s needed includes templates that include what to check for.
Ops blindsided and pulled in many directions happens both when they can’t see work coming their way and can’t prioritize the work they do get.
Marketing needs left out can be avoided with the same means of avoiding problems being discovered late and avoiding blindsiding ops.
Most companies have a fairly well defined strategy . The biggest challenges they have include:
Fixing these challenges is not usually very difficult if C-level people are involved. It’s about:
However, unless C-Level folks are driving things you can’t usually start here.
The diagram shows the effect of having strategies, OKRs and Lean Portfolio Management. Here’s how this helps the challenges mentioned:
Ineffective budgeting. Being clear on your strategies and objectives highlights that value is achieved not through development but through the entire value stream – realization being most important.
Work items not sequenced. The only effective way to sequence work items from different product managers / owners is to have a common set of objectives to measure against.
Unclear requirements. Having clear objectives and well defined customers makes clarifying requirements easier and more effective.
No line of sight to strategies and OKRs. It is impossible to have this if you don’t have clear strategies and OKRs.
Lack of coordination between teams. Lack of coordination between teams often comes from teams being pulled in different directions. Strategies and OKRs can help align the work of teams.
Problems discovered late and marketing needs left out. Strategies and OKRs help create the big picture which helps focus on the end result.
Use MBIs and create a well defined intake process
Eli Goldratt (creator of Theory of Constraints) once said “often reducing batch size is all it takes to bring a system back into control.” Using MBIs is often the most straightforward way to do this. If you only do one change to your process I’d suggest it be use MBIs.
If the CTO/CIO and/or product managers are driving then you can start here even if C-Level folks aren’t.
Adopt a well-defined intake process
This is perhaps the most important item to attend to. A well-defined intake process can be used to avoid overloading the development group. It also puts some pressure on product management to select the most important items to be worked on.
Takes too long to get anything done. This is helped by controlling how much work is in process. A proper intake process also can load balance the teams better.
Ineffective budgeting. Having a clear intake process makes it easier to control the capacity programs and teams are given to different MBIs. Budgeting is made easier by having clarity on what is being proposed to work on.
Shadow IT. There are two kinds of ‘shadow IT.’ One is when business stakeholders have their own people and do their own development. This is not necessarily bad. It is mostly a problem when this work is improperly done and not able to be well handed off. Another is when work is done off the record. This causes many problems because when this happens it is not possible to manage work in process.
Chunks of work too big. An intake process is used to ensure items being worked on are of the proper size.
Poor intake process. Well of course.
Work items not sequenced. This is part of a quality intake process.
Working on too many things. One of the parts of a good intake process is to limit how many things get started.
Insufficient specialized skills. There will usually be people who are required for many different initiatives. By having a well defined intake we can control which work items get started in a way that doesn’t overload these people.
Lack of coordination between teams. Controlling the amount of work should make coordination easier.
Integration errors. The intake process can adjust the workload so that teams can integrate better.
Ops blindsided and pulled in many directions. An intake process that uses MBIs will include the work for Ops. It also gives ops a way to decide what to work on.
Marketing needs left out. An intake process that uses MBIs will include what’s needed for marketing to do.
Effective Program Formation
Create effective teams
Cross-functional teams are almost always the best choice, but they are not always possible to form. Often a combination of almost cross-functional teams along with the use of kanban boards for those who have to share people with critical skills is required. Having effective teams is a critical aspect of Agile.
Use ATDD to define the sprint backlogs
Writing small, well-defined stories is hard for most Agile teams. The fact that they are usually not taught this until the the second or third round of training is one of the biggest mistakes I believe organizations make in moving to Agile methods. Regardless of who is driving, this should be in the first line of training.
Program Level Planning
Have teams collaborate and integrate
There are several ways teams should collaborate. SAFe has one, but there are several others. I’ve included a few in part V of this book.
There are several ways that teams can collaborate. A common one is to have a common cadence and integrate either continuously or no less frequent than at the end of the cadence. This is best used when teams are mostly using Scrum. It is possible to coordinate with a more pure flow model as well.
Challenges improved by properly coordinating shared services
Use DevOps and create a relationship with marketing and support
DevOps is growing in popularity and for good reason. However, it is not much more than a specialized way to do Lean flow. Doing the same for the relationship between development and test is equally important.
Attending to Release Needs (Marketing, Support, Telemetry, …)
Challenges improved by improving developer’ skills
The next FLEX course is currently being scheduled in August 2019 in southern Orange County, CA.
If you want to learn more about FLEX you can take an online course at the Net Objectives University.
If you want to learn about how to adopt FLEX in your organization please contact the author, Al Shalloway.