Why You Suck at Scrum: The Development Team

When organizations try to incorporate an Agile way of working such as Scrum, they typically want to change the process in which they work so they can realize the benefits that moving to this way of working provides.

Examples of these benefits usually include:

• Delivering faster to the market
• Realizing ROI sooner due to faster delivery
• More closely meeting customer needs
• Having the ability to pivot to a new priority with new information

Here are examples of how groups looking to move to a framework such as Scrum fail when it comes to their delivery teams, and the impediments they create to achieving the outcomes they desire.

Teams Remain Matrixed

Few organizations that are looking for the outcomes listed above understand that there is more than the process that needs to change to get where they want to go, they also need to change the way they are organized. A term I’ve heard many times in my coaching is ‘Agile Project Mgmt’, which normally translates to, ‘how can we make minimal change to the way we work and are currently organized, and still take advantage of this ‘Agile thing’?

Many project oriented companies have their teams organized by function, similar to an assembly line, resulting in handoffs throughout the process, and generating painful planning and adjustments when necessary. These ‘teams’ are large pools of single skilled, single focused individuals, that provide one piece of the puzzle needed to complete a specific piece of work over a specific timeframe. These pools of people add up to a total capacity for that skillset, that is then siphoned off for each project, until that pool’s capacity has been depleted for the given timeframe. When this max capacity has been reached, any remaining projects that have not been ‘fully staffed’ get bumped to the next time frame when the pool is ‘refreshed’, typically after the previous projects that were using those people have been completed, they will now be available. (Visions of the 70’s gas shortage come to mind, with cars waiting for hours to get to the pump, only to find out the gas ran out 4 cars before you could get there)

The many problems with this type of approach look something like this:

