POS

Case Study—Valpak

BACKGROUND

Established in 1968 and headquartered in Largo, Florida, Valpak is one of the leading direct marketing companies in North America, owned and operated by Cox Target Media (CTM), a subsidiary of Atlanta-based Cox Media Group (CMG). In addition, Valpak has one of the largest collections of digital coupons on the Internet with thousands of local products and services, as well as national brands.

Working in partnership with its network of nearly 170 franchisees in the United States and Canada, Valpak helps more than 54,000 businesses a year to achieve their marketing goals. Valpak's primary competitors are Money Mailer, Valassis (Red Plum), and Super Coups. Valpak's secondary competition includes newspapers, television, Yellow Pages, and any other forms of advertising. All in all, Valpak is trusted by consumers and merchants alike to consistently deliver value. The Blue Envelope® delivers savings and value to nearly 40 million households each month. Annually, Valpak will distribute some 20 billion offers inserted in more than 500 million envelopes. Valpak also offers digital solutions with  www.Valpak.com ®, an online site for printable coupons and coupon codes, which has nearly 70 million offer views each month, as well as apps for smartphone platforms.

Valpak's IT group builds and supports technology for a wide variety of stakeholders and audiences, including consumers who are focused on saving money with coupons, Valpak franchises that need systems to run their business and sales operations, merchants interested in tracking and maximizing their returns on investment, and traditional internal corporate stakeholders that need to run the core business operations. Efforts for these distinct audiences include:

· To some companies, it may simply mean moving from a waterfall-style development process to adopting a more agile development approach.

· To others it may mean transforming the way the whole company operates. An example is America Online (AOL). Years ago, AOL used to be a dial-up modem company, but as the Internet technology changed, AOL recognized that it needed to transform the very nature of the company to survive. It needed to shift from being an Internet service provider offering dial-up modem access to a fast-paced provider of media content in order to shift its value proposition to continue to attract subscribers. That required changing the way the whole company operated, in addition to implementing a much more agile process to rapidly develop new media content. They used an overall agile transformation driven top-down by their CEO to transform the whole company to focus on delivering very-high-quality media content to the market quickly. 1

· Some companies may be far along the agile adoption curve, trying to move on to the next level; and

· Some may be just starting out.

· We were able to successfully build a partnership with the government client in which we did a very professional job of managing overall contractual requirements at the macro-level.

· Within that  macro-level envelope, we were still able to implement a fairly agile development approach at the micro-level.

· Increasing the level of predictability and control requires beefing up the macro-level, providing more detailed requirements at that level, and implementing at least a limited amount of change control.

· To increase the level of agility, you can simply eliminate the macro-level altogether or limit it to only very high-level requirements.

· Other elements of the framework can be easily customized or eliminated depending on the scope and complexity of the project and other factors.

· The standard implementation uses a model very similar to Scrum for managing the development effort, which uses a prioritized product backlog to drive the development process, and the work to be done is broken up into iterations.

A more advanced implementation uses a lean approach, eliminates the iterations, and replaces them with more of a pull approach that allows work items to be addressed whenever there is capacity to work on them.

· Valpak franchises: Order entry, office management, mobile/online sales tools, and CRM applications are developed to support Valpak's 170+ franchise locations located in the United States and Canada. These franchises are independently owned and operated locations that utilize Valpak's franchise system to sell Valpak print and digital products to local merchants.

· Consumers: Savings/coupon applications and websites are developed that provide daily value to consumers looking to save money on their purchases. Consumers can interact with Valpak savings  anywhere at any time, regardless of whether they are using Valpak's traditional “print” mailer or one of Valpak's several digital channels (web, mobile, SMS texting, e-mail). Valpak's savings content is also distributed to over 150 partner websites as well.

· Merchants: Online websites and mobile applications are developed to allow merchants to manage their advertising campaigns with Valpak.

· Corporate: Traditional back-office operations, including manufacturing, marketing, finance/accounting, order processing, and sales. The IT group develops and supports various ERP and custom application solutions to automate these back-office operations.

Valpak's ability to utilize technology to transform their business is a very significant factor in their business success, and Valpak's IT group is an integral part of the business transformation and growth of the company. To compete with the quickly changing digital savings marketplace, Valpak transitioned the entire IT organization to agile Scrum/Kanban processes with two-week sprint delivery cycles. They embraced this change and quickly adapted. This effort was so well done in the IT organization that Valpak is now driving the agile culture throughout the company, heading toward “The Agile Enterprise.”

As director of agile leadership at Valpak, Stephanie Stewart 2  has been responsible for leading the agile transformation. In this role, she is responsible for process facilitation, portfolio governance, program management, project management, and of course, oversight of related people, processes and tools. Stephanie leads the team of agile project leaders, who handle everything from project management to Scrum mastering to leading Kanban teams. A self-admitted agile enthusiast, Stephanie has worked passionately to encourage and support the IT organization at Valpak in fully embracing agile software development, to move Valpak toward a greater vision of “The Agile Enterprise.”

