Sizmek Case Study

Inbar Oren!1

How Sizmek managed to reduce product release time from 6

months to 3 WEEKS, while improving quality and simplifying

processes

Introduction

!2

Sizmek is one of the world's leading providers of

solutions in the online advertising arena working

with some of the biggest agencies in the world. In

2013 they came to the conclusion that in order to

improve competitiveness they needed to completely

change their way of working and decided to embrace

Agile. They chose AgileSparks to help with the

transition.

!Considering the needs of the company, the

management team decided on bold moves

and drastic revolution rather than a small

incremental change approach, being fully

aware that this will be more difficult for

the R&D teams initially.

!

The implementation followed the five steps of the

AgileSparks way:

!★ Initiation

★ KickOff

★ Stabilize

★ Recharge

★ Improve

InitiateKick

OffStabilize Recharge Improve

Initiate

!3

We started with a management workshop to

understand the problems and agree on goals. The

management team decided on the following goals:

!★ Drastic improvement in quality.

★ Dramatic improvement in Time To Market.

★ Improved cooperation inside R&D and across

the company.

★ Empowerment and improved accountability of all

people in the organization.

!The implementation followed the five steps of the

AgileSparks way: Initiation, KickOff, Stabilize,

Recharge and Improve.

Sizmek operates in a complex technological

domain and as we often see in such

organizations, it was split into specialized

functional groups.

!The management team decided to

transform teams into cross-functional

Scrum teams, capable of delivering

functionality either alone or by

integrating with 2-3 teams at most. !Most teams were focused on customer

functionality while others retained their

specialization in order to handle more generic

infrastructure.

!

InitiateKick

OffStabilize Recharge Improve

Building Teams

!4

Each team had a Scrum Master who was in

charge of improving the team and overseeing

the functionality end to end. In addition, each

Scrum team had a Product Owner. Most were

the product managers but some infrastructure

teams had internal R&D POs.

R&D PO

(Has pocket protector

instead of tie)

InitiateKick

OffStabilize Recharge Improve

Product POs

Database

Infrastructure

Team

Team Leaders

!5

Team Leaders became Scrum Masters but

maintained their role as leaders of their

original functional team and retained HR

responsibility for their people and technical

responsibility for their output.

!The reasons for keeping the original team

leaders in place were:

!★ To reduce friction and resistance

★ To allow flexibility in the structure of the

Scrum teams. While we didn't want people to

move from team to team too often (we

decided on a 3 months minimum), we needed to

be able to restructure teams and still have

people managed by the same person for a

longer time frame.

★ To provide technical support for members of

the Scrum teams in their specialized field.

To determine whether a Scrum team included a

member or used his services through a

professional group, we decided that a person

needed to dedicate at least 50% of his time to a

team in order to be a member.

!To avoid collisions between Scrum Masters and

Team Leaders for team member’s time, it was

decided that people belonged first and

foremost to their Scrum Teams and only then

to their functional teams. If a Team Leader

wanted to “borrow” a team member mid-sprint,

he would have to consult with the Scrum master

and the PO.

InitiateKick

OffStabilize Recharge Improve

Kick Off

!6

We started the kick off phase by training and

aligning expectations with two groups that we

thought were essential to the success of the

Agile transformation: the Program Managers

and the Team Leaders.

!Since it was crucial to get Program Managers,

who were originally responsible for both product

and project management, closer to the teams

to provide ongoing clarifications of the

business and customer needs, we decided to free

them from project management responsibilities

so they could focus on product management.

!We thought that getting the team

leaders' commitment was critical in

order to guarantee a successful Agile

transformation.

We conducted an extensive workshop with them

to achieve buy-in and harness them as a force

for the transformational effort.

!Next, we built initial backlogs for the first

sprint of the launching teams, decided on an

initial 2-week cadence, trained the teams and

started sprinting. To allow focused coaching in

the initial phase, we decided to stagger 5 teams

at a time, adding 5 more teams into the

transformation effort every two weeks.

!We started with strict and simple Scrum, working

with boards on walls with a policy that we made

sure was followed: Only work that the

testing staff had time to test could be

developed in the sprint. Overflow of

developer time was used for

improvement activities not to advance

scope.

InitiateKick

OffStabilize Recharge Improve

Stabilize

!7

The stabilize phase was focused on getting

