Disciplined Agile

Using FLEX to Perform an Assessment for an Organization

This chapter focuses on an assessment for small-scale organizations. But it is also the starting point for organizations of any size. Later chapters include the factors to consider for larger organizations. The aspects of flow for larger organizations are essentially the same, just facilitated in slightly more complicated methods due to their larger size.

We define a “small-scale” organization to be when the development group is driven by a handful of product owners and many of the teams require some help from others. It is likely that some degree of shared services (e.g., business intelligence) and ops is used in common across the teams. The product owners are able to coordinate among themselves to provide a shared backlog for the teams to pull from.  Typically, the size of the development group is 25 to 125.

A key factor in achieving business agility is to have work flow through the system. To achieve flow requires minimizing hand-offs and avoiding delays in workflow, feedback and using information. It requires alignment across the value streams  and a collaborative organization. What it takes to achieve flow is well known. The challenges include changing the culture by changing management methods, having the roles required to create and continuously improve an effective ecosystem, and having the proper skill sets to do the work.

This list parallels the vision of an effective organization we discussed earlier. This chapter discusses what to look for and why.

In particular, here is what is involved in achieving flow.

  • Identifying, defining, sizing, and sequencing the work to be done. If you don’t work on what will achieve the greatest value being efficient at it is little consolation.
  • Having an effective intake process, planning method and dependency management. In order to not overload the development group an effective intake process is required to feed planning, be it incremental or via a flow method. This also requires having a clear dependency management approach.
  • Having quality value streams. If value streams intertwine with each other it will be difficult to achieve flow as the resulting conflicts will cause workflow delays that will cause feedback delays that will cause unplanned work.
  • Improving your workflow to remove delays in your value streams. The order of the workflow itself is critical in order to create clarity and achieve quick feedback.
  • Roles to manage the ecosystem. A key tenet of Lean is that you manage the system within which people work and not the people themselves.
  • Quality of the work. At all stages, high-quality work is essential. But, remembering what W. Edwards Deming says (“a bad system will beat a good person every time.”), it is important to focus on creating a good system.

Step 1: Prepare for the assessment

The first thing to do is to familiarize yourself with an effective value stream for a small-scale organization. This is shown in Figure 1.


Not all roles are shown, just the key ones of business architect, product manager and product owner. The question marks after the product manager icon is to represent that this is an optional role. Work starts at the upper left and progresses through the organization until work is completed, deployed and value realizes. Feedback loops are present but are not shown for clarity.

Step 2: See the Challenges Present in Your Value Stream


Challenges most organizations have

Figure 2 shows many of the challenges that most organizations face.

Fill out the table below with those challenges that affect your organization. Mark them on a scale from 0 to 3.

  • takes too long to get anything done
  • ineffective budgeting
  • shadow IT
  • chunks of work too big
  • poor discovery intake process
  • work items not sequenced
  • working on too many things
  • insufficient specialized skills
  • unclear requirements
  • poor development intake process
  • no line of sight to strategies and OKRs
  • lack of visibility of workflows
  • lack of coordination between teams
  • technical debt
  • integration errors
  • testing lags programmers
  • problems discovered late
  • Ops blindsided and pulled in many directions
  • marketing needs left out

While these may identify the challenges we also should go through different parts of the value stream and see how well we are doing certain things.

Step 2: Review strategic planning, OKRs and Initiatives

This is a critical first step to set up the work of the value stream. We find that most organizations have very well defined objectives.  But they are not always clear to those not working on creating them. The assessment here is based on:

  • Have the business stakeholders identified what they want the company to invest in and stated the key results they intend to achieve by doing so?
  • Is this visible to product managers and product owners?
  • Is this visible to people throughout the organization?
  • Is technology represented in this process?

Step 3: Review the  use of Minimum Business Increments

“There’s nothing quite so useless, as doing with great efficiency, something that should not be done at all. -Peter Drucker

Identifying, defining, sizing, and sequencing requires using the proper blend of MBIs, MVPs and MVRs. This allows setting up a well-defined intake process to help ensure teams are working on the items that will realize the greatest value for the clients identified by the organization to be most important to focus on. This is illustrated in Figure 3. Most transformations will require training for Portfolio Managers (and Product Managers if present) and for Product Owners.

Minimum Viable Products (MVPs) are in vogue now. If we take Eric Ries’ definition, these are intended to be used for new products for early adopters. But most small scale and above organizations spend most of their time working on enhancements to existing products. While the concept of the MVP is useful, it’s not quite what is happening most of the time. Driving with Minimum Business Increments (MBIs) is a much more effective method. An MBI is the smallest realizable chunk of value that makes sense to release from the business perspective. In must include all aspects of a release that will make the value realizable as well.