Chris Cate, CIO, is the agile executive champion working with Stewart and the executive leadership team in transforming the company over the past year. Cate also evangelizes “The Agile Enterprise” vision by encouraging the adoption of agile values and the use of agile methods for non-IT departments.

Bob Damato, director of software engineering, led the adoption of agile technical practices such as test-driven development, continuous integration, and evolutionary architecture. Strong leadership for technical practices across teams has been critical to maintaining and improving quality as part of the agile transformation.

OVERVIEW

Valpak's overall enterprise-level approach is based on the Scaled Agile Framework, 3  which is shown in  Figure 15.1  (see  Chapter 15 ). The Scaled Agile Framework (SAFe) consists of three primary layers:

1. Portfolio layer: The portfolio layer is the highest and most strategic layer in the Scaled Agile Framework, where programs are aligned to the company's business strategy and investment intent.

2. Program layer: The Scaled Agile Framework recognizes the need to align and integrate the efforts of multiple teams that are engaged in large, complex enterprise-level development efforts to create larger value to serve the needs of the enterprise and its stakeholders.

3. Team layer: The team layer forms the foundation of the Scaled Agile Framework and is where the fundamental design, build, test activities are performed to fulfill the development requirements for each major area of business. At Valpak, there are actually two different development processes that are used in the team layer, as shown in  Figure 19.1 . In most cases, Scrum is used for more exploratory development, while a Kanban process is used for  run the business kinds of development.

Valpak implemented the SAFe from the bottom up:

· In October 2011, Valpak started with six Scrum teams and three Kanban teams at the agile teams (bottom) layer of the SAFe (Valpak currently has 10 Scrum teams and 3 Kanban teams).

· Shortly after the agile teams were established, Valpak implemented road-mapping and release management with the middle layer of the Scaled Agile Framework in mind.

· Most recently, Valpak implemented the portfolio Kanban at the top layer of the Scaled Agile Framework with their leadership team of executive sponsors.

· Last but not least, Valpak added the architectural Kanban.

There are two key things that are most significant about this case study:

1. Valpak recognized the need to adapt the agile development process at the team level into an overall enterprise model that is well integrated with their business. Valpak is one of the initial pioneers in the use of the Scaled Agile Framework to provide that integration.

2. Valpak also recognized the need to use a Kanban process for  run the business efforts, instead of Scrum, which is used for exploratory development, because the needs are very different.

Both of these efforts show real thought leadership to fit a methodology (or combination of methodologies) to the business and projects instead of force-fitting the business and projects to a predefined, textbook approach.

Architectural Kanban

The  architectural Kanban is a recommended practice in the Scaled Agile Framework (SAFe) that was implemented by Valpak. It recognizes the need at an enterprise level to plan and implement consistent and well-integrated architectures across all teams and projects.

This approach defined by the SAFe consists of defining architectural epics, which are “large technology initiatives that are necessary to evolve portfolio solutions to support current and future business needs.” 4

FIGURE 19.1 Valpak agile process framework

According to Leffingwell, sources of architectural epics can include the following:

· Mergers and acquisitions, which require technological integration

· Technological change and infrastructure obsolescence

· Performance and scalability challenges of existing solutions

· Cost and economic drivers, such as avoiding duplication of effort

Leffingwell says these are “initiatives of epic proportions,” because they typically cut across three dimensions:

1. Time: requiring multiple PSIs to implement, perhaps taking up to a year or two to complete

2. Scope: affecting multiple products, applications, and solutions

3. Organizations: affecting multiple teams, programs, business units, and even external entities” 5

At Valpak, architectural epics are captured in the architectural backlog, which is part of the architectural Kanban system. They are processed through various states of maturity until they are moved to implementation. According to Leffingwell, the following are the primary motivators for using this architectural Kanban approach at Valpak:

· Make the Architectural Epic backlog and ongoing analysis visible to all.

· Provide WIP limits to ensure the architects and teams analyze responsibly, and do not create expectations for implementation or timeframes that far exceed capacity and reality.

· Help drive collaboration amongst the key stakeholders in the business and Development Teams.

· Provide a quantitative, transparent basis for economic decision-making for these most important technology decisions. 6

Table 19.1  shows how the architectural Kanban board is organized at Valpak.

TABLE 19.1 Architectural Kanban Board

The “Value Stream Stage” indicates the stage of progress of each architectural Kanban epic (“Development” often involves the Scrum and Kanban teams helping to implement the architectural epic for their area of concern).

The “Swim Lane” rows in the Kanban chart indicate how the architectural epics are grouped by area of focus.

