The Creole cottage is a dominant house type along the central Gulf Coast, which was built by former French settlers from about 1790 to 1840. The typical Creole cottage is composed of one chimney and two gabled windows on the top of the roof, narrow doors and windows built on the top of a waterproof foundation. Using with these structural elements, we create a metaphorical pattern —— the ‘Creole Cottage’ pattern, which contains a context, problems, and the solutions. This pattern is abstracted from a real-world experience. It’s a practical and hands on pattern to help building a Scrum Master community, solving company-wide problems and making continuous improvement for processes. It can be said to kill three birds with one stone.
1. INTRODUCTION
We present the “Creole cottage” pattern, which was discovered from the experience of building a Scrum Master community in EF. A Scrum Master Community is a community of Practices (CoP) for Scrum Masters. While the purpose of a CoP is mainly to facilitate learning, we found that simple knowledge sharing did not serve purpose well. It is also more difficult to get support from organization when our learning cannot be validated and learning is distanced from the results. Therefore, we try to combine growing capabilities and achieving results in designing CoP activities.
If you are trying to achieve results with a group of Scrum Masters, and also building their capabilities, our experience of building a Scrum Master community may provide insights for you. The emerging pattern from this experience may even serve a wider scope.
2. BACKGROUND
EF (Education First) is the world’s largest private education company. EF Labs, located in Shanghai city, China, is the global research and development center charged with using new technologies to create a fundamentally efficient way for students to learn.
To meet the new challenge of how to deliver higher quality product to customer with faster speed, EF Labs started an Agile transformation in the middle of 2011. As a new agile-‐transformed organization, EF Labs was like a newborn baby, weak, fragile, unsustainable, threatened by growing crises. There were huge barriers between scrum teams belonging to different business units, resulting in cross-‐team product delivery being repeatedly delayed; because of lack of visibility of defect data and standardized processes, complaints happen between customer service and development teams, cause the average lead time of live defects to be even longer than the release cycle. Waterfall development mode was used for 4 years since EF labs was born.
Waterfall culture is deeply rooted and there’s a lack of awareness of continuous improvement.
Furthermore, the first wave of Scrum Masters was brand new, and there was a need to build a community to grow Scrum Masters from both a knowledge and a practice point of view.
As an Agile Coach and a newcomer in a new agile-‐transformed company, I was given two missions by my management team. Eric Azumi, Vice President of EF Labs, told me his vision was to create a continuous improvement culture. He gave me one mission: create a Scrum Master community, at the same time to increase Scrum Master competence. Patrick De Moustier, EF Labs’ Senior Vice President, gave me another mission: solve company-‐wide problems systematically. At the company’s yearly offsite meeting, EF Labs CEO Bill Fisher, emphasized two business goals: to reduce product defects, and to break down team barriers.
Author’s address: Ni Sun, Room 1005, No.16 Weifang Road, Pudong district, Shanghai City, China; email: [email protected]
Copyright 2014 is held by the author(s).
3. OUR STORY
3.1 Problems
Given the direction from the business goals, and with my own two missions, I need to solve three problems:
(1) How to develop Scrum Master competence?
(2) How to decrease defects and defect cycle time?
(3) How to improve cross-‐team collaboration?
While searching for solution, I was remembered a previous experience at Nokia Siemens. I was working as Scrum Master and latter R&D manager there. The organization was running in Scrum mode with multiple teams. There was a community of Scrum Masters in the organization supporting learning among them. In addition to sharing experiences and challenges from our own teams, we created Scrum Master taskforces, partnering with managers, to address organizational impediments. Working on the root problem with mentoring from senior Scrum Masters and managers not only helped remove those organizational impediments, but also developed Scrum Masters’ capabilities. Would a similar approach apply to my new challenges? I believed so.
3.2 Alignment
Alignment with stakeholders is essential for the success of continuous improvement . How to align our effort with all stakeholders? The first step was to understand our current situation as well as the history of this organization. Who was doing what, what were their ways of working. The first month after I was on aboard, I did nothing except one-‐on-‐one deep conversations with key influencers in EF Labs. I talked to Business Owners, Technical Development Managers, Scrum Masters, Product Owners, QA managers, Organization Designers, Developers, QAs, etc. Besides learning that who was doing what and how, also I abstracted their common interests, expectations, and their attitudes towards solving the three problems.
Net-‐map [1] is a toolbox to help to clarify the influencers to a specified question in a network of people. I used it to identify the key stakeholders and influencers in EF Labs.
After that, we used an Influence-‐Interest diagram [2] to find out which people should to be involved in the continuous improvement projects and be the seeds of an Agile culture. As shown in Figure 1, according to people’s influence and interest in the three problems which need to be solved, the people who have high influence with high interest (Quadrant I) are our powerful supporters, they are core and key persons need to be aligned; People with high interest but relatively lower influence (Quadrant III), are solid allies, they are the
basic foundation and mass line for the alignment from a long term view. For people with high influence but not much interest (Quadrant II), we need to build trust and positive relationships via proven successful example and experiences. To form an agile atmosphere and culture, we launched Agile Salon, Agile games and Agile seminars involving all functional departments and business units to pull our solid allies from Quadrant III to Quadrant I. It’s a long-term process, but the impact to the organization is quite positive and appears to be
sustainable.
Figure 1. Influence-‐Interest diagram
3.3 Creating projects
3.3.1 Targets
The more important part of the solution is launching the continuous improvement projects. Starting from our business goals and problem backlog, we decided upon two projects. The first one is live defect process improvement, with the goal of reducing average open days by 20% for live defects, and decreasing monthly defects by 25%. The second project is cross-‐team collaboration enhancement, to reduce delayed cross-‐team projects by 20%.
The remainder of this section will those describe these two Continuous Improvement Projects, who was involved, how they were accomplished, and what the outputs and results were. During the ‘how’ part, we will introduce the tools we used for the projects.
3.3.2 Building teams
In order to advance the Scrum Masters’ competence and build our Scrum Master community, Scrum Masters are the core team member of the Continuous Improvement Project. I acted as the Product Owner for these two projects. Ten Scrum Masters acted as developers, divided into two teams, each focusing on one of the projects. Based on people’s influence and interest, we involved VPs, Technical Development managers, Release managers, Tech leads, BAs, a JIRA owner, and Organization designers into our continuous improvement projects. Each team elected one person as their mentor.
3.3.3 Solve problems
We used Scrum to launch the two projects. First, we had a kickoff meeting, inviting all of the team members and stakeholders as the participants. The purpose of this kickoff meeting was to create a sense of urgency regarding the need to solve these three problems and to make sure that everybody was on the same page, understanding our business goals, problems, and our current situation.
After the kickoff meeting, I delivered a problem-‐solving workshop to the Scrum Masters. In this workshop, Scrum Masters learned problem solving tools and techniques such as fishbone, (Plan-‐Do-‐Check-‐Act) PDCA [3], cause-‐effect diagram [4], 5 whys, and value stream maps. We had a group study of real business cases using these problem-‐solving tools.
After this background preparation, we had planning meetings for each project. In the planning meetings, we used cause-‐effect diagrams to do root cause analyses, and identified solutions with system thinking [5]. Then, we recorded our proposed solutions into JIRA as the initial backlog. Each item in the backlog was a concrete action with clear acceptance criteria.
We planed three sprints to implement these projects in parallel. Each sprint’s time-‐box was designed as 6 weeks, because of the need for sufficient feedback cycle time to validate and adjust our prototypes. Scrum Masters and mentors had weekly synchronization, identifying what had been accomplished last week, what we planed to do in this week, and the obstacles we met. If there were impediments, Scrum Masters tried their best to remove it together, as well as getting support and advice from mentors. Each project team cooperated as a self-‐organized team.
At the end of each sprint, two teams did a sprint review and demonstrated our accomplishments to the pertinent stakeholders. We collected feedback, listened to the advice and suggestions, and then adjusted our plans and refined the backlog items.
We applied a PDCA cycle running through the three sprints during the whole project. For example, in the cross-‐ team collaboration enhancement project, to reduce the project delay, decrease the dependency of related teams on software design and implementation work, improve synchronization, and clarify roles, we designed the cross-‐team project process prototype as our MVP (Minimal Viable Product) [6] in the first half of the first sprint. Then in the second half of the first sprint till the end of second sprint, we did the MVP experiment in
three Scrum teams, which had their cross-‐team project together. After we checked the result, we adjusted our MVP according to the feedback. Finally, we rolled the cross-‐team project process to whole of EF Labs during the third sprint.
After resolution of the results at the end of the third sprint, the Scrum Master group presented these projects’ results to the whole company’s staff.
3.4 Results
For the first project, live defect process improvement, we established a standard live defect process with clear role definitions, and corresponding responsibilities. We established a Defcon system (defect severity calculation), which was integrated into JIRA. Live defect reports based on systems, products, average open days, and monthly defect numbers in JIRA exposed all defect data to the whole company. We instituted a defect follow-‐up triangle meeting between Product Owners, Scrum Masters, and Customer Support, held every three weeks.
After making our product defect data transparent, our scrum teams solved many long-‐open defects. Average defect cycle time was reduced from 47 days to 36 days, an improvement of 23%; and our monthly open defects decreased by 38%, from 81 to 50. There is now more effective communication between customer relation and scrum teams. The defect fix flow has become more efficient. The product live defect reports provide our management team with quality actionable feedback, and they are now the quality matrix in our business Objectives and Key Results (OKRs).
For the second project, cross-‐team collaboration enhancement, we rolled out a cross-‐team project work process, “EF Labs Team Portal”, held Agile Salon, launched Agile games, and organized badminton rallies.
By a clearly defined cross-‐team project driver, roles’ responsibilities, definition of done, input and output, and scrum of scrum, cross-‐team project work process has been used as an info hub and systematic tool to run through the whole project. It helped scrum teams to reduce the foreseen risk, solve synchronization problems and remove design and implementation dependencies. The project driver run through whole cross-‐team project, and made sure the product delivery together with all scrum teams.
The “EF Labs Team Portal” contains the electronic seat map, the scrum teams’ workflow and structure. Using the electronic seat map on the website, everyone can easily find who sits where and their organizational relationships. The Scrum teams’ workflow in confluence page, makes each team much more transparent to each other in terms of people, process, practice and data.
In Agile Salon and Agile games, we invited all staff from different functional departments. People from R&D, Customer Support, Marketing, User Experience Design, Content Development, etc., got together, and enjoyed learning as well as playing games. By taking part in the badminton rallies, our colleagues created their own personal networks. These positive relationships bring the benefit of better collaboration to our work.
So far, each scrum team’s structure and profile is clear. A cross-‐team collaboration culture now exists, and teams are more integrated and likely to support each other. Cross-‐ team project workflow now is working smoothly and efficiently. Project delays due to dependencies on another team’s tasks or due to poor collaboration happen less often. Employees from all disciplines – developers, testers, customer service engineers, content developers, designers, product owners, and super-‐geeks from the technology team all took part and enjoyed the agile games.
On the other hand, from the kickoff meeting till the final presentation to the whole company, for over six months, Scrum Masters cooperated with their counterparts, talked to key stakeholders, solved company-‐wide problems, and led for changes. Their competence and influence developed rapidly. The Scrum Master community has been established and becomes stronger and stronger as time goes by.
3.5 What We Learned
From the kickoff meeting till the presentation for the whole company, it took almost seven months, which was really a tough journey.
If we had another opportunity, we would like to have had better control of the pace of projects. We would like to have had release planning first and shorter sprint time-‐boxes (e.g. 3 weeks). That way, we might have reduced delivery cycle time and gotten faster feedback.
During project implementation, we could do a better job of information radiation about what we were doing. We created a white board to publish the information and the sprints’ outputs. However, it was not enough since people would loose interest in a static board that was not changed for a month. Next time, we would like to create a real-‐time dashboard using TV screen, showing the data, progress, activities and outputs.
One of the key experiences for us is that we created a solid alignment before we started to do the projects. We aligned our project goals with business goals. We told key influencers our motivation, abstracted their common interests, and addressed their concerns, which formed a strong foundation for what we were going to do. Proof of this appeared in a lot of support and advocacy from our allies in the latter stages when we were challenged by obstacles.
And another key experience is that we did the continuous improvement project with solutions based on systems thinking instead of short-‐term actions. We recognized that our organization is a complicated system, and we took a comprehensive view of all departments’ functionalities, roles, responsibilities, and impacts of serial actions. Based on that, we avoided some foreseeable low-‐level mistakes.
Personally, looking back on the whole story, I played the role of the driver of change, and I struggled a lot sometimes. I learned that the key to success is not IQ or EQ, but is grit. Whenever I was stressed out, I never thought that I would give it up. I always remembered the words from the Bible: Those who sow in tears will reap with songs of joy.
4. EMERGENT PATTERN
The approach of creating improvement projects to solve company-‐wide problems and building a team of Scrum Masters to work on them worked again. It was a success at Nokia Siemens Networks, and I used a similar approach in EF to achieve great success. Is a pattern emerging?
A pattern is a proven solution to a problem in a context [7]. It is basically composed of three aspects, but not limited to: a context, problem, and solution. Thinking of what was essential in my previous experiences, we were guided by our business goals, which defined the context. Our challenge was both solving problems and developing people at the same time. After an analysis of the influence and interests of the people, then aligning with them, we created improvement projects, applied a set of tools, such as PDCA, systems thinking, Net-‐Map, and cause-‐effect diagrams. Finally, we achieved both business results and growth in people competency.
While I was planning to submit this experience and the pattern at the Scrum Gathering in New Orleans this year, I found a metaphor that corresponds to the pattern well.
A Creole cottage is a type of vernacular architecture in the Gulf Coast of the United States. When walking through the French quarter in New Orleans, you can see many colorful Creole cottages on both sides of the street. In a typical Creole cottage, there is a chimney and two gabled windows on the roof, long-‐narrow doors and windows on the frame, and an exposed foundation at the base. Comparing these structural elements, I created a ‘Creole cottage’ pattern.
As shown in Figure 2, the key structural elements of a Creole cottage: chimney, gabled windows on the roof, long-‐narrow doors and windows on the frame, and a foundation at the base, ‘Creole Cottage’ is a metaphorical pattern which consists of the context (chimney: Business Goal), the problems (gabled windows: Problems), Solutions (Foundation: Alignment; Doors: Continuous Improvement project; windows: Tools).
Figure. 2. Sketch of ‘Creole Cottage’ pattern
Considering the three aspects of a pattern, for the ‘Creole Cottage’ pattern, ‘Chimney: Business Goal’ is part of the Context; ‘Gabled windows: Problem Backlog’ refers to the Problem; ‘Foundation: Alignment’, ‘Doors: Continuous Improvement Project’, and ‘Windows: Tools’ define the solution.
4.1 Chimney: Business Goal
The chimney is at the highest point of the cottage, and represents the idea of the business goals, pointing the direction where people should go. Each firm has own specific business goals and focus. Effective execution requires deep understanding. That is your starting point.
4.2 Gabled windows: Problem Backlog
On top of the cottage roof, there are two distinct gable windows. In the ‘Creole Cottage’ pattern, the gable windows represent to the Problem Backlog, a to-‐do list prioritized from a Return on Investment (ROI) perspective.
There are two views on the Problem Backlog. From the staff’s perspective, depending on the specific roles played in the organization, e.g., Agile coach, managers in the organizations, team leaders, or process improvement specialists, different problems will be encountered. From the organization’s perspective, e.g., scrum teams, sections, departments, business units, or company might have a different problem set. This problem set forms the original Problem Backlog. You and your partners need to determine the priorities according to the ROI.
4.3 Foundation: Alignment
The first step in building a cottage is to lay a foundation; Similarly, the first step of the solution is to align all stakeholders within the problem scope. The more solid the foundation, the more stable the cottage. You need
to identify who is concerned with this problem, and who can contribute to the improvement, who can influence, and who can make the decisions. Find these people and create alignment with them. The more solid the alignment, the further you can go, and the more sustainable results you can achieve.
4.4 Doors: Continuous Improvement Project
Just as the doors on the frame of the cottage are the access points through which people can enter the house, the Continuous Improvement Project is the access point and also the major component of the solution. In the continuous improvement project, Scrum Masters are the core team members, involving the most influential, senior people in the organization as the mentors. Each project team’s goal is to solve the problem systematically by hitting the pre-‐defined and measurable target.
4.5 Windows: Tools
Through the windows of the cottage, people breath fresh air and enjoy the sunshine. Thus, the windows refer to the tools we applied to implement the continuous improvement projects. By using suitable tools, such as systems thinking, Net-‐map, cause-‐effect diagrams, Plan-‐Do-‐Check-‐Act (PDCA) etc., we can implement projects more effectively.
5. WRAP UP OUR STORY
Returning to the ‘Creole Cottage’ pattern, the real experience in EF Labs is one instance, which is shown as Figure 3. To summarize, guided by two business goals (chimney), decrease defects and break down barriers, as an Agile coach in a new agile-‐transformed company, I met the challenge of a set of problems (gabled windows). The first step of the solution is to align with key influencers and stakeholders in the organization as the foundation of the cottage. We launched two continuous improvement projects in parallel, live defect process improvement and cross-‐team collaboration enhancement (doors). During the entire process, we applied tools (windows) such as Net-‐Map, Scrum, cause-‐effect diagrams, PDCA cycle, and systems thinking to support our implementation of the projects and reach our targets more efficiently.
Figure. 3. EF Labs instance of ‘Creole Cottage’ pattern
6. CONCLUSION
The Scrum Master community as a practice often doesn’t achieve its full potential in many organizations. One observation is that they often limit themselves in the sharing of good practices and lessons learned. This pattern greatly expands its scope. By doing working together to solve organizational problems and remove organizational impediments, learning is deepened and validated by the outcome.
Given the business goals, when we face the challenges of both improving outcome and developing people, we create improvement projects, in which we coach, lead, and facilitate the team for both results and capability. This summarizes the pattern. Our story provides a reference for your application of this pattern in the Scrum Master community. We wish you success in building a great Scrum Master community with business achievement.
7. ACKNOWLEDGEMENTS
This paper would not have been possible without the help of many great people. There are three people in particular I would like to thank: Eric Azumi, Patrick De Moustier and Lv Yi. Without the unique mentoring of each and their allowing me to do what I did, this paper would be a mere shadow of itself. I’d also like to thank the staff of the Scrum Master community of EF Labs. They contributed a lot of effort and enormous energy to those continuous improvement projects, which made a dream come true. I am also grateful to James Salsman.
He helped to edit my paper rigorously. Finally, I sincerely thank Linda Rising, my great shepherd, for guiding me in writing a professional paper. Her rich experience with patterns and the persistence to teach novices impressed me deeply. She is my role model of learning new things endlessly and creating value for people.
REFERENCES
[1] Eva Schiffer, Net-‐map toolbox: Influence mapping of social networks. Netmap.wordpress.com
[2] Influence-‐Interest diagram, http://changingminds.org/disciplines/change_management/stakeholder_change/interest_influence.htm
[3] Rother, Mike (2010). “6”. Toyota Kata. New York: MGraw-‐Hill. ISBN 978-‐0-‐07-‐163523-‐3.
[4] Brenda Scottsdale, eHow Contributor, How to use cause-‐and-‐effect diagram, http://www.ehow.com/how_8290508_use-‐ causeandeffect-‐diagram.html
[5] Peter M. Senge, The Fifth Discipline, 2006, Random House Books; 2nd Revised edition
[6] Eric Ries, Minimum Viable Product: a guide, Lessons Learned, August 3, 2009
[7] Richard Gabriel, Pattern definition thread. http://www.c2.com/CGI/WIKI?PATTERNDEFINITIONTHREAD
