Join the Discussion
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.
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: Review strategic planning and Lean Portfolio Management
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:
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.
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:
Step 5: Evaluate the quality of planning across teams
Use figure 4 for this section.
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:
Which works better has many factors. These include:
Regardless of approach, these are some things to consider when assessing the planning:
Step 6: 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.
Step 7: 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 8: 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 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 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:
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 13 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.
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.
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:
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:
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.
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.
If you want to learn more about FLEX you can take an online course at the Net Objectives University or take a live course in Orange County, CA May 7-9 or in Seattle in June (both led by Al Shalloway). If you want to learn about how to adopt FLEX in your organization please contact the author, Al Shalloway