The architectural Kanban board is made highly visible to all teams and provides work-in-progress (WIP) limits on each of the stages in the Kanban process. Weekly standups are held with the architects to review progress and discuss any issues.

Portfolio Kanban

The  portfolio Kanban is a recommended practice in the Scaled Agile Framework that was implemented by Valpak. The purpose of the portfolio Kanban is to provide a way to plan, prioritize, and manage a portfolio of business epics. “It brings visibility to upcoming work as well as work in process, helps facilitate product development flow and can be a key factor in achieving enterprise—as opposed to team or program—agility, and thereby more fully optimized business outcomes.

According to Leffingwell, the Kanban system is used in this context to accomplish several purposes:

· Make the strategic business initiative backlog (upcoming business epics) fully visible.

· Bring structure to the analysis and decision making that moves these initiatives into implementation, and make that process visible to all.

· Provide WIP limits to ensure the teams responsible for analysis do so responsibly, and do not create expectations for implementation or timeframes that far exceed capacity and reality.

· Help drive collaboration amongst the key stakeholders in the business, Architecture and Development Teams

· Provide a quantitative, transparent basis for economic decision-making for these, the most important business decisions. 7

The implementation of the portfolio Kanban at Valpak included:

· Highly visible (physical) Kanban board; however, no WIP limits were applied at the portfolio level because it wasn't found to be meaningful.

· Portfolio Kanban standups held with executive sponsors weekly. Each executive sponsor addresses any board movement of epics and any major decisions made.

· Definition of an epic:

· ≥ 3 sprints of effort

· ≥ 3 agile teams to coordinate

· Considerable corporate, franchise, or market value/impact

· The portfolio Kanban is reset at the beginning of each new quarter based on the output from an executive quarterly planning meeting called the Portfolio Review Board (PRB) and based on retrospective improvements identified. PRB focuses on planning only; status and day-to-day collaboration is left to the portfolio Kanban process.

· Value stream (includes entrance/exit criteria) on portfolio Kanban includes  funnel, vet, design, build, deliver, and  done. Build is usually when the epic is being developed by the Scrum or Kanban teams.

· The  funnel is divided into “current quarter,” “next quarter,” and “unplanned,” so that everyone knows what epics have been planned for and what epics have come up that were not in the last quarterly plan. Epics not in the quarterly plan are subject to dot voting.

Challenges with the portfolio Kanban have been:

Standup derailment risk: There is too much talk about strategy or decision making or solutioning during the standup. The director of agile leadership facilitates them; without that facilitation, they tend to fall apart.

Executive schedules: Executive schedules are always busy, so not every executive sponsor shows up every week. Valpak tries not to cancel portfolio Kanbans if two or more executive sponsors are available.

Definition of an epic: There was initially some confusion over what an epic was and if it deserved to be on the board (versus a strategy or a feature or a story). Valpak recently settled on a definition of an epic for this purpose.

Tying strategies to epics: A list of all active business strategies has been established to tie to the epics on the portfolio Kanban. The goal is that strategies spawn one or more epics, and epics are managed via the portfolio Kanban process.

PROJECT MANAGEMENT APPROACH

Valpak has implemented the Scaled Agile Framework (SAFe) very closely. The SAFe does not recognize the concept of a “project”; however, Valpak does have a handful of projects wrapped around large cross-team efforts. For those projects, Valpak assigns an agile project leader to work with the relevant Scrum Masters, product owners, and stakeholders to pull it all together, but there are only about a handful of these projects running at any given time. Most work (even work that crosses multiple teams) can be managed by collaboration among the product owners and Scrum Masters for the agile teams.

At Valpak, projects are represented by epics, and each epic has an executive sponsor. Epics are managed via the portfolio Kanban process (described earlier). The portfolio is planned and prioritized quarterly using these epics. In most cases, epics require the work of three or more Scrum / Kanban teams to accomplish and therefore have more than one product owner involved.

Some epics also have important business tasks to be managed as well (not just a technology effort). For this kind of large epic, Valpak assigns an agile project leader as a project manager to coordinate the work of the business and the agile teams. A waterfall type of schedule may be applied to a project (which is typically the case when you have to fold in the business tasks); however, it is still an agile project management approach overall.

Where project management is needed for large cross-team efforts, the agile project leader will create a project plan (schedule) or a roadmap to represent all the teams, sprints, and business tasks involved with the effort as well as significant milestones. Even though project management may be applied, the agile values are still top of mind for the agile project leaders. This might mean a light roadmap versus a lengthy project plan; in other words, the agile project leaders plan and document to the needs of the project at hand. They apply the degree of project management that produces the most value and expect that the plan is certain to change.

Valpak uses four levels of planning:

1. Daily: Scrum team standups in front of task boards

2. Biweekly: Scrum sprint planning (all teams run on a common sprint schedule with sprint planning on a Monday and the sprint reviews on a Friday, two weeks later)

