Learn how we used a Code Jam in a fun way to change how we work. The Code Jam has showcased Agile practices to the entire company from business to IT, from the C-Suite on down to the teams. It has provided us a safe place to learn, innovate and create.
Are you looking for a way to promote and educate your organization on Agile methods that is fun and engaging? Is your organization drowned in process and having trouble seeing a path to something different? If so, we understand. At the Principal Financial Group® (The Principal® ) we were also looking for a way to inspire our organization to not only learn about Agile, but to experience Agile in a real-life setting. We took a chance and decided to bring the unconventional idea of a Code Jam to our executive leadership.
The Principal is a global investment management leader offering businesses, individuals and institutional clients a wide range of financial products and services, including retirement, asset management and insurance. The Principal employs almost 15,000 people around the globe. Approximately one out of every eight employees serves in an information technology role. While most of the IT staff is located at the headquarters in Des Moines, Iowa, many also work in remote locations across the United States and abroad.
Our role as managers allows us to influence everyone from new hires to senior management. Having a pulse on what happens at all levels of the organization uniquely positioned us to have a good understanding of what needed to happen with each of these groups to influence change. We are Agile advocates and continually look for ways find a way to show how innovation and Agility helps drive our business now and into the future.
A Code Jam is an event where people involved in software development collaborate intensively on a software project over a short period of time. Sometimes events like this are called hackathons, but we like the term Code Jam better. It fits with our company culture. A Code Jam is fun, innovative, creative and isn’t about security and information theft hackers. At the Principal Financial Group, we held three capstone Code Jam events across the globe every year since 2013.
In 2013, a small group of employees who call themselves the “Changineers” self-developed the idea of Code Jam and presented it to the IT CIOs. The Changineers are a small, informal team of change agents who are passionate about trying new ways to get things done. Their idea was simple – create an event where like-minded IT professionals could come together to collaborate, innovate, and learn. Agile was being used inconsistently across The Principal businesses before 2013. Code Jams were important to broadening the understanding of the power of Agile and led to broader adoption and effective utilization of Agile methods. Figure 1 outlines our Code Jam adoption timeline.
Figure 1: Code Jam Adoption Timeline
At Code Jam, IT professionals are working outside of their daily responsibilities for a period of one to three days. They have the opportunity and support of the organization to learn, experiment and solve problems they care about for our company. We celebrate learning – new technology, practices, and skills. Daily constraints are temporarily lifted. Teams can explore possibilities.
We think there are a lot of good reasons to take the leap and try out a Code Jam in your organization based on our experiences at The Principal. Table 1 summarizes some of the key reasons a Code Jam could be helpful for your group based on feedback we have received from participants in our organization.
Agile mindset: The fast-paced nature of a Code Jam forces flexibility. You have to be willing to fail fast, regularly communicate, and create the minimum viable product. Time is not given for extensive documentation; the focus is one working code that can be demonstrated to stakeholders at the end of the event.
Cross-discipline roles: When someone walks into a Code Jam they must be willing to do whatever is needed to achieve their stated goals. A developer may have to become a tester; a project manager may have to play the role of a business analyst. Participants are encouraged to try something new and see from a new perspective.
Mid-manager: buyin Leaders get to observe what is possible when they support a new way of creating software. They get a better sense of how Agile methods can be used by experiencing them first hand. They may even get to see a new side of their employees in a different environment and playing different roles.
Self-empowered team: Code Jams allows the teams to decide what they want to tackle. They also decide how they want to work together to accomplish their goals. The role of the manager is to support the team where it is needed. This was a new way of working for many of our teams.
Culture: In a Code Jam teams learn how to work differently. They see that their work can be productive, fun, educational, and innovative all at the same time. Many wanted to bring this feeling back to their day-to-day work.
If you think your organization would benefit from any or all of these focus areas, you likely have all the ammunition you need to give a Code Jam a try.
As we reflect on the planning and execution of our enterprise-wide Code Jams, these elements were instrumental to our success.
Executive support – Our experience was so favorable in part due to the unwavering support of the CIO working group at The Principal. The key elements of their support were freedom from current processes, funding, and visibility.
First, we were given freedom to try something new and innovative outside of our current work and governance processes. Essentially, we had support to “break some rules” for 3 days. They openly supported helping us through any traditional barriers or rules. For example, we were granted exceptions to try new technologies that weren’t on the “supported and in use list”. This is critical to create the best possible experience for participants to explore new ideas and technology.
Second, taking people out of daily work for 3 days is expensive when you are running a business. We had executive support to test this with our first Code Jam with 25 employees (5 teams of 5 people). For an organization with approximately 2,600 IT professionals, this was about the right size for us to try it. We want to create an environment where people want to be to work and learn. In our experience, having some financial support to promote the event can also go a long way towards success. We provided Code Jam tshirts, food, etc. to our participants, organizers and CIOs.
The third important way the CIOs showed their support was being visible during the event. If you are thinking of putting on a Code Jam, you will want to show that you have leadership support. We had an executive kick-off the event and another emcee closing demonstrations. As the event got underway, we noticed that they wanted to take an even more active role in the event than we anticipated. In response, we added daily and mid-day pep talks for the teams. Teams gained an opportunity to showcase their talent and interact with the C-level, which isn’t something everyone gets in their day to day work.
Engage your entire business with a themed event – Having a broad theme for your Code Jam will help teams and your organization focus in a central objective for the event. Some themes we have used at The Principal are “What would you build?”, “IT Save Me”, “Renovate IT”.
Voluntary signup of participants – One thing our Code Jam planning team was sure of is that we needed participants who wanted to be a part of the Code Jam to make it a success. We didn’t want people assigned from the various business units by their managers. We were looking for people who were passionate about a project idea, or about making a change in how we do work at the company to participate. We set up a simple registration process for people interested to sign up for the event. Submit your name, strengths, how you can contribute to a team, and agree to be at the event for 3 days with no other work obligations. We hoped to get the most motived and inspired people to sign up. It worked. For our first Code Jam, we filled our 25 spots and had to turn a few people away.
Creating teams across the organization – Another goal of the Code Jam was to have cross business unit teams, so we matched up people who had never worked together to gain networking and new perspectives. For example, someone who works for our Retirement business may not know or work with someone from our Insurance business, or Corporate Marketing. In our experience, creating teams for the Code Jam that crossed the business unit lines exposed people to new ideas, technology and ways of working. As the participants voluntarily registered for the Code Jam, the Code Jam organizing team reviewed the registrations and created balanced teams mixing up people from various business units. Don’t worry, the teams still self-organize around their project and the work. We’ve found this to be a great platform for inspiring creativity as well. As we have evolved our event over time, we have tried team registrations and required participation (internship program). When we had a team registration process, saw a substantial increase in participation numbers (over 70% increase). What we lost in this process was the networking and creativity aspect. Teams registered as groups of people who work together in their daily work. They just wanted to work together in our Code Jam environment. With our IT internship program, Code Jam is a required component. There has been some hesitation. For example, an intern in network security is not sure how a Code Jam is relevant to their job. After participating, several interns have reflected on how much they learned and grew working on a team and learning new work practices, or new roles.
Set up a fun and highly visible collaboration space for the teams – We have found that getting people out of their normal work area (i.e. cubicles if you still work in them) and into a space primed for innovation, creativity and collaboration will help you create a fun atmosphere for the teams to do their best work. We have held our events in highly visible areas of our corporate campus. Some examples have been a large area of our cafeteria seating and a pavilion between two of our buildings with a lot of open seating. The visibility has been a key to getting people who are curious to ask, “What is going on over there?” It is a conversation starter for IT and business to talk about the process, practices, and innovation that is possible. We also had a fun vibe in our space by setting up a playlist with music, team photos, fun team names, and a Twitter hashtag. These little things have helped to create an environment where teams really enjoy working.
The atmosphere and experience was so different. Now we hear comments like “Code Jam days go by so fast. Why can’t we do all our work like this?” We are evolving our work environment as a result. One downside we learned after the first Code Jam we have affectionately called “re-entry”. This is what happens after the Code Jam is over and everyone goes back to their normal work area – to business as usual. We had to coach participants on ways to take what they learned at Code Jam back to their home teams. That first day back after a Code Jam will be tough.
We have also held Code Jams with much smaller groups (less than 25 people) to focus on specific learning opportunities. These Code Jams are typically one day or less in duration. Teams can choose to focus on learning a particular Agile methods such as pair programming or using a Kanban board. They can also decide to use several Agile methods and get additional time to practice in a safe environment. In addition, they can focus on other core skills they may want the team to develop, examples include learning mobile technologies or cross-training on systems the team currently supports.
The first step in planning a small scale Code Jam is to understand what you want to accomplish and prepare appropriately. Our first small Code Jam was focused on learning Agile basics, coming together as a team, knocking off some small product enhancements from our project backlog, and having fun. Some basic Agile 101 training was provided and more extensive education was provided on how to break down our work into smaller pieces and write good user stories. A basic “definition of done” was written to help the team understand how to move stories across the Kanban board. We decided to hold the Code Jam in a room on our floor for eight hours and to work on projects that could be completed in less than eight hours. We invited our business partners to participate so they could see what we were working on for them and provide feedback as needed. We invited all of the team members to happy hour after the event to build team morale. In the end, the team completed more small projects than they ever had in a day before, they felt more comfortable using Agile methods, and received positive feedback from our business partners.
Three primary methodologies that emerged during both the enterprise and small scale Code Jams were Scrum, Extreme Programming (XP), and Kanban. Participants began to use these methodologies for a variety of reasons including:
- Value-add to the rapid pace of Code Jams
- Ease of learning
- Desire to have the methodology used more generally through PFG
- Focus on teamwork and collaboration
- Time-boxed event
- Small cross-functional teams
Most participants who were full-time employees had attended an “Agile 101” course that was offered by PFG, but many interns and new employees had little to no Agile training. An Agile course is not required for a successful Code Jam, but it does help the participants feel more comfortable with the values of the Agile Manifesto as well as the terminology that is unique to Agile such as “Scrum” and “user story”. An Agile book or mentoring could also help prepare participants for the Code Jam.
Scrum was used as a tool to facilitate regular communication within the Code Jam teams. Daily stand ups were held to discuss what had been completed, what was in progress, and any impediments the team members were experiencing. In some cases, team decided to hold stand ups throughout the day to keep the team moving forward. The teams worked together to create user stories and prioritized in a backlog. Liven Up Agile Learning with Code Jams: Page – 5 For many of the participants, this was the first time they had written and sized user stories, so those with user story experience taught team members how to break down the work and provide the appropriate information required for a good story. Product demonstrations were not limited to stakeholders; anyone at The Principal with an interest in technology was welcome to attend and ask questions or provide feedback. Teams were encouraged to hold a retrospective at the end of the Code Jam to discuss what worked, what they could have done differently, and what they should consider for future Code Jams.
Extreme Programming (XP) methods were used to encourage collaboration and put an emphasis on “working code”. Code Jam participants’ pair programmed with one another to share design ideas, exchange coding ideas, and inspect for potential quality issues. In many cases, developers were pair with other developers, but often they worked with business analysts to ensure requirements were understood or quality assurance professionals to focus on code quality. Figure 2 shows pairs that include both developers and business analysts. Teams produced regular code builds to ensure their products were working as designed and to allow for more regular testing.
Figure 2: Paired Programming at the Code Jam
Kanban boards were leveraged to visualize the backlog and manage the work in progress. Each team used their own board and decided how many story points their team would work on at any given time. Most teams used a physical board, but some also used a software tool to track stories.
The most positive outcome that came out of using Agile methods in Code Jams is that we created an army of Agile advocates. Each participant went by to their home teams with a clear understanding of the benefits of Agile and ideas on how to use some of the tools from several of the Agile methodologies. Agile was no longer an idea or catchphrase, but a new way to approach the way they worked. This year alone, participation in Code Jams has increased 70% and with the expansion of adopting Agile methods has seen similar growth.
Agile learning and adoption has been an important outcome of the Code Jams, but we have also experienced other important wins including:
- Networking and collaboration across major business units
- Recognition in local media outlets as well national publications
- Attracting talent
- Encouraging innovation
- A fun and positive culture
As Code Jams has gained popularity, they have expanded to our remote teams in Pune, an intern-focused Jam, and a Code Jam that includes the greater Des Moines community doing tech projects in support of non-profit organizations. In addition, individual teams have started using the Code Jam format to teach Agile methods. They operate the same as corporate–wide Jams, but operate on a smaller scale at a more regular cadence. Each expansion of the Code Jam offers more opportunities for Agile learning and also a better understanding of how Agile can best be leveraged for new types of teams and projects. Code Jams are changing our culture and how we do work at The Principal. Participants want to work in a Code Jam atmosphere all the time. They appreciate the fast pace, freedom to learn and experiment, while getting results. CIOs have asked us to help foster a “Jam Every Day” culture. Applying what is learned in Code Jam to the daily practices of teams is creating a big change in our culture. It is helping spread Agile techniques to teams in ways we never imagined possible at the start of our journey.
Adopting Code Jam at The Principal has not only helped us deepen and broaden our understanding of Agile tools and techniques, but it has also encouraged our large organization to more broadly embrace an Agile mindset. This was an important step in our Agile journey.
Three particular tenets of the Agile Manifesto have been particularly evident in our transformation. First, we value individuals and interactions or process and tools. We have not abandoned the use of processes or tools, but there has been an increased focus on how we can work across business unit silos and share best practices with one another. We also have learned to value working software over extensive documentation. In a Code Jam environment, participants do not have time to write extensive documentation because they only have a few days to create a working prototype. They incorporated automated build techniques and only created the minimal documentation needed. It usually came in the form of a user story and several PowerPoint slides for their product demonstration. Finally, they have started to respond to change over following a plan. Builds break during a code, performance is slow, and stakeholders send you in a new direction sometimes hourly. It quickly becomes obvious that grit and passion get teams to a great product much faster than the most thoughtful project plan. It forced them to start appreciating the idea of a “minimum viable product”, something that has been difficult for them to grasp in the world of feature bloat and customization.
If your organization is looking for a new way to educate their team members on Agile methods, we encourage you to try a Code Jam. Like with anything new, your Code Jam may not go perfectly smooth your first time through, but we assure you that you will have a better understanding of how your teams will operate in an Agile environment. It will become quickly apparent if they need more training on breaking down user stories because none of their stories will pass the “Develop” lane on the Kanban board. They will see for themselves that the teams that focus on putting together an extensive schedule for the day will not make as much progress as those who are heads down creating working code. Perhaps most importantly, they will appreciate the value of becoming a happy and empowered team.
We would like to thank The Principal leadership and Code Jam participants who helped make the movement not only possible, but transformative.
About the Author
Aug 2015, Agile2015 Conference