During my fifteen years working as a Scrum trainer I’ve contributed to a few concepts on Scaled implementations that have been adopted by the larger Agile community. My first words of advice: bundle external experience with internal champions. Also, find the smartest people within the enterprise.
I learned this during one of my most successful and largest Agile Transformation. It was with the CISCO Voice Technology Group[1] (VTG). I was one of three people who had the opportunity to help VTG think about how to best transform their operations. This was an extremely complex change involving over 2,500 people, globally distributed teams that were working on 40 complex interfacing products.
I had the privilege to work with Kathleen Rilliet and Michael Kalt, both members of the project management office, and our success at Cisco was largely due to Kathleen and Michael’s incredible knowledge and experience.
Core concept
The core solution in handling CISCO’s context was to address the scale and complexity by actually scaling down. Start with a modest goal. We decided to move to a 3-month release with fewer people, features, and interacting products. The key challenge here was to first go smaller and faster – not an easy feat!
The “New New Product Development Process”[2]
The existing waterfall process at VTG had worked itself into the classic problem of needing too much test time. Even with high quality code, the number of links to other products created a long-winded test cycle. Combined with an impatient product management, the result was an attempt to take advantage of the economy of scale within this already lengthy test process. Just put more features in the test, then we get more value for the same investment. Data shows that this thinking is flawed: more features make for a longer test cycle, with more problems.
The Scrum implementation focused on automating these massive integration tests. Cycle time went from three months to one. The process was still a bit unwieldy and far from our goal of continuous integration – but a massive improvement to managing delivery.
The goal was to go from nine months, to three months, and then to just one month. Ultimately we challenged the teams to work in 2-week Sprint that had testing completed in by the following two weeks. However, we told them: “if you want to be best in class: the team needs to get all testing done inside a 2-week Sprint.”
This move cost a lot of time and money. But the ROI was amazing. The money saved from two months of expensive testing plus the added revenue from an earlier release was well worth the upfront cost.
Getting to Continuous Integration (CI)
Let’s put our feet back on solid ground: CI is extremely challenging and will take even the best people months if not years to achieve.
The “Plan to Re-plan” makes the move from defined development to continuous integration a little easier. In “Five Levels of Planning[3]” the ideas is to link the long-term vision to short delivery cycles.
Leadership sets direction for product development in their Vision Statement. Through a combination of market research, technology opportunities and visionary skills a road map is sketched to where the product should be in a year.
Rather than defining delivery up-front, the agile approach is to do it iteratively: sprint-by-sprint accumulating value until it is market-ready.. Product management lays out their goals on a roadmap of frequent deliveries. An agile organization can do this in a continuous delivery; thinking in 3-month releases is a great first step. In three months the market isn’t going to change dramatically, and work queued up for that length of time has reasonable stability – change yes, of course, but a 90 degree turn in product direction, not really.
Develop a product backlog for the quarter, prioritize the list with the product owner and the delivery team, and voila: great input for the six sprints, reasonable stability, and ample opportunity to change backlog items from the one sprint to the next.
Now Plan to Re-plan kicks in: the development teams are working through the backlog, delivering value, and the product owner tunes the backlog from sprint to sprint. The other responsibility for product owner is to look ahead to the next release. Incorporating the vision, absorbing new technology, responding to competition, and incorporating new regulations, the product owner develops the product backlog in real time. Subject matter experts and developers should be getting more and more involved in the refinement process. Pretty soon the backlog is ready for the next release. Then the cycle repeats, forever:
From Theory to Reality
Back to Cisco, how did the “New New Product Development Process” get implemented? Here is the picture, with the local language:
The “Agile Commit” happens in backlog refinement. The role of the PO was to orchestrate dependencies between the multiple products. This used to be impossible. The number of dependencies in a 9-month project is mind-boggling. At the time, I compared it to a three-dimensional chess. Scaling back still makes it a challenging two-dimensional chess game that requires a grandmaster to orchestrate , but it is possible. The largest challenge was to get the old project managers to change their mind-set from big-bang delivery to value accumulation.
The “Golden Bridge” is the integration testing which links development to production; notice how after one month of work the Alpha Test (incorporating actual users) and an early release (EFT) kicks in. These are the wins – moving from a 9-month plan, which delivered in an average of 15 months, to a situation where every quarter product is released to early adopters.
Leadership Scrum
“Scrum is Simple, Not Easy” – so is the above process. And it can be better, more streamlined, faster, and cheaper. Re-training a large organization takes commitment; we did it from the team level up, and with good success. With more experience in building agile organizations, my current approach is try to bring the agile mindset to the team, division and leadership level. When product delivery moves towards continuous delivery, leadership has to be part of the on-going feedback loop: Annual plans need to be replaced by an ever evolving product roadmap, departmental plans need to be merged into leadership’s release plans, and process improvements need to be socialized in the entire organization.
Hubert Smits is a Certified Scrum Trainer and has been leading Agile transformations for over decade. Hubert is currently focused on how to help government contactors become more Agile and succeed with Scrum. He and holds a regular series of Certified Scrum Courses in San Francisco and Arizona. Where you can learn more about how to successfully scale Agile practices and how to apply Scrum in a highly regulated environment.
[1] Complexity at CISCO – Hubert Smits & Kathleen Rilliet - 2011
[2] The New New Product Development Game – Takeuchi and Nonaka - 1986
[3] Five Levels of Planning – Hubert Smits - 2006
The post Scrum Inc. Partners with Hubert Smits appeared first on Scrum Inc.