3. Monthly: Release planning across Scrum teams (product owner-level planning with a six-month look-ahead)

4. Quarterly: Quarterly plan of epics (executive sponsor-level planning that fuels the portfolio Kanban for the upcoming quarter)

Valpak has learned to fit the project management methodology to the type of project:

· Scrum is used for most exploratory development and currently consists of 10 teams aligned with each of Valpak's major areas of business focus.

· Kanban is used for run-the-business type of work and/or areas that are not conducive to or don't require the highly prescriptive nature of Scrum.

· Infrastructure projects and large-scale corporate projects are managed as waterfall with some of the Scrums and Kanbans producing work that supports those projects.

According to Stewart:

There is no one-size-fits-all methodology; at least not that I know of … Project Managers need to be more versatile and flexible than ever before. PMs need to be able to effectively pivot between command-and-control and servant leadership focused facilitators. Even though I love working with agile teams right now, I also know your run of the mill Traditional project when I see it. I've learned to pivot between the two by applying different soft skills. Traditional is all about directing and managing whereas agile is all about serving and facilitating. 8

Tools, communication, and reporting

The following is a summary of Valpak's approach for tools, communication, and reporting:

· All Valpak agile teams maintain physical boards in a common area. Scrum teams use a task board format to display their stories and tasks and show their progress each day. Kanban teams have boards with their custom value stream, and sometimes swim lanes for further classification of work. Additionally, Valpak uses Pivotal Tracker for Scrum teams to manage its backlogs and sprints.

· To assist with managing cross-team dependencies, each product owner tags stories (in Pivotal Tracker) with noted dependencies on other teams. A report is distributed each week that shows these dependencies so that product owners and teams can coordinate and collaborate accordingly.

· On the day after sprint planning Monday, two reports are distributed:

· Sprint accomplishments (from previous sprint) and

· Sprint goals (for current sprint)

· On sprint review day, an e-mail of sound bites of accomplishments for all Scrum and Kanban teams is sent to a broad group of stakeholders.

· After the product owners perform their monthly release planning process at the feature level, a one-page view is distributed with six-month look-ahead.

· After the Valpak executives meet for their quarterly planning of epics, a one-page view is distributed with a four-quarter look-ahead.

· After the last grooming session of the sprint, each Scrum Master sends out a quick list of proposed stories, anticipated to be planned into the next sprint. These are highly subject to change but help product owners and stakeholders to see what's coming to better coordinate and collaborate across teams.

CHALLENGES

Cultural and organizational challenges

Table 19.2  is a summary of the key cultural and organizational challenges faced by Valpak and how they were handled.

TABLE 19.2 Solutions to Cultural and Organizational Challenges