people up to speed with the new ways of

working. Having strong buy-in from management

as well as from the Team Leaders made it

relatively easy to make sure the

transformation was going well.

!The main problems we faced were

around implementing the new policies

and handling resistance by people

affected by them.

!We used three elements to help address the

problems:

!Inspect & Adapt Policies – Frequent

retrospectives at the team level with problems

escalated to the Steering Forum.

!

Focused coaching on hot areas – Managers

focused their coaching efforts on the

problems as they arose, for example, the role

of testing team leads, uncooperative product

owners or reluctance to stop developing if we

couldn’t test. Scrum masters, Directors and

even the development VP would step into

meetings to reinforce the messages. We were

alert to the problems by having an Agile

Initiative Steering Forum which met regularly

to review and address progress and issues.

! Scrum Master Forum – We had a specific

forum where Scrum Masters got together to

raise issues and solve them. This forum was

attended by senior management, usually the

development VP himself, to allow quick

resolution of problems.

InitiateKick

OffStabilize Recharge Improve

Release Diet

!8

Once the basic process was working in the

teams, the development VP took another bold

decision and declared that in three iterations

time the entire organization needs to start to

release every iteration to production. The

teams had three iterations to understand how

to implement Continuous Delivery practices,

such as feature flags, so that they could be

ready in time.

!This move led to a buzz of activity and

a lot of "organizational adrenaline", as

the way to achieve this goal was left

to the teams themselves. !

After just one iteration, each team, including

database and data warehouse teams, had

solutions for how to implement this goal. They

did a dry on the second iteration and by the

third iteration had started releasing to

production and have been doing so ever since.

!Only now did the organization start building

better tools to make this new way of working

less painful. We began building a plan that would

improve Continuous Integration, add a level of

automatic testing and allow automatic

upgrades to production.

InitiateKick

OffStabilize Recharge Improve

Continuous

3

weeks

3

months

6

months

Recharge

!9

At this stage of the Agile Initiative the

organization needed some time to "recharge its

batteries". Time was needed to implement the

Continuous Delivery mechanism as well as its

Agile Testing practices. We reached the original

goals set at the Management Workshop and

could rest for a while before starting to climb

again.

Management needed time as well in order to

examine how all this hard work impacts the most

important KPI which was customer satisfaction.

The mechanics were now in place to enable the

organization to delight both its internal and

external customers with the new found

capabilities and energies.

The break came at a good time as product

marketing had just requested a large initiative

and the organization needed to focus its

attention on content and less on process for

a while but everything we had learned and all the

new capabilities that became the new way of

working indicated that the Agile initiative was a

success

InitiateKick

OffStabilize Recharge Improve

Improve

!10

This chapter has yet to be written and is

waiting for the organization to write it in

the future. Agile is a journey and not a

destination and the organization will

hopefully continue to constantly improve

its Agile practices and principles. These

improvements will be driven by new

challenges and new goals and the whole

cycle will repeat itself by going higher and

deeper with each cycle.

!

During this intensive six-month journey,

Sizmek shifted from a waterfall

company with six-month release cycles

to an Agile organization with an Agile

mindset and three-week release cycles.

InitiateKick

OffStabilize Recharge Improve

Reasons for Success

!11

Dedicated management team– The

development management team internalized

the Agile concepts quickly and started to

manage accordingly. They delegated

responsibility and decisions to the teams

and Scrum Masters while making sure

Agile principles were adhered to and not

abandoned for convenience.

!Buy in from the team-leaders – Initial

effort in the workshop with the team

leaders became aligned and engaged at a

critical level in the company and they drove

the initiative in the trenches and helped

the teams understand and stick with the

concepts.

Real Need – Sizmek had a true business

need to bring products to market in a more

efficient process so they were

able to rally people around the need and

practices.

!Courage – The management team made

courageous decisions both with regard to

restructuring the company around Agile

teams and with the move to Continuous

Delivery without waiting for the tools and

without over discussion. This courage

created a lot of energy in the company and

a lot of engagement and accountability.

Structured Initiative – The AgileSparks

Way allowed a smooth and structured

implementation with each part arriving at

the right time.

InitiateKick

OffStabilize Recharge Improve

!12

Thank You

!13

www.agilesparks.com

www.leansamurai.com

inbar at agilesparks.com