Failing implementations of Scrum
In the previous four subsections, you have learned how Scrum implementations fail from lack of executive sponsorships, foundations, agile mindsets, and communications and training programs. In the remainder of this section, you will learn how to resolve the impediments that hinder the successful enterprise or product-level deployments of Scrum.
I've touched on this subject before, but the empirical process control mechanisms of Scrum provide a practical approach to resolving Scrum implementation issues. However, the Scrum Teams cannot resolve most of the issues identified in this section as they don't have the authority to address issues outside their direct product development-related activities.
Therefore, the organization must establish an enterprise-level Scrum CoE or some other type of organizational Scrum implementation resources to resolve issues that require executive-level decisions. These decisions include issues associated with business and organizational alignment, hiring, people management, compensation plans, and investments in infrastructure, tools, training, facilities, and funding.
Adding roles that are not part of Scrum
Scrum Teams only employ three roles, ever. These are the Product Owner, the Scrum Master, and the Developers. The founders of Scrum were very careful not to install structures that would create an overly competitive environment that is not conducive to team building. Any organization that adds additional roles is not truly practicing Scrum. Moreover, another risk from adding roles is organizational bloat and a return to hierarchical and bureaucratic processes.
Focusing on the wrong product backlog items
Given the product-oriented nature of Scrum, there has to be someone responsible for making decisions and ultimately held accountable for the success of the product. To be held accountable, they must have the authority to make decisions on product backlog items and priorities. That is the role of the Product Manager.
There is only one Product Manager assigned to each unique product. In some of the scaled-Scrum approaches introduced in Section 2 of this book, the Product Owner may enlist the help of assistants or Teams of Product Owners working under a Chief Product Owner or Product Manager. For now, let's keep things simple. The Product Owner is the only decision-maker regarding product backlog priorities.
Not even the company's chief executive should override the decisions of the Product Owner. For sure, Chief Executive Officers (CEOs) and LOB executives, customers, end-users, development team members, and other stakeholders will undoubtedly have opinions and seek to influence decisions. Still, there can only be one decision-maker, and that is the person who ultimately has responsibility for the organization's Return on Investment (ROI) for the product.
Product Owners are the voice of the customer. A successful Product Owner recognizes the customer's interest must come first. If a prospective customer is not happy with a product, they will not buy it. Customers have varying needs and will value different features and functions, price points, performance, and quality uniquely. The challenge is in identifying the right set of product features and functions and priorities to make the product commercially viable.
A product with a large prospective customer base and multiple market segmentation will have a larger pool of requirements options to consider for each Increment. As mentioned in previous sections within this chapter, the Product Owner must work though a multi-dimensional problem that evaluates the size of the market for each identified requirement, the Incremental value to customers for each satisfying requirement, and the cost of producing and delivering each requirement. They must resist every attempt by outside influencers to change priorities that do not fit Scrum's value-based product backlog prioritization model.
Allowing inappropriate priorities
You may think that surely the CEO can change the priorities in the product backlog. However, unless the chief executive is the Product Owner, the answer is no; the CEO cannot change the product backlog items or priorities. The Product Owner cannot allow outside influencers to arbitrarily make decisions on product backlog items and priorities that do not fit the highest-value/lowest-cost prioritization model described previously, no matter who the influencers are.
Product Managers who are weak or ineffective will make bad decisions. For example, they may add low-value items with unsubstantiated priorities within the product backlog. Conversely, they may add items that appear to have high customer value but are not cost-justified given what the target market is willing to pay for them. Or the Product Owner may make an error by purposely choosing to prioritize the development of many low-cost items that have relatively little Incremental value, instead of focusing on the development of higher-value items.
An effective Product Owner understands the scope of knowledge and work that goes into building and sustaining a viable product backlog. When a Product Owner fails, it's likely the hiring chief executive or LOB executive who under-scoped the breadth of skills and cross-functional knowledge required to perform in the role of Product Owner successfully.
For example, the Product Owners must have credible domain knowledge to understand customer issues, capability requirements, and priorities thoroughly. To stay on top of the market trends, the Product Owner needs to spend the bulk of their time meeting with customers, industry analysts, end-users, and stakeholders. Ideally, the Product Owner should seek out opportunities to speak and present at industry forums and become a recognized thought-leader within the industry.
The Product Owner must have the business domain knowledge to assess product pricing strategies accurately, as well as costs, and value. They must have marketing skills and knowledge to understand how to identify target market customers and how best to promote their products. The Product Owner must be a competent business development specialist who can identify new market niches and product opportunities. The Product Owner must also know about sales, including the use of inside and outside sales organizations, and the use of channel partners such as Value-Added Resellers (VARs), systems integrators, consultants, Managed Service Providers (MSPs),?Original Equipment Manufacturers (OEMs), and distributors.
Do the Product Owners do all of this work alone? No, of course not. They are the ultimate decision-makers, but they must have access to functional efforts to pull the information together they need to make the right decisions. If the Scrum implementation effort is limited strictly to development activities, the Product Owner will access corporate resources in the functional departments. However, if the organization is implementing Scrum enterprise-wide, the Product Owner can establish functional Scrum Teams to provide support across sales, marketing, partnerships, and other critical product life cycle activities.
In short, the Product Owner must be a capable and knowledgeable jack of all trades whose responsibilities encompass the entire scope and breadth of product management. The Product Owner spends a relatively small amount of time directly supporting development-oriented Scrum events, requiring somewhere on the order of only 25% of their time. The Product Owners need time to work in parallel with functional or, more ideally, Scrum-based teams supporting marketing, sales, partnerships, distribution, and other business functions critical to the product's market success.
Directing instead of leading
A common mistake is to place a Scrum Master into a development team based on their technical skills, domain knowledge, or project management experience without making sure they are adequately trained and clearly understand their role. None of those skills are requisite justifications for hiring a Scrum Master. The potential problem is the Scrum Master with such skills may assume authoritarian control over the Scrum Team, which is in opposition to their role in Scrum.
The roles of the Scrum Masters include providing mentoring, coaching, and serving. The Scrum Master provides mentoring and coaching on Scrum practices to the Product Owner, development team members, and any other stakeholders whose views and actions can affect the product development priorities and work. In this role, the Scrum Master monitors decisions and activities, and steps in to provide guidance when the actions are taken or proposed are inconsistent with Scrum.
Moreover, in the role of a servant leader, they help the development team to resolve any impediments that would otherwise distract the team members form to complete the goals of each Sprint. In other words, the authority of the Scrum Master comes not from directives but from their knowledge, their ability to provide guidance, and their desire and ability to serve the team as opposed to leading or directing the team's activities.
Scrum Masters who approach their job as technical leaders make the mistake of trying to exert influence as the arbiter of technology, architecture, design, and development decisions. Such actions fly in the face of both agile values and Scrum practices, where the team as a whole determines the best approach to developing each new Increment of functionality. Scrum Masters who cannot resist influencing technical and development-related decisions should reconsider if they are better suited to working as a development team member.
Scrum Masters coming from a project management role need to understand they are no longer responsible for project planning, scheduling, or prioritization of work. Scrum Masters do not monitor work to control or direct the execution of work. Only the development team, operating as an independent, fully functional, and self-contained unit, can decide how much work they can take on within each Sprint.
If the Scrum Master helps to create the burndown and velocity charts, it is Done in their role to serve the team by allowing the team to stay focused on their value-added tasks. The Scrum Master never develops charts to direct the team's activities. They develop the charts so that the development team, its Product Manager, and other stakeholders can make informed decisions.
When I say the development of burndown and velocity charts are non-valued added work, I don't mean to imply the charts have no value. But the charts are measurements only and do not directly contribute to the development of a new Increment of functionality. On the other hand, the charts are part of the information radiators previously discussed that help to provide transparency and facilitate inspection and adaption processes. So, the charts have value, even though they do not directly contribute to the development of the project.
An easy way to think about value-added versus non-value-added work is to ask yourself whether the activity directly contributes to the construction of the product's Increment. If not, then the work is not value-added from the customer's perspective. The work may be necessary or useful as a vital information radiator item, but the development team cannot let such activities get in the way of developing the Increment. As a Servant Leader, the Scrum Leader steps in to help the team.
Likewise, rather than use the information from the burndown and velocity charts to micromanage and direct the team's progress, the Scrum Master provides the information freely and without judgment and as an aid to the team's decision-making process. The goal of a Servant Leader is to help the team to obtain the information so they can assess the progress of their work and their capacity as a team.
Having risks and issues are the norm and not the exception when developing large and complex software and IT-aided systems. Risk management is the reason Scrum implements the concepts of empirical process control. It's impossible to know or plan for every contingency that affects a development project. In some cases, the development team responds directly to address any issues that arise. However, the Scrum Master should work through any issues not directly related to the act of designing and building the Increment. They may schedule fact-finding meetings or need to resolve other issues that affect development team member participation.
Performing non-value-added activities
The fastest way to kill an Increment is to allow the development team to get sidetracked on non-value-added activities or work. Non-value-added work is any activity that does not directly contribute to the development of the current Increment of functionality as required to achieve the Sprint Goal. Activities that can take away the development team's focus includes the attendance of non-relevant meetings, working on development tasks or other activities not related to the current Increment, and working on issues best resolved by the Scrum Master. Over-engineering a product beyond what is required to achieve the Sprint Goal is another example.
The timeboxed events of Scrum (for example, Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective) provide maximum transparency while minimizing time spent in non-value-added meetings. The Scrum Master helps to ensure the teams stick to the scope of each event and within the time boundaries. When an additional discussion is required to resolve a development issue, the impacted development team members should take the meeting offline and allow the other team members and meeting participants to get back to their work.
In an ideal situation, the development team has a typical area in which they work as a team. The co-location of team members facilitates the display and use of information radiators, paired programming, and breakout sessions to discuss requirements and architecture, design, and coding issues. The developers need access to networks, computing systems, and software development tools. I also personally believe people need time and space to think without distraction and to decompress. Having cubicles or individual desks within or adjacent to the shared meeting room provides that individual space.
Scrum development teams are self-organizing. That means they must have the authority to evaluate the work necessary to fulfill a Sprint's goal and make individual assignments based on priorities, time, skills, and interests. Scrum development teams are self-contained. That means each team must have the skills necessary to complete all work. Since Scrum development teams are limited in size, the individuals must value learning new skills and developing competency in multiple skills. New product requirements and new technologies and tools will expand over time the skills needed to develop the team's assigned products. As a result, employee compensation and incentive plans must support the multi-learning objectives of Scrum.
With all of these constraints in mind, the development teams cannot afford team members who are specialists. Still, there will be times when the need for a new skill is immediate, and the team may not have the expertise needed to develop a new Increment of functionality. In those cases, the team must have access to specialists on a time-limited basis. Those specialists may come from an internal group or hire through outside contractors. However, in the longer term, assuming the new skills become an ongoing requirement, the development team should build the skills in house.
Allowing team burnout
A critical issue that comes up time and again is burnout of Scrum development team members. This issue happens when the Scrum Masters, Product Owners, chief, or LOB executives exert too much influence on individual Scrum goals and over commit the developers. Only the development team can make commitments on the scope of work they can take on during each timeboxed Increment and plan the work tasks necessary to achieve the Sprint Goal.
Executives, Product Owners, and Scrum Masters who do not recognize the development team must have the final say on Sprint Goals and work tasks make two mistakes:
They have not understood that value trumps functionality.
They have not understood the importance of transparency.
In the first case, Product Owners who focus on making value a priority understand that releasing something customers want and will pay for is more important than waiting to implement a product with the most features and functions. The 80/20 rule is a prime consideration, as we've learned previously that ~20% of a product's features provide approximately 80% of the product's value. The other 80% of the identified prospective backlog items are expensive and time consuming to deliver and offer little value in return to the customer.
In the second case, transparency is critical as it provides timely and accurate information for accurate decision making. Transparency enables trust, which is why Scrum's three pillars of empirical process control, transparency, inspection, and adaptation, are so important. The organization's executives and Product Owners may question whether the development team is putting their full effort toward meeting their target release dates. Such concerns are reasonable and open for discussion. However, interference with a team's decisions is not. Only the Scrum Team can adequately access the scope of work they can take on within an Increment. But the Scrum Team also has a responsibility to provide sufficient and accurate information to have informed conversations.
For example, if the Product Owner or executives have concerns about the team's velocity, they can have a conversation to see whether there are external impediments that are limiting the scope of work completed within each Increment. It also might make sense to evaluate the economic feasibility of adding additional Scrum Teams to help to work through the product backlog.
Failing to provide full transparency
Scrum development teams, when properly implemented, can determine the amount of work they can complete withing an upcoming Sprint. They must have the authority to make decisions on workloads. But they must also show accountability through the visibility of their velocity charts and by meeting their commitments.
Besides the Scrum events, velocity and burndown charts and other useful metrics provide evidence of the team's ability to both judge and complete the work they have committed to complete within each Sprint and planned for future releases. Over time, the development team builds a profile of their capabilities by estimating the work they can complete in each Sprint, often expressed as story points, and then tracking their performance against their estimates. The team charts this data across each completed Sprint. The measure of their performance, expressed as story points per Sprint, is called velocity, and the charts showing velocity over time are called velocity charts.
Burndown and velocity charts are not the only items that provide transparency on the team's activities and capabilities. The team can employ any number of handwritten, drawn, printed, or electronic displays of their work and their decisions. For example, they may have the User Stories written on 3" by 5" index cards and posted on a Scrum Board to show those that are in a queue, work in progress, tested, and Done. They may have architecture and design drawings displayed on whiteboards or flip charts. They may also draw out the screen displays, application reports, and screen navigation features. Test scripts and test results should be displayed.
There is no limit to what can be displayed so long as the information is useful and relevant. Such information, when publicly displayed for all to see, is referred to as an information radiator.
Continuing development beyond economic value
We can think about this issue in another way; how many features in a mature word processing application do you use, let alone across the entire suite of products? As an author, there may be certain features I use more than you might in a word processor. There may be other features you use that I do not. Other users will have different feature sets they prefer. The question is how many features have the team implemented that do not have sufficient economic value to justify the effort?
One of the primary roles of the Product Owner is to look at the intersection of our needs and other market opportunities, to determine the sweet spot for maximizing value at the lowest production delivery costs. See Figure 3.2 on ‘Word Processor Application Needs’ as an example. The Sweet Spot identified in the graphic offers the maximal economic return to the organization's investments in the product as it includes the subset of features desired by all types of customers.
That's not to say the sales opportunities within the author, market, or your collection of needs might not economically justify further investments. The Product Owner needs to gauge whether features should all go into a generalized product or whether it might be better to offer niche variants of the product. A generalized product costs less to promote, sustain, and sell. However, niche products may avoid turning off customers who believe the full-featured product has become too complicated. Niche products may also support a higher price and a higher ROI.
The Scrum Teams stay together for as long as the addition of the new features and functions continue to add value sufficient to justify continued investments. Of course, the product's accumulated costs continue to increase with added development activities. But that does not matter so long as the revenues from new product sales and from existing customers for maintenance, support, and upgrades offset the ongoing costs of continued product development activities.
Failing to support market segment opportunities
Some products have a large and diverse customer base. The Product Owner, working with the product's marketing staff, segments their market opportunities based on groupings of common characteristics, such as customer demographics, interests, needs, and locations. The Product Owners follow the same rules of prioritizing identified backlog items with the highest-value and lowest-cost.
Take a quick look at the graphical example of Figure 3.3 – Market Segmentation Priorities – Intersecting, which is a generalized view of the graphic presented in Figure 3.2. You can see there is an area of overlap where the customers' needs span all three market segments, for example, the Sweet Spot! From Increment to Increment—this is the area where the Product Owner knows they can maximize sales opportunities:
At some point in time, the developers may complete the implementation of all features within the intersecting needs of the three marketing segments. Now the market segments must carry their weight to justify further development investments.
The reason for pointing this out is that markets are seldom this easy to segment. For example, Figure 3.4 displays a situation where target market segment two does not intersect the customer needs of either target market segments one and two. There is a sweet spot among the needs of the first two market segments, and that may be a logical place to start development.
However, what do you do if the customers in segment three will pay more for a product than the customers in market segments one and two? Be careful here. The easy answer is to assume we'll build the product for segment three customers. However, the needs may be so unique and challenging that the development costs outstrip the additional revenues.
In the meantime, perhaps segment two customers will pay more for additional features, beyond the sweet spot, that are relatively simple and inexpensive to implement. Now the Product Owner should consider making those segment two features a higher priority, along with those identified in the sweet spot:
The bottom line is that, across Increments, the product backlog may include items that address the needs of one or more market segments. There still is only one product backlog. Also, the Product Owner still makes the priorities based on the highest-value/ lowest-cost prioritization model.
Regardless of the situation, when producing a new release for a product with multiple market segments and niches, your marketing and sales campaigns must be in sync for each new release. Otherwise, your company may not achieve the sales goals that justified the investments. In other words, the Product Owner cannot solely focus on development priorities; they must also make sure the rest of the product marketing, sales, delivery, and support functions are operating in sync.
Pushing deliveries beyond capacities
Companies exist because there is a profit incentive to create things that customers want. The same paradigm holds for government agencies and non-profits. Rather than profit, legislative mandates and goodwill drive government agencies and non-profits to create products and services their customers want. Motivation is useful in that it drives our economies and citizen support systems.
But unbridled motivation can also destroy a company by releasing products and services that are not ready for delivery. When we are not honest, disaster follows—usually in missed delivery dates, cost overruns, and reduced profitability.
Here, again, the answer is transparency. Product Owners need to determine and communicate the identified product backlog items with the highest customer-centric value. The Scrum teams need to make visible their capacities to deliver. Executives need to communicate to investors and their customers the organization's capacities and plans to deliver.
Putting undue pressure on the development teams will not fix the problems of misinformed expectations. Moreover, putting more pressure on the development organization is likely to backfire, creating stress and long hours that hinder the team's performance. The developers need to work at a sustainable pace or they will burn out and mentally and emotionally check out.
The development team's primary focus must continuously remain on only providing the highest value product features with the lowest cost, across each development iteration. But that statement also assumes you have a legitimate market opportunity and capacity to deliver within a competitive timeline. If your competitors beat you to the market and your organization does not have a compelling and unique value proposition, then, most likely, your company shouldn't be making this product or service anyway.
Failing to work as a team
This subsection discusses a catch-all area of behaviors that can hinder the success of a Scrum Team. For example, a dominant team member may seek to lead instead of jointly collaborating on critical decisions. The Scrum Master needs to get involved and mentor the team member on more effective ways to work with their team members.
Some team members may not pull their weight at work. For example, a team member may be late to Scrum events or may not adequately participate and engage in the development work. They may also have a limited skill set and may not learn new skills that would otherwise help the team to more efficiently self-organize, be self-sufficient, and evenly allocate work across each Increment.
The team can positively address these concerns with the individual during their Sprint Retrospective meetings, though the discussions need to remain respectful to retain the integrity of the team. If the member is defensive or non-responsive, the Scrum Master needs to get involved, listen to everyone's concerns, and see whether there is a resolution that works for the individual and the team.
Failing to evolve the product Incrementally
Sometimes, a new product concept is enormous in scope and complexity, making it difficult to immediately assess the features, functions, priorities, and architecture and design requirements. And, in some cases, it may be difficult to refine the vision without some experimentation. But how is the team supposed to proceed in those cases?
After all, without a solid vision and specific product goals and objectives, the development team can't know how to get started. If they start on development, they can't know what they need to deliver. Finally, without a complete vision, the team won't know whether they are off track working on items that have little or no value.
Still, we have to start on something. Though it may be tempting, it's not a great idea to put a new product out to market too quickly. It's much better to build a series of prototypes until the functionality reaches a stage that the product has enough value to attract customers and end-users.
I'll admit, this approach is not textbook Scrum. But as digital remove systems continue to merge into increasingly complex products, we need to manage our risks. It takes time to figure out what our customers want, and releasing a product before it's ready will do more harm than good. It's better to set expectations correctly upfront with customers, stakeholders, and investors.
Keeping the development focus on continually delivering only the highest-value Increments allows the product to mature gracefully. It also provides that fastest path to deliver a viable release.
The value-cost development priority model does not change. The Product Owner still defines a prioritized list of requirements within the product backlog. The development team works through the product backlog as expeditiously as possible, but not to the point of exhaustion and burn out. It's the CEO's job to manage shareholder or customer expectations. As mentioned in the Scrum Team burnout section, productivity will go down if the work pace is not sustainable, and your best people will leave.
By definition, prototypes are potentially disposable products. The reason for this is the developers, the Product Owner, and the paying customer or executive sponsor must be able to walk away from an early architecture or design that cannot meet the business goals that justified the investments. Modern evolutionary architecture concepts help to address these risks by allowing the architecture to emerge in lock-step with the product.
Prototypes also allow the customer to provide early guidance from customers and end-users. The team should find out early on what the customers and end-users do not like or want in the product so that they can cut their losses and remain focused on developing the features and functions the customers do want. The development team works through multiple development iterations until the baseline product can justify a release of the product to customers. The Product Owner decides with input from targeted customers when the product is ready for release.