Challenge	Solution
Managing Cross-Team Dependencies Valpak has very highly integrated systems. In establishing the agile teams, it was almost impossible to create teams that could operate independently of any other teams. In most cases, teams are dependent on one another for a given feature or epic. The most common dependency at Valpak is between Valpak's BI Scrum teams and all other teams, since just about everything involves the ability to track and report.	Besides continuous cross-team collaboration and communication, Valpak has implemented: · Cross-team dependencies report distributed each week based on dependencies tagged in Pivotal Tracker · Proposed stories distributed week prior to new sprint · A meeting referred to as the “Scrum Powwow” held each week with product owners and Scrum Masters to discuss current sprint, next sprint, and roadmap dependencies · Visibly flagging dependencies between teams on task boards · Shared acceptance criteria prior to or early in sprint · Better planning and coordination of handoffs between teams · Allocation of time prior to the sprint for proper discovery and architecture across impacted teams for large/complex cross-team epics · Cross-team post-planning standup with the impacted teams the day after sprint planning to sync up stories/tasks and collaborate early
Accountability at the Top Since SAFe was implemented bottom up, the agile teams were in place well before the portfolio Kanban. Prior to the portfolio Kanban process, there were major disconnects between the executives and the product owners. Mixed directives and conflicting direction was coming from the top, leaving product owners and, therefore, teams with roadmap whiplash.	· Executive sponsors named for each Scrum team to establish accountability and ownership at the top · Product owners meet regularly with executive sponsors on their upcoming sprint plans and roadmaps · Portfolio Kanban established · Quarterly planning of epics · Weekly executive-level standups in front of portfolio Kanban board · Executive sponsors frequent the sprint reviews · Retrospectives held with executive sponsors to look for improvements
Product Owner Collaboration Collaboration can be just as difficult for product owners as it is for the teams. At first, product owners were very comfortable working within their own teams. However, where there were dependencies with other teams, there were often collaboration issues between product owners.	· At first, a Scrum-of-Scrums meeting was held for 15 minutes each week in the task board common area with product owners and Scrum Masters to review dependencies and their progress. · The Scrum-of-Scrums format becomes difficult beyond five teams, so Valpak evolved to the “Scrum Powwow” format. The Scrum Powwow is a one-hour meeting held each week with product owners, Scrum Masters, architects, and other IT leaders to collaborate on dependencies for current sprint, next sprint, and roadmap across teams. · Product owners look for proposed stories distributed each week for dependent teams; product owners have access to one another's backlogs in Pivotal Tracker. · A cross-team dependencies report is distributed each week that helps product owners to manage dependencies with other teams.
Franchise-Based Company Valpak is a franchise-based organization. This means that while products and features may be released more quickly under an agile framework, they aren't necessarily adopted, utilized, or sold any quicker by the franchises. Rolling out new products and features to Valpak's franchise organization takes considerable planning and support.	· Valpak's sales and marketing organizations are becoming more and more agile to quickly enable franchises with new products and features. · Training and communication are happening more quickly and frequently than ever before to keep up with the agile releases. There will always be those franchises that are slow to adopt new products, new tools, and new features; however, Valpak is pushing as hard and fast as possible to roll out new products and features. If the product or feature proves to be valuable, most franchises will get on board.
Managing Stakeholders At Valpak, stakeholders are anyone who isn't the team, the product owner, the Scrum Master, or the executive sponsor. This means that stakeholders are at all levels of the organization and all departments across the business. Stakeholders also include Valpak's franchises and consumers; however, those particular stakeholders are represented indirectly by Valpak's sales and marketing organizations, respectively. Product owners had difficulty in managing the various, diverse stakeholders. Each product owner had dozens of stakeholders to deal with, each with their own needs.	· All stakeholders were given one-hour training on agile, Scrum, and Kanban. · Over time, product owners refined their approach to stakeholder management. Each product owner has a slightly unique approach based on the needs of their stakeholders. · Some product owners began regular stakeholder meetings with core groups to elicit their needs and keep them apprised of progress. · Some product owners require that their stakeholders submit a project request form (PRF) to articulate their stories in proper format.
Agile Culture Shift An organization's culture can't be changed overnight with a simple announcement like “going agile!” In fact, it can't be changed with just a kick-off and some training, either. Starting out with agile back in October 2011, Valpak had about 30% naysayers, 40% indifferent, and 30% enthusiasts.	· The culture that is  agile must be constantly developed and nurtured over time with every meeting, decision, action, and event that takes place across the organization. · To help implement this culture shift at Valpak, an agile coach was involved (three to four days a week on site) for about eight months. · To continue the culture shift, Valpak has agile excellence meetings with product owners, Scrum Masters, and IT leadership every other month to perform a retrospective of agile (a retrospective of retrospectives, if you will). · In addition, what was the old PMO was restructured to the agile leadership office, led by the agile leadership director supporting a team of agile project leaders. · To continue the culture shift momentum in fun and memorable ways, Valpak holds events with the agile teams and stakeholders like Xbox Kinect Fruit Ninja Tournaments. Most recently, Valpak held an Agile Roast for the first anniversary of agile at Valpak.
Developing High-Performance Teams With any agile transformation, teams start off by “doing agile”; following the basic mechanics without necessarily understanding or embracing the values. Such was the case at Valpak. All teams were trained and knew just enough to be dangerous.	Moving the teams from the basic mechanics of agile to truly high-performing teams; no longer “doing agile” but “being agile.” Valpak has recognized that developing self-organizing, high-performance teams doesn't happen automatically and requires leadership and continued support. “Agile is not about getting out of the way of your teams but rather staying involved as servant leaders.” 9

Technical challenges

Table 19.3  is a summary of the technical challenges faced by Valpak and how they were handled:

Other challenges

Table 19.4  is a summary of some other challenges faced by Valpak and how they were handled.

TABLE 19.3 Technical Challenges and Solutions at Valpak

Challenge	Solution
Lack of Continuous Integration (CI) No organization or structure around automated testing. No automated execution of tests.	· Valpak implemented continuous integration where code is committed throughout the day with tests automatically run and errors sent to all developers to resolve.
Build Process Lack of structure and organization around build process. Build process was completely brute force and highly manual.	· Valpak's build process is now semi-automated and progressing toward fully automated with twice-daily builds to development and test environments.
Legacy Code Base At the beginning of agile, Valpak had a legacy code base consisting of over a half million lines of untested, unclean code.	Valpak implemented Test-Driven Development (TDD) methodology, along with clean code practices. Percentage of test coverage continues to increase with continuous support of TDD and clean code practices.
Architecture Role/Involvement Early on, the architecture role was not well defined. In addition, as a leftover from the waterfall days, teams did not feel empowered to make architecture decisions.	· Architectural Kanban · Architect and lead developer roles better defined · Improved collaboration between architecture and teams
Manual Tests / Quality / Risk No real automated tests existed, which increased the risk of quality issues as Valpak moved faster in delivering working software to the business. Releases required what Valpak calls “production checks” to ensure that everything was deployed correctly.	Valpak is currently in the infancy stages of QA automation using Selenium. Teams have begun to automate tests by including technical stories in each sprint.