The following figure illustrates how business increments created by the stakeholders should be decomposed into MBIs to begin the requirements process.

If MBIs are not being used it is a certainty that work entering the development group will be bigger than it needs to be.

  • Are MBIs being used for extensions to existing products?
  • Are MVPs being used for new products?
  • Are MVRs (Minimum Viable Replacements) being used for replacing products?
  • Are features being defined within the context of the above questions?

Step 4: Evaluate the quality of the intake process

Perhaps the most important part of a value stream is the intake process. This is usually managed by a backlog that is created by product management/owners at the direction of the business that is intended to be used by the development group to see what to create.

Having a well defined intake process is critical to achieve flow.  Without it teams will be overloaded even if product owners don’t push too much work as new items come up. Integrated with the intake process is how people will plan their work. This “planning” may be for an increment or done via a continuous flow model.

Questions to ask to determine the quality of your intake process:

  • What percentage of new product work goes through it?
  • What percentage of enhancement work goes through it?
  • What percentage of maintenance work goes through it?
  • Why do things not going through the intake process not go through it?
  • How many shoulder taps or severity errors occur on a weekly basis?
  • Can people across the value stream easily see where the work they are doing originated?
  • Are properly sized chunks of work coming into it?
  • Does it provides visibility of all work taking place in the organization?

Step 5: Evaluate the quality of planning across teams

Planning is important and can be done in many ways. A popular method in the industry now is big-room planning, as adopted by SAFe (it originated at Salesforce with Pete Behrens). Big-room planning has all teams get together and plan out for several iterations. However, there are several ways to do effective planning. The main variable are:

  • whether planning is done in a batch or flow method
  • length of the planning increment if done in a batch
  • who does the planning

Which works better has many factors. These include:

  • the extent of business and technical dependencies across the teams
  • how well formulated Lean Product Management is at the organization
  • the level of Agility the teams have achieved

Regardless of approach, these are some things to consider when assessing the planning:

1. Is planning being done in a push or pull method?  That is, are product owners and team leads deciding what the teams will work from or are the teams pulling from a backlog. This should be done in a pull manner because:

  • it requires product owners to prepare the backlogs sufficiently (they are more aware of this when pull is used)
  • teams better understand their capacities
  • they own the commitment to do the pulled work more
  • this is part of the mantra of pushing responsibility down to where the work takes place

2. Is planning done to achieve maximum utilization? This typically will lead to non-resiliency – small changes will cause big problems.
3. Are features and stories properly decomposed and satisfy the definition of ready for a planning event?
4. Are the planners focused on minimizing cost of delay while identifying the sequence in which the work will get done?

Step 6: Review the extent Test-First requirements are being used

Quality can not be inspected into a product or service; it must be built into it.” – Edwards Deming

Test-first is often thought of as existing at the team coding level – Test-Driven Development. However, Agile methods now include both Acceptance Test-Driven Development (ATDD) and Behavior Driven Development (BDD) among even others. Using test-first methods to define requirements with all three roles (product owners/BAs, developers and testers) working together can solve most of the challenges organizations have with requirements. They should definitely be used.

Step 7: Evaluate the quality of the team process

The best measure of the quality of a team’s process is having a cycle time that is very close to the time work is spent on stories. Good team processes will have no interruptions for those involved from when a story is started until it is completed.

Step 8: Determine how often and why teams are being interrupted

By definition, interruptions stop flow. Interruptions may occur throughout the value stream. During the assessment, we are looking for unplanned interruptions that affect the team.

Here are questions to ask.

  • How much do we interrupt the team?
  • How do we interrupt the team?
    • Severity errors?
    • Shoulder taps?
    • Changing requirements?

Step 9: Review the extent of tech debt present and why it is present

The level of technical debt your organization has is important to attend to. If it is very high, simple changes will take much longer than they should and create risk to other areas of the system as well.

Step 10: Investigate the degree Unit Test-Driven Development is being used

Test-driven development is thought of as being done totally at the team level. However, having test-driven development follow from acceptance tests makes them more powerful. At a minimum, tests should be considered prior to writing code. Just thinking about it doesn’t take any time and can have a big, immediate impact. The next level is to write them prior to writing code. The best way to do this, of course, is to automate them and do test-driven development a la XP where tests go red and then green and red and green.

TDD with automation not only provides safety it increases code quality and reduces the time required for testing.

Step 11: Identify the dependencies between teams and how well they work together

To some extent there will always be dependencies across teams. The question is to what extent are they present and to what extent are they necessary. The fewer dependencies across the teams the better the quality of your value streams will be. These are illustrated in Figure 8.

The four main types of dependencies across teams:

  • Technical dependencies
  • Business dependencies
  • Architectural dependencies
  • Communication dependencies

