Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Sizmek - From 6 Months release to 3 weeks continuous delivery


Published on

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

Published in: Technology
  • Be the first to comment

Sizmek - From 6 Months release to 3 weeks continuous delivery

  1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. !12
  13. 13. Thank You !13 inbar at