TABLE 19.4 Additional Challenges and Solutions at Valpak

Challenge	Solution
Planning Sprints for Sustainable Pace Out the gate, no team had proper velocity measures. At first, teams planned too much into their sprints and ended up exhausted in trying to accomplish their sprint goals.	· Over time, the agile leadership office worked with teams to establish some best practices for keeping within their sustainable pace. · Most teams have a pencils-down day built into their ground rules in which no new development can be completed toward the current sprint. Stories may be dropped as a result, but sustainable pace is preserved. · All teams use a custom capacity calculator (spreadsheet) that was created to take into account non–sprint work like meetings, administrivia, and support in order to better estimate sprint capacity for each team member. · So as not to overcommit to a sprint, most teams use the concept of extra-credit stories. Extra-credit stories are established during sprint planning by the product owner as a stretch goal of sorts; if time and capacity allow, the team will complete them.
Decomposing Stories Teams are often challenged to decompose stories to fit within a single sprint and without breaking them down by task (develop, test, etc.).	Proper story decomposition can be more art than science. Through training and continuous coaching from Scrum Masters, product owners and teams learned to decompose stories better with each sprint.
Story Points Early into Valpak's agile transformation some teams still struggled with the proper use of story points. Many teams were applying story points as a measure of complexity rather than effort. In addition, some teams were applying hours to tasks and skipping the story point step altogether, which basically negates the benefit of this relative estimating technique.	Through training and continuous coaching from Scrum Masters, teams learned to think of story points as effort. Story points are a relative measure of effort to be done, not complexity, not priority, not sequence. Also, the point of improving Valpak's story point estimating is to someday stop having to think about hours.
Team Collaboration Spaces At Valpak, the software development organization has the advantage of being collocated in the same building. However, as a leftover from Valpak's waterfall days, team members were scattered about, which meant there were no team collaboration spaces.	· Just a few months after Valpak's first sprint, a massive office cube move was organized across 70+ employees to bring together team members with their teams into cube quad areas. · Within the cube quads, the inner walls of the cubes were taken down to create a “bullpen” for each team. · To top it off, creative signs were created for each team and hung over their cube areas. · With open spaces for each team, collaboration and osmotic communication increased dramatically.
Non-agile Tools · Prior to agile, Valpak used a traditional project management tool called @task. So, Valpak's agile process inherited a non-agile tool. This meant that sprint planning and backlog management were tedious and time-consuming exercises for each team.	· After an evaluation of several agile tools, Pivotal Tracker was selected. Pivotal Tracker was considered just enough tool for Valpak's purpose, remembering the Agile Manifesto value of “Individuals and interactions over processes and tools.” · Pivotal Tracker did not replace the need for physical task boards, which provide high visibility to the process that a tool can't match.
Predicting Release Dates In some segments of the agile community, it is not considered very agile to predict a release date and be held responsible for meeting that schedule. Because of the nature of the Valpak business, it was essential to be able to predict release dates with some level of accuracy.	Valpak adopted a strategy to predict release dates. “… by nature of time-boxing, the schedule is a fixed constraint. With the schedule being a fixed constraint (as is cost based on team size), it is scope that remains flexible. So, the scope that is included in any given release is flexible based on what the team was able to accomplish, what stories get dropped, what natural disaster impeded the team, who was out sick, and so on and so forth. Whether that scope accomplished is acceptable for release to production is always a product owner decision.” 10
Developing Agile Project Leaders Valpak recognized the need to define a new leadership role and job description for its project leaders so that someone in this position can assume the role of Scrum Master, Kanban leader, and/or project manager, depending on the work at hand.	Valpak created a new job description for an  agile project leader oriented around leadership of technology-focused projects and teams relying on agile values and principles. “The focus of this position is on delivering value over meeting constraints, leading the team over managing tasks, and adapting to change over conforming to plans.” 11

KEY SUCCESS FACTORS

Four factors helped make agile a success at Valpak.

Top-down support coupled with bottom-up drive

Taking the agile transformation seriously and supporting it at all levels of the business was essential to make the culture shift to the agile mind-set. Stewart explains:

Rather than continue to dabble with Agile, we went full-fledged, full-bore Agile (all software development teams all at once). Once our CIO declared that we were going Agile there was no looking back. He gained the support of our executive leadership team and they helped us to sell it to our stakeholders, including our franchise network. At first, there were some hold outs (the resistance) but with each and every sprint we have managed to convert a few more into believers. Whenever someone says, “Agile is not working for us,” I like to respond with “No, we are not working for Agile.” 12