You need to look at both dependencies across teams in the same primary value stream and any that are between some teams that are primarily in other value streams.

Coordination of teams begins with how teams pull work

Teams best coordinate when they pull work together or have some method of synchronizing what they are working on. So when evaluating how they work together start here.  Also, look to see if all teams are on a common time-boxing or cadence starting point. Time-boxing and cadence intervals are suggested to be one or two weeks. If they are mixed between two and three week time-boxes/cadences then ask the three week teams why they are on three weeks. If their answer has more to do with them (e.g., “we find two weeks is too cumbersome”) then you have some work on having your teams look at the bigger picture. What’s good for them may not be good for the rest of the group.

Step 12: Review the level of test automation present

Test automation not only saves time it makes changes and deployment safer. The more the better.

Step 13: Review the guidance being given Shared Services

Shared Services are those services that are provided to multiple teams. A common “shared service” is business intelligence. Shared Services often has the capacity to meet demand but is also often demanded to do a lot in a short period of time. This often has them be overloaded for short periods which wastes their time and causes delays throughout several value streams. To avoid this it is important for shared services to understand which requests they should work on (and not by who is screaming the loudest). Evaluating this is an important step in improving the value stream.

Shared Services are often placed in the situation of being told to do different things by different product owners. This causes many problems. The best solution to this is when shared services can see how the requests being made affect the cost of delay of what’s being worked on. This requires visibility to the portfolio backlog.

Step 14: Review the relationship between Ops and the rest of the organization

Figure 14 identifies where DevOps fits within the organization. As with any step in the value stream, a blockage doesn’t really matter where it occurs. DevOps has become very popular to attend to because Ops is often a serious problems in most organizations. But many delays in Ops are best viewed as symptoms of other problems.

Here are symptoms of problems that may be present.

  1. Lack of visibility on the work coming to Ops
  2. Little clarity on what’s important to be done
  3. Product problems

While DevOps is a way to create focus on these problems it is important that is a sense these challenges can occur throughout the value stream.

Step 15: Review how well is management is doing their job of creating a great environment within which teams can work

“A system must be managed. It will not manage itself. Left to themselves, components become selfish, competitive, independent profit centers, and thus destroy the system… The secret is cooperation between components toward the aim of the organization.” —W. Edwards Deming

The role of management is to create an environment within which teams can self-organize and get their work done effectively.

  • Management (in general) creates the ecosystem within which people can work effectively in a self-organizing manner
  • Middle management to look up the value stream to see the direction the organization wants to go and then look down the value stream to improve the environment development is working on. This is called “Middle-Up-Down” management.
  • TDM/RTE. The Technology Delivery Manager (called the “Release Train Engineer” in SAFe) are needed to coordinate teams in a value stream.
  • Value Steam Network Architects to coordinate how value streams work together.
  • Business Architects to coordinate the business dependencies between the value streams
  • Scrum Masters to coach teams to improve both their effectiveness and efficiency

Step 16: Review how well the roles are being filled and how well the  work together

All too much attention is placed on following a framework instead of how to work together.  How well are roles keeping the guardrails, either explicitly or implicitly.

The basic roles to look for:

  • product managers (if needed)
  • product owners
  • technology delivery managers (a mostly equivalent role to the release train engineer of SAFe)
  • team coaches (often called ScrumMasters)

Step 17: Evaluate the quality of the value streams

“All deficiencies in your value stream will show up as some form of delay.” – Al Shalloway

Achieving flow of value across a value stream requires:

  • Minimizing hand-offs
  • Managing Work-in-Process
  • Doing the work in the right order (such as test-first)
  • Creating visibility
  • Aligning the organization around value realization

Look for the above in the assessment. This is often causes (or exacerbated) by overlapping value streams. This directly causes interruptions, slow feedback, delays in workflow, hand-offs, and general chaos as unplanned work is created. Creating visibility on the workflow in current value streams assists in determining how to reorganize people so that they can work better together. Dependencies across value streams must also be managed. Consider Figure 5.

Here are some of the dependencies to manage.

  • Technical dependencies: when software created in one value stream directly calls software created in another value stream
  • Business dependencies: when one value stream has created some behavior or data used by another value stream but no direct call is made
  • Architectural dependencies: all value streams must attend to essential architectures
  • Communication dependencies: we must attend to communication channels, especially when teams are distributed

See worksheet Net Objectives uses as a first step in this evaluation.

Step 18: What Constraints do we have imposed on us from outside our business group?

We often don’t have control even within our business group. Our adoption to better methods may not include all of our value stream(s). When we have to work with outside groups that represent constraints on how we work, we need to pay even more attention to them.

  1. What groups outside of our business group do we work with?
  2. Do any of these constrain how we work?
  3. Are there units within our business group that we have to work with that constrain us as well?