• All lines of business are typically competing for capacity from these ‘teams’
• Each LOB most likely has their own priority of importance for their projects, that most likely don’t align across LOB’s or the organization as a whole (meaning my #1 and your #1 might actually be #3 or #4 in the overall company priority)
• When we compete for this capacity, we will inevitably end up bumping projects out that may have added value to their LOB, and possibly the organization, however we will never know, as they will probably continue to get bumped for other, larger shiny objects. Worse, they will finally get prioritized, but when they do, they will have missed the market opportunity window that would have made it worth doing in the first place
• When we compete internally like this we all lose, sometimes most of all our customers. The world moves too fast to wait until the next project cycle (sometimes a quarter, sometimes 1–2 years) to implement an improvement that our customers want or need now. It will cause your products to stagnate, and your customers will go to a competitor that can keep up with the pace of the market
• Individuals on these ‘teams’ have a singular micro focused view of their work, and miss how it may fit into the big picture
• Handoffs of work between the ‘teams’ cause dependencies and waiting, or waste, and delays from one ‘team’ to the next have a tidal wave effect on the entire delivery timeline
• New information gained during the delivery cycle that requires a change in direction feels like moving an entire fleet to a new objective, and to avoid that pain often results in pushing those changes to ‘phase 2’ of the project (which is just code for the bucket of stuff we know we will need to fix or adjust, but we can’t now because of the friction that the change would entail)

Do these problems sound familiar? I’d bet real money they do. And yet, when companies state they want to move to a more Agile way of working to achieve the outcomes listed above, they fail to realize their very way of working and organization of their teams are what is causing them from achieving those outcomes:

• Delivering faster to the market?

You won’t get there if there is an abundance dependencies & handoffs in your process .

• Realizing ROI sooner due to faster delivery?

You won’t realize ROI any sooner if you don’t make the changes needed to align your teams and work without competing internally for the same people’s time.

• More closely meeting customer needs?

You’ll miss this mark if it takes too long to get something in the hands of your users and get feedback on the solution you provided.

Worse, you may never meet some customer needs if you never get the opportunity to create a solution (aka your project didn’t get prioritized).

• Having the ability to pivot to a new priority with new information?

You won’t be able to turn on a dime for a dime if it costs you thousands to reshuffle an entire project portfolio when you realize you need to change direction or meet a new need.

Teams are not cross functional, or organized around products

To build on the last topic, if you remain matrixed and componentized, you will inevitably suck at your Scrum implementation. The measurement of success or failure in this context can be simply determining if you realized the outcomes you were hoping for as outlined above. So far, the answer will be ‘no’.

Another way to impede your progress is to fail to organize around products, and fail to get out of the ‘project’ mindset. Sure, you may be able to stay organized the way you are, and create projects the way you do, and still possibly achieve some level of Agile benefits. You may be able to introduce transparency into your work, therefore identifying some level of waste in the system. You may be able to increase some form of cross team collaboration, possibly spotting dependency issues sooner. You might incorporate some form or a mechanism for continuous learning & improvement, gathering more frequently than you had previously, possibly identifying areas for improvement in your current processes.

What you will most likely fail to get is the more robust changes in your outcomes that you desire. If you treat adopting something like the Scrum framework for product delivery similar to the way most of us approach weight loss, you will only get a fraction of the results you are seeking. When most of us approach weight loss (myself included), we see and hear the complete set of changes we should adopt if we wish to see the best results. Complete changes look like some combination of diet and exercise. Sure, if you change only your diet, you should see some results. Conversely, if you start to exercise but don’t change your diet, it’s better than if you did neither. But to get the most bang for your buck, you need to do both, you need to commit to real change. But change is hard, we like what we are comfortable with, our routines.

One of the biggest and most difficult changes that will have the impact you are looking for, is to reorganize out of your matrix teams, and organize your people and skillsets around products, and form real teams to those ends. If you want to almost guarantee your failure at a Scrum adoption, or move to product delivery, you won’t make this change. You’ll keep your warm blanket of the status quo, the way you’ve been organized for years, and pass on the opportunity for real change.

When teams are stood up to be long lived, cross functional (having all of the skillsets needed to bring an item to ‘done’ on a single team), and dedicated to products or product lines, you will eliminate the impediments to you achieving the outcomes you desire:

• Delivering faster to the market?

This smaller, focused team can work with your product area to identify problems to solve, and then identify potential solutions for those problems, and then move on them without friction from competing with other product areas to see how their idea measures up with all of the other potential ideas and then trying to find someone to work on them. The team is already there, waiting for the next big idea.

• Realizing ROI sooner due to faster delivery?

Less friction with competition will allow teams to plan incrementally and get incremental solutions out to the market, potentially realizing ROI on what is able to be delivered while the next incremental change is being worked on, with no fear of the team being poached for a newer, bigger project before they have the opportunity to improve on the solution

• More closely meeting customer needs?

When the team is aligned to a product, they inherently get aligned to a customer base that uses that product, and they start to learn what the users needs are, and in time, may even be able to anticipate future needs. They start to build product & market subject matter expertise due to their ability to focus

• Having the ability to pivot to a new priority with new information?

When this team hears that there is a new priority based on new information that differs from what they were working on, there is an easy pivot to the new thing. This change will not require the overhead of tying off a project in progress, spinning up a new project, gaining approvals for all of the ‘in/out’ of scope items, budget approvals, people alignment changes, etc. The team and the Product Owner can start making progress immediately on the new priority, as what they are working on & how they work is controlled within the team, not project steering committees that only meet on a scheduled timeframe with an abundance of paperwork to justify the change that is already painfully obvious.

The Team is not heard when they say they want to start working this way

Sometimes the biggest impediment to change are those that are not even doing the work. These are the people that fear a new way of working might make their job more difficult, because they will have to change as well. They will have to change the way they communicate, they will have to embrace empowering their teams to find the best solutions to the problems, and no longer dictate how things will be done. These are the people that have been incentivized up until now to ‘drive success’, to develop the plans that should be executed by the teams.

When the team doing the work requests to make a change in how it is approached, that will put them in a better position to be successful, and they are not heard and or dismissed with talk of ‘we do it this way and have always done it this way’, this is an impediment to change. If this level of management is not brought into the process of change, they will resist, and your adoption will fail.

Listen to the people closest to the work, closest to your customers, and you will increase your chances of success.

If you are attempting an adoption of an Agile way of working such as Scrum, please do not overlook the importance of committing to real change, even if it causes short term pain & friction by doing something such as reorganizing your teams and product areas. This realignment will ease your pain in the long run, and set you up to achieve the outcomes that you desired from making the move to this way of working in the first place.