Hiring an independent coach

Attempting to DIY (do-it-yourself) agile can sometimes backfire. You need to spend the money on bringing on an agile coach for about six months to train the teams and support the process. Companies often tend to appreciate the advice of an independent expert more than a trusted member of the company's own staff.

Continued support each and every day

Where agile has failed with other companies, it seems that it was done with a big one-time kick-off without continued support. Stewart continues:

· I think I read once that a culture change takes 10 years, so … We continue to support agile each and every day. That's my primary role as director of agile leadership, but I am well supported by it directors, product owners, agile project leaders, and even team members that have become great evangelists in their own right. The more you talk about it, the more they talk about it. Ways in which we continue to support agile here are things like:

· Agile Excellence meetings every other month (the retro of all retros, so to speak)

· Scrum Powwow each week (cross-team current sprint, future sprint, and roadmap discussions)

· Team Building (with Xbox Kinect Tournaments for agile teams to compete against one another)

· Celebrations (we did an Agile Roast for our first anniversary this month, and we have cake a lot for important sprint/release milestones)

· Agile tours given to special groups of stakeholders or VIPs on request

· Facility sponsor for Tampa Bay agile meet-ups, along with helping to secure speakers and topics

· Agile Manifesto and other agile-related posters highly visible throughout the IT work space 13

Stewart said, “It's fun to hear people dropping the  A bomb (that is, mentioning Agile) at large-scale events like our annual Coupon U with our franchises or corporate all-hands meetings. Agile is really a rock star around here!” 14

Senior management engagement/business ownership

Getting Valpak's senior management engaged and committed to the effort was a significant factor in the success of the effort. Chris Cate describes the process:

Valpak has fundamentally changed the way we get work done. This is not just a new process that only involves technology teams but more of a mind-set across all groups that puts an emphasis on driving real business value to our customers in short iterative cycles.

Business is deeply engaged with their products and services that they are asking IT to build.

· Business (Exec Sponsor and Product Owner) control the backlog and work output—they own it!

· They now have complete ownership and accountability—no place to hide.

· They are actively engaged in managing priority discussions with their customers to identify the highest valuable feature that the team should work on.

· The business is getting more work done across all teams.

· None of our business owners would ever go back to the older Waterfall process. 15

RESULTS AND CONCLUSIONS

1. More strategic management focus. The agile development process, using empowered, self-organizing teams, has enabled a major shift in the Valpak management approach. Cate explains it this way:

Conversations are fundamentally changing at the Sr. executive team level, focusing less on tactical implementation issues and more on strategic growth initiatives:

1. Do these things less

1. No longer have to justify and/or explain extremely large project plans (the Executive Sponsor and Product Owner decide the sprint schedules and backlog priorities and own it)

1. No longer have to talk about why IT missed a date or did not set expectations correctly between project team and Executive Sponsor (ES and PO own the priorities and expectations)

1. Rarely have to play the ‘peacemaker’ role between various groups now that the business firmly owns the work product

1. Started doing more of

1. Strategic planning and execution to grow the business

1. More involved in business development, partnership, and acquisition executions

1. Partnering with other Sr. team members to help them think through growing their business lines versus fixing IT 16

2. Management of IT resources. The shift to more empowered, self-organizing teams has also made the management of IT resources much easier. Cate says:

2. Less time needed to manage personnel issues since the process helps to correct this naturally

2. Teams are empowered to solve their own problems through collaboration, thus reducing functional manager activities

2. Much more open and transparent environment where the employees, or contractors, not fully contributing are identified and coached up or out quicker 17

3. Time-to-market. Valpak releases software to production at the end of every sprint. Time-to-market was significantly improved as a result of shorter iterations. With two-week sprint cycles, new/enhanced software was available more quickly than ever before to stakeholders, including internal, franchises, merchants, and consumers.

4. Alignment and collaboration. Alignment and collaboration between business and IT were increased as a result of a highly visible process. Product owners became truly accountable for their products and teams, and the “us versus them” mentality quickly disappeared.

5. Employee productivity and morale. Productivity and morale among the teams improved as a result of the empowered and self-organizing team's principle of agile. In fact, team morale and pride are greater than they've ever been at Valpak.

6. Delivering more frequent value to customers. A value-driven process is now in place. Decisions are made on what to work on based on value—that value is derived from stakeholder input. With two-week sprint cycles, teams deliver the highest value stories each sprint. Value is being delivered to stakeholders more frequently than ever before.

7. Openness and transparency. Teams, at the portfolio and architecture levels use highly visible task boards to track progress—anyone on the team or in the company can easily see a visual status of what stage of work each story / task is in at any time. In addition, teams know what they're going to be working on for the next two weeks, and all the teams have visibility into what the other teams are doing.

