If you’re thinking adopting Scrum for product development will improve your business, you would not be alone. According to VersionOne’s latest State of Agile Report, Agile adoption continues to rise with Scrum being the most popular. The top reasons for adopting Agile have remained constant over the past 3 years:
- Accelerate product delivery
- Enhance ability to manage changing priorities
The top three real benefits of adopting Agile has remained steady over the past 5 years:
- Ability to manage changing priorities
- Increased team productivity
- Improved project visibility
However, the number one reason Agile adoption fails remains:
- Company philosophy or culture at odds with core agile values.
What’s clear is a number of businesses take on Agile without considering the impact and the challenges facing the business environment. Before you and your company launch yourselves into the subtleties and complexities of Agile and Scrum, consider these two points:
- Are you clear what business problems Scrum will solve and
- What corporate or cultural attributes could stand in the way.
Here are three scenarios:
When the company decided to run a project using Scrum, the decision was based on previous track record of failure to deliver on schedule, at cost, and with the agreed to scope. The company felt they had nothing to lose by going Scrum. After successfully running an experiment with one team, all teams soon adopted Scrum.
The company wanted to start a new project using Scrum, based on the promise of faster and predictable results. Agile implementation was ultimately unsuccessful for a number of reasons including Command & Control culture and product decision-making not pushed down to the Scrum teams. Management couldn’t give the Scrum team autonomy or empowerment.
A company thought themselves as an Agile organization but the business and business culture was top down Command & Control. Product decisions were in the hands of management and not pushed down to the Scrum teams. Management needed to maintain control of the Scrum teams and couldn’t give them autonomy or empowerment.
All three of these companies are successful and all have good products and good people but not all could fully adopt Agile values and principles. For Agile to be successful, it’s best if the company has a culture and environment to support Agile, or at least a culture and environment that doesn’t clash with Agile values.
Agile and Scrum isn’t the answer in all cases and isn’t necessary for company success. However, Scrum can help a company be more successful. Scrum is particularly hard since many behaviors and cultural changes might be needed. If the business is willing to change the way it works then adopting Scrum may be easier but still does not guaranteed a happier outcome.
To help guide your move to Scrum, here are some questions that need to be answered. The idea isn’t that the corporate culture and environment be perfectly aligned with Scrum but that you have a clear understanding of what impediments and huddles you can expect.
- Do the executive officers of the business (CEO, CFO, CTO, …) believe Agile is a viable way forward?
- What business needs are to be fulfilled by adopting Agile?
- What core business assumptions (cultural or ‘way we do things around here’) are challenged by adopting Agile?
- Beyond the ‘nuts & bolts’ of Scrum, what business processes need to change to adopt Agile?
- Does the [new] business strategy support Agile?
- How well will Scrum fit into the current Product Lifecycle?
- How well does Scrum fit into the business’s current planning and budgeting processes?
- How much effort (training/coaching) is involved bringing product management, development, marketing, sales, and executives along on the Agile journey?
Do the executive officers of the business (CEO, CFO, CTO, …) believe Agile is a viable way forward?
In general, executives need to have a compelling reason to try new methodologies. If they already believe Agile is the way forward you’ll have an advantage to start but they may not recognize the efforts necessary for success. It’s up to you to make a compelling case for Scrum or do as I had done, run an experiment using Scrum and let the results speak. In either case, there must be a real business problem to solve. Solving a real problem drives innovation and inspires an innovative spirit. Tying company growth e.g. sales, profitability, customer base, to Agile is crucial but may be hard in your organization. There exists lots of anecdotal evidence of the value of Agile but hard evidence of a specific formula is elusive.
“The top three benefits of adopting agile have remained steady for the past five years: manage changing priorities …, team productivity …, and project visibility”.
If the experimentation route is open for you then take advantage of this to demonstrate Scrum. I wrote a post, Agile: Don’t Sell It, Demonstrate It, describing how experimentation was used to help the company recognize the value of Scrum and what results could be achieved.
It will help too for you to have an understanding of why Agile might fail. Here’s an article in InfoQ that can give you some insight on problems that may arise including understanding what Agile is about. Forewarned is forearmed.
What business needs are to be fulfilled by adopting Agile?
Do your homework to determine what business challenges or needs can be fulfilled by introducing Agile. Change usually requires a motive force and in business this usually lies in the company’s strategy and goals. For example, let’s say the company wants to increase their sales to customers 35-55 years old. Using Scrum and weekly releases, the Scrum team can run growth experiments and get prototypes (or real products) in front of the targeted people for user experiments. The team can quickly determine if they’re building the ‘right product’.
In another example, the business goal is to gain more positive testimonials from customers. The Scrum sprint review is an ideal event that involves customers and elicits customer feedback.
This business connection might be the difference between management allowing Scrum into their shop and having management enthusiastically embrace Scrum. As mentioned in the post, Agile: Don’t Sell It, Demonstrate It, full acceptance of Scrum might require tangible evidence.
What core business assumptions (cultural or ‘way we do things around here’) are challenged by adopting Agile?
It’s is important to ‘know your enemy’. By far the biggest obstacle to Agile adoption or expansion in your organization will be the company’s culture.
In VersionOne’s 10th Annual State of Agile Report respondents cite
“organizational culture and a general resistance to change as their biggest barriers to further agile adoption.”
In their book “Blue Ocean Strategy,” W. Chan Kim and Renee Mauborgne cite four hurdles that face a manager trying to institute broad change in an organization
- people must have some understanding of why the change in strategy or in culture is needed
- changing an organization will require shifting resources away from some areas and towards others
- workers have to want to make the change
- institutional politics.
If you’re a member of the company’s corporate management team, you need to work toward solving for these hurdles. If you’re a Scrum Master, Product Manager, Agile Project Manager, or mid to lower level manager, you’ll probably need to seek an executive sponsor.
Beyond the ‘nuts & bolts’ of Scrum, what business processes need to change to adopt Agile?
Do an audit of current business processes and make a determination of which of these support your Agile adoption and those that can slow down or inhibit Agile adoption. Some of the process changes I did with the first Scrum project:
- How is was: The business’s initial full list of requirements defined the release content. Change: Review requirements with the Team Lead and Product Manager to remove requirements that didn’t add immediate value i.e. remove all the ‘nice to haves’.
- How is was: Product Architects dictated how to implement stories to the developers. Change: Developers held responsible for implementation and consulted with Product Architects if needed.
- How is was: Developers/UXD approached Product Manager to decide if display changes should be done. Change: Developers/UXD would make display changes based on acceptance criteria and demo to Product Manager at end of each day.
- How is was: Business was not involved day-to-day with the development team. Change: Senior managers attended the daily standup meeting to show support and to understand what problems the team had.
- How is was: The development team’s daily progress wasn’t available to the business. Change: Place the sprint board on a big wall in a prominent viewing area.
None of these changes occurred without some trauma but they were each done. Their cumulative effect was the successful adoption of Scrum.
As Scrum Master, Product Manager, or Agile Project Manager, changes need to be explained but often this will not be enough as people resist change on the emotional level. For example, one developer said he was working a task but the task wasn’t on the sprint board. When asked to put it on the board and explain it he wasn’t able to do so. What actually happened was the introduction of the Sprint Board with all its visibility was highly stressful to a development team who, until then, operated in the dark so to speak. If the developer was confused on a way forward, it was OK because no one would know. What saved the day was the lack of blame and recrimination from management and the Scrum team’s overall desire to progress and be successful.
Does the [new] business strategy support Agile?
Richard Rumelt in his book, Good Strategy/Bad Strategy: The difference and why it matters talks about company strategy as having three distinct components. These are:
- A diagnosis that defines or explains the nature of the challenge. A good diagnosis simplifies the often overwhelming complexity of reality by identifying certain aspects of the situation as critical.
- A guiding policy for dealing with the challenge. This is an overall approach chosen to cope with or overcome the obstacles identified in the diagnosis.
- A set of coherent actions that are designed to carry out the guiding policy. These are steps that are coordinated with one another to work together in accomplishing the guiding policy.
Agile and Scrum neatly falls into the ‘Guiding Policy’ step, the overall approach towards solving a business problem.
I’ve never been in a position to define a company’s strategy but that doesn’t mean I couldn’t influence it. As Scrum Master, Product Manager, or Agile Project Manager, if you have access to the executive team, you can help make Scrum part of the strategy. However, getting an Executive Agile Coach for your industry might prove a better way forward. An Executive Agile Coach can better speak and understand the language of the executives. Without Scrum being part of the business strategy it can quickly become a sideshow.
How well will Scrum fit into the current Product Lifecycle?
A while back I wrote the Product Lifecycle document for a waterfall organization. Along with describing dozens of processes, it identified the decision makers for each step. For these gates in the lifecycle, one or more department (development, product, sales, marketing, support, executive, finance) would need to sign-off before proceeding to the next. Lots of decision makers but no one responsible. The Lifecycle document is based on good intent to guide a project but the detail was such that deviation, even slightly, was hard. Very unagile.
With Scrum, be prepared to rewrite the Product Lifecycle document (or remove it entirely) to accommodate the shift in responsibility to the Scrum team. In general, the Scrum Guide’s descriptions of the Scrum framework will replace the waterfall Product Lifecycle. The Scrum team takes center position with making product decisions and solving customer problems to grow the business.
How well does Scrum fit into the business’s current planning and budgeting processes?
If your organization has traditionally followed a waterfall paradigm, it’s likely that a single individual managed the project and was held accountable for cost and schedule. In Scrum, the Scrum team collectively becomes the project manager and as a team, is held responsible for delivering value to the customer. Many businesses have the board and shareholders to answer to. Part of that is predicting revenue and profits based of medium to long-term plans, often aligned to quarterly, semi-annual, or annual reports. Being able to accurately predict deliveries beyond 4-6 weeks is hard. It’s better to have growth targets and adopt Scrum practices that support achieving these. Enter Growth Hacking.
Growth hacking is a process of rapid experimentation across marketing channels and product development to identify the most effective, efficient ways to grow a business. Growth hackers are marketers, engineers and product managers that specifically focus on building and engaging the user base of a business. Source: Wikipedia.
By adopting Growth Hacking as a business strategy, you and the team are working in the near term where you’ll have better visibility and control. You still work toward growth targets, the stuff the shareholders and business managers care about, but you and the team are focused on immediate value and goals.
Take a look at this site for some successful Growth Hacking stories.
How much effort (training/coaching) is involved bringing product management, development, marketing, sales, and executives along on the Agile journey?
Scrum cannot exist for long if only the developers follow it. The Agile values and Agile principles clearly require the entire business to support and respect Agile for it to be successful.
VersionOne 10th Annual State of Agile Report states that barriers to Agile success include:
The availability of personnel with the necessary agile experience
Other important factors included: externally attended classes or workshops, company-provided training program, online training and webinars, and full-time internal coaches.
When I first introduced Scrum, I provided training to everyone in the company. I somewhat tailored the training for teach department to make clear of their ongoing responsibilities to the Scrum teams. For example, Marketing attended the daily standups so art could be collected for brochures.
Adopting Agile is a serious undertaking where there are no guarantees of success but by getting the business managers behind you, your much more likely to succeed.
- Use experiments to showcase the possibilities of adopting Agile.
- Address your Agile adoption to specific business problems.
- Get executive sponsorship for adopting Agile.
- Expect to change existing business processes. Expect resistance and understand the emotional state of those who are being asked to change.
- Tie Agile to the business strategy and goals. Get an Executive Agile Coach to help the business leadership team understand Agile strategies.
- Prepare to change or discard your Product Lifecycle.
- Maintain long-term growth targets for shareholders and business managers. Use near term Growth Hacking techniques to help achieve these goals.
- Provide the necessary training to the business to help all facets of the business better communicate with the Scrum teams.