How Sizmek moved from 6 months releases to 3 week continuous delivery and business agility using the AgileSparks way.

1. 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

2. 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
Initiate
Kick
Off
Stabilize Recharge Improve

3. 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.
!
Initiate
Kick
Off
Stabilize Recharge Improve

4. 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)
Initiate
Kick
Off
Stabilize Recharge Improve
Product POs
Database
Infrastructure
Team

5. 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.
Initiate
Kick
Off
Stabilize Recharge Improve

6. 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.
Initiate
Kick
Off
Stabilize Recharge Improve

7. 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.
Initiate
Kick
Off
Stabilize Recharge Improve

8. 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.
Initiate
Kick
Off
Stabilize Recharge Improve
Continuous
3
weeks
3
months
6
months

9. 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
Initiate
Kick
Off
Stabilize Recharge Improve

10. 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.
Initiate
Kick
Off
Stabilize Recharge Improve

11. 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.
Initiate
Kick
Off
Stabilize Recharge Improve

12. !12

13. Thank You
!13
www.agilesparks.com
www.leansamurai.com
inbar at agilesparks.com