8. Responsiveness and adaptivity. Changes can be implemented more quickly than ever before. It is easier to change strategy and pivot. This makes experimentation and risk taking much more feasible. Being able to try out new ideas and turn on a dime is critical, not only for startups but also for larger companies that do not want to become obsolete.

9. Software quality. There is increased emphasis on Test-Driven Development (TDD), unit testing, and clean code. Continuous integration allows recognizing the impact of a change quickly.

LESSONS LEARNED

Forming projects around teams

Prior to Valpak's agile transformation, when a project was initiated, a team would be formed around the project. In most cases, the team members were already assigned to other projects. Stewart says:

So, with project plans changing as they do, a team member would typically end up being pulled in multiple directions, reporting to multiple masters, across many projects all at the same time. From a people perspective, this is not a fun place to be (remember, “multitasking” is the new four-letter word). The result was low morale from all the project whiplash going on. 18

With the new agile approach, Valpak shifted to “forming projects around teams.” There are 10 Scrums and three Kanbans. Stewart says:

We have naturally experienced a shift in our project initiation process. Now, when a project is requested, we evaluate the request based on the existing Scrum and Kanban teams, and  we form the project around the teams. Sometimes this means breaking up the project to fit the vision and/or skill of the teams. So, as opposed to forming a team around a project, we are now forming a project around teams. 19

Planning team capacity and developing a sustainable pace

Valpak's Scrum Masters needed a better approach to refine team capacity calculations during sprint planning and to allow for non–sprint activities (such as product support) that might require some of the team's time during a sprint. Valpak developed and implemented a team capacity calculator (spreadsheet) for this purpose, which factored in the amount of time each team member was actually available to work on sprint activities. Stewart describes the process:

During the planning session, we mitigate this risk by having team members predict their personal sprint capacity (50%, 80%, etc.), taking into account non-sprint meetings and a predictive measure of support. Also, we can further manage this by only working on support that our Product Owner deems immediate work. Any other support can be backlogged and planned into a future sprint. Now, should all hell break loose in the support arena, some stories may be dropped or some stories might not meet the team's definition of done. 20

Using sprint reviews and “science fairs”

There was a lot of difficulty associated with scaling sprint reviews to an enterprise level with multiple teams needing to hold sprint reviews with some of the same stakeholders concurrently.

Our first take at Sprint Reviews was pure madness! Each ScrumMaster would schedule a separate 1- to 2-hour meeting on the same Friday for each Scrum team. That's nine 1- to 2-hour meetings within an 8-hour business day [—] and on a Friday no less! 21

Valpak developed a common sprint review process accompanied by a “science fair” approach.

Reviews [were] shortened to 90 minutes, with each team presenting for just 10 minutes each. Within those 10 minutes, the Scrum Master provides a condensed version of the Sprint accomplishments and metrics, and the team demonstrates only the  sexy stuff … Following that 90-minute period, we hold a one hour Science Fair in the cube areas where the teams sit. Just like parents viewing student experiments at a school Science Fair, this hour is for stakeholders … to make the rounds at their own pace to each team they have an interest in for any given sprint. 22

1Jochen (Joe) Krebs, Presentation to the Agile Boston Group, February 2010.

2 http://www.linkedin.com/pub/stephanie-stewart/31/317/a01 .

3 http://scaledagileframework.com/ .

4Dean Leffingwell, “Architectural Epic Abstract,”  http://scaledagileframework.com/architectural-epic/ .

5Ibid.

6Ibid.

7Ibid.

8Stephanie Stewart, comments from “Podcast This Week”

9Ibid.

10Blog, “Release Dates in Agile Not Taboo,” posted by Stephanie Stewart, June 25, 2012,  http://iamagile.com/2012/06/25/release-dates-in-agile-not-taboo-4/ .

11Jim Highsmith,  Agile Project Management (Reading, MA: Addison-Wesley, 2010).

12Stephanie Stewart, personal e-mail correspondence.

13Stewart, personal e-mail.

14Ibid.

15Chris Cate, Cox Target Media CIO, personal e-mail correspondence, November 12, 2012.

16Ibid.

17Ibid.

18Blog, “An Agile Light Bulb Moment: Forming Projects Around Teams,” posted by Stephanie Stewart, April 20, 2012,  http://iamagile.com/2012/04/20/an-agile-light-bulb-moment-forming-projects-around-teams/ .

19Ibid.

20Blog, “Accountability to Sustainable Pace and Work/Life Balance,” posted by Stephanie Stewart, April 10, 2012,  http://iamagile.com/2012/04/10/accountability-to-sustainable-pace-and-worklife-balance/ .

21Blog, “Our Evolution of Sprint Reviews,” posted by Stephanie Stewart, June 13, 2012,  http://iamagile.com/2012/06/13/our-evolution-of-sprint-reviews/ .

22Ibid.