5 Reasons Why You’ll Love Our Devjams

Back in January, we held our very first developer outreach and mini hackathon event, aka devjam, in Scottsdale, AZ, to a sold-out audience. Since then, we’ve had three of these one-day events in Durham, NC, Québec City, Canada, and Austin, TX, with one coming up in Los Angeles in June.

So far, the response has been very positive. The feedback received has helped us build better APIs and a better developer experience. The devjams’ Net Promoter Score (NPS) is 72, which is pretty high. So thank you to everyone involved in this success 🙂

IMG_5200

Devjams are our way to, in the parlance of Steve Blanks, get out of the building and engage our customers. Since my team’s mission is to create APIs developers love to make our platform accessible, devjams are a great and fun way to engage our customers, the developers using those APIs.

IMG_5243

Whether you’re a developer or someone interested in Ticketmaster tech in general, here are 5 reasons why we believe you too will love being at one of our devjams:

#5 Meet the team

Devjams are a great opportunity to meet the people of Ticketmaster who are opening up the platform, building APIs and shipping products. We believe that the best innovations happen when people connect at a human level, and devjams are a fantastic setting for that. Once you meet the team, you will feel the stoke!

IMG_5266

#4 Join the team

It takes a special kind of talent to spend their Saturday with a bunch of strangers to talk APIs and product innovation. That’s the kind of talent we’re interested in and we have various opportunities where they can contribute. Who knows, we might be working together soon on some awesome products 😉

IMG_5683

#3 Get inspired

Serendipitous “eureka” moments are a conversation or a keystroke away. It happens every single time without fail. You’ll find inspiration in the demos others give and in the cross-functional collaboration throughout the day. Given how intimate our events are (30-70 people), it’s easy to have meaningful conversations that will set your imagination free.

IMG_5709

#2 Give feedback

As mentioned earlier, we focus very heavily on the developer experience, or DX. You’re the customer and we’re here to listen to you. We want your feedback. We want your input. As a developer myself, I love when companies do that because it shows they’re invested in me. We’re definitely invested in you, so come on out and share your thoughts with us!

IMG_3175

#1 Have FUN!

By far the best reason for coming out to one of our devjams! We’re a fun bunch and like to connect with others. Our events are informal, laid back, and are as much about enjoying oneself as they are about coding and APIs. There will be plenty of food and beer for everyone. Just bring your jolly self and have a great time!

IMG_5202

We hope to see you very soon at one of our devjams this year. You can also follow us on Twitter to stay abreast on our exciting journey to open up the platform at Ticketmaster.

We would love to hear from you directly. Please leave a comment below or reach out to me on Twitter.

Let’s build amazing products together! 🙂

How Agile Inceptions Are Changing Ticketmaster’s Team Culture

The Ticketmaster Way

An agile inception is a collaborative discovery workshop to visually get all stakeholders and team members to a common understanding prior to the start of a project.  The first time I observed my first agile inception I watched 3 transformations occur.  API developers’ eyes widened as they realized for the first time how their “piece” fit into the larger ecosystem and how different applications used it; developers were visibly excited to understand the business problem they were trying to solve and the team rallied together to then solve the problem and ideate based on a common understanding. Product, engineering, UX, program and our stakeholders were bound together by a common mission.   It was one of the most inspiring things I have ever witnessed a team go through. A year and a half later, the Ticketmaster coaching organization regularly facilitates inceptions as a way to kick off a new project or team and the inception process is now part of our technology culture. “The Ticketmaster Way” became a term used to describe how our culture was changing and we began to experiment with new processes and techniques to deliver ideas to our fans and clients.

How we got here

Like many organizations, Scrum gave us a base and common understanding around agile principles and ceremonies.  It became a very dogmatic approach and much of the principals were driven by the project management organization however, the value was not fully understood throughout the team.  Although, we were doing agile things, we were not agile minded.  It was time to change (yes, this was hard!)  At the start of our transformation, most of our teams were comprised of all one specific skillset on one part of the system or site.  We piloted the idea of creating a cross-functional product focused pod. This group of people were assembled as a team and had varied understandings of systems, architecture and applications.  It was then that we piloted our first inception.   The entire team moved to a separate building which gave them ample opportunity to form autonomously.  Ticketmaster’s first inception lasted 2 weeks.   During this time, we also introduced other agile frameworks into the team including Kanban, Lean and some Design Thinking workshops.

Inception.jpg

The Inception

We have since refined our process considerably.  After restructuring most of our teams into pods and over 40 inceptions later, we have found that 2-3 days at the beginning of the project to get to a common understanding is the right amount of time.  Inceptions are critical to help the team spend much less time in the forming and storming stages of team development and shift to norming and performing much quicker (therefore, eliminating waste!)

Tuckman
Figure 1. The Tuckman Model of Group Development

Inceptions are not only Ticketmaster’s way of kicking off a new project or team, it most importantly aligns the team around a concise mission with measurable business value – outcomes vs. outputs.  In fact, we no longer call projects…”projects”. We deliver on Promises of Value or (POV’s).

Who comes to the inception and what is the outcome?

We bring all team members, key stakeholders and customers into the same room (yes, we fly remote members out for this). The inception is an investment as part of the POV.  We keep the tone neutral by ensuring that it is facilitated by 2 members outside of the delivery team.  We break up the inception into 3 key areas. “The Strategy”, “The Work”, and “The Team”.  Although “The Work” and “The Team” are equally important, strategy is most often done at the product or business level and the team rallies around the work. Think of the team as “The Shark Tank”.  The team needs to be fully bought in and invested in the product that they are building to be inspired and motivated.  Because of this I am going to focus on “The Strategy” portion of the inception in this blog post.

Agree
Figure 2: Illustration via
Jeff Patton & Luke Barrett for Thoughtworks who re-created the cartoon from an unknown origin.

The Strategy – The Mission

The mission is not about telling the team what they will deliver. It is about understanding the problem that they are trying to solve. Product and design help the team to align on some materials prepared prior to the inception.  These materials help the team understand how the product will fit in to the ecosystem, who our competitors are, target users, the user journey, business drivers and the investment. UX will then will help to put some visual context, early prototypes, personas and design around what we are trying to solve. Finally, the mission statement is the most powerful piece. Why is the mission statement so important? It is what the team believes in and clearly states the problem that the team will solve. Product may come to the table with a mission statement already written, however, I typically have the team rewrite the mission so it is in their voice.  They own it. It needs to be something that any person on the team understands, is able to state and is passionate about. This is where it all starts. In writing the mission statement, I actually prefer a hypothesis statement format over an elevator statement. It clearly states what the team will deliver, the value it will bring to the business and how they know they will be successful.  At the end of the day, we really are building a hypothesis.  We have yet to prove its value.

We will deliver _______________________________

Which will enable the business to ________________

We will know we are successful when _____________

We are fans too! Bring the team members into the problem

The teams at Ticketmaster are passionate. Employees go to events; they experience shows and connect with the fan. We are fans! This passion becomes a critical piece in binding the team to the mission.  We begin the inception by allowing the team to fully experience the problem that our end-users are facing and empathize with them. We found that creating personas for the team was not enough, but having the team fully immersed in what the fan or client was experiencing sparked instant emotion, processing, and then ideation from the team. For example, in one inception we had the team call customer service and make changes to an order. We recognize that this is an experience that can be much better today, so what better way to have the team understand the pain then to go through it! This is the hand-off. It is at this point the team fully understands the WHY. They are not being told it will save the company x amount of dollars, or that it will improve the bottom line. They understand the pain and can see that this is a problem that can be solved.

When possible, we will bring our client or customer into the inception and have them demo directly to the team in how the product is being used and the many steps they have to go through to find a solution.

Measure Success

How will we know that what the team has been working on has been successful? Output is not as critical as outcomes. Just because we deliver something does not mean that it is meaningful to anyone. This final step is critical to motivate the team and help them feel successful in their journey. Are they going down the right path? Should they pivot? The team, just like the business, wants to know from the customer themselves. What do these measurements look like?

I often hear in these workshops that “we want to improve our Net Promoter Score or improve conversion”. But it’s not clear how this product or feature will move the needle in the many products we are delivering throughout the organization. It needs to be tangible. I usually ask 3 basic questions:

  1.  How do you know that you’ve achieved your mission for your slice or POV?
  2.  What does that look like and how will that help you make decisions or validate what to work on next?
  3.  When can the team celebrate their next win?

I like to ask when the team can celebrate their next win because most often than not, these are measurements that the team can fully get their head around – “We integrated with X and validated that the system is fully functional”. “We tested with internal users and validated that the user interacted with application as expected”…

It helps to break down the victory into much smaller wins which keeps the team motivated and excited.

Ticketmaster’s culture is changing. At the core of this change are the people who are passionate about solving hard problems. Given the context, room to innovate, alignment and a way to measure their success the teams become the change agents.  Invest in an inception, it will allow your teams to align early and deliver value quickly.  The key to kicking off a successful inception is by bringing the team into the strategy up front as possible.

  1. Get the team to collaboratively write (or rewrite) the mission statement.
  2. Demo the problem to the team.  Get every member on the team to feel the pain and then give this demo again for any new team members that come on-board.
  3. Understand the team’s success metrics and then measure success at the end of each slice/mvp.

Teams that are motivated feel empowered and driven.  Empowered teams produce amazing results.

celebrate

Our journey to shorter release cycles

The team that is responsible for the development of the ticketing websites of Ticketmaster International has been around for many years.

Where we came from

When we started we had a rather undefined project based process where we released new versions of the site when a project was ready. It was generally many months between each new version. Sometimes over a year. We were using a waterfall approach.

The business made project requests and handed over their requirements to the product team. They then analysed the project and wrote a large specification that they handed over to the visual design team. When designs were done the engineering team analysed the specification and made a technical design. After that, we broke the project down in smaller work items and worked until we were done. Then testers got to work and reported bugs for anything that didn’t follow the specifications. After a few loops of bug fixing and testing again, the new version was tested again for regression issues.

Then the new version was handed over to the operational team that deployed it to a staging environment where the business could see the result. It was common that the end result did not meet the expectations of the stakeholders. All the handovers in the process meant that the original intent was lost.

water-fall_454x172

Where we come from (Image courtesy of iquestgroup.com)

One step at a time

Our first step to improving this was to bring the testers into the same team as the developers. That meant they could test right after something was done. The next step was to regularly demo what we had done for the product team and the business. That meant we got feedback earlier if we were not delivering what was asked for.

We started to do sprints of originally 3 weeks with a demo after each sprint. Then we started to bring product managers into our daily meetings to be closer to the development. Then we made the engineering team more involved in defining the work. We broke the project down to stories that would bring value to the end user. The development team was actively helping product managers breaking down the project to user stories.

We shortened our sprints to two weeks. We also started doing test driven development. That is a way to help driving good technical design by doing automatic tests even before the functionality is developed. We also wrote higher level tests that tested the system from the outside. We decided that a new release would happen every 8 weeks.

After doing that for a while, we moved down to a 5-week cycle. We still had low coverage of automatic tests so we had to test the product manually for regressions at the end of each release. We got stuck in this state for quite some time but were happy with the way things worked. After all, we had come a long way from how we used to work.

We took further steps to work better together. We moved people to the same office, we started to create tools for improving our efficiency of deploying and generally automated as many manual tasks as possible. Coverage of automatic test grew over time.

Our most recent step

We wanted to take a further step to reduce our cycle. This time, the goal was to release to production after every sprint. It had a more profound impact than the changes we did before. All stakeholders would be affected as everyone would need to do their part more often. We decided to ask all stakeholders what such a change would mean for them and what changes were needed to enable a 2-week release cycle. We started tackling the identified issues.

Of course, our main priority in this change is to maintain the high-quality standards we have previously set for ourselves. We measure the rate at which high priority bugs are reported from production and how often and for how long business disruptions occur.  

One leap of faith we have to do when releasing after every sprint is that we removed the regression testing step that we used to have at the end of the cycle. That’s not to mean that we don’t test for regressions. Every story has manual exploratory testing included. All our automatic tests also catch regression issues and they are fixed within minutes of being introduced.  We also need to deploy the new version of code without disrupting sales. The local staff in each country that use our product must be able to translate any new text to the local languages before production deployment.

What we learned

We now have some 2-week releases under our belt and things have gone well. It has uncovered lots of inefficiencies that were hidden before and made everyone rethink their ways of working. Doing something that feels wasteful can be tolerated when you do it only every fifth week. But doing it every other week gets you thinking of ways to improve efficiency much more. It has also made us take the incremental approach much more serious.

I’m very proud of what our team has accomplished so far. It has taken hard work and dedication to reach the point where we are now.  The next steps would be to come to the point where we release code as soon as something is done no matter how small the change.

 

What Ticketmaster is doing about professionalising software careers

“My wife is doing her accountancy exams so is busy tonight, so I’m staying in to look after the kids” is something you expect to hear in every day conversation. But what about “My partner is doing his software engineering training tonight so I’m unable to come out for a beer?” Why is this still unusual? Are software developers still a product of their bedroom and dorm room past, hacking things together and so often saying ‘yes’ when no other professional would in a similar situation?

Software development, let’s face it, is an immature industry. We build software, but not many of our parents generation did. What we often fail to realise is the number of different roles we play. When we started out in software, we most likely will have felt the excitement of building something, and seeing it work. But to get it to work properly, we likely had to do some testing. As our initial projects mushroom, we start to learn various constraints – so without realising it, we start thinking about the design. Then when we have something that other people start using, they might have found a problem with it. So we need to do some investigative work. Then we find that there are additional requirements which can’t be met by the current design – so we start to think about the architecture.

What we haven’t realised is that we’re doing all the parts of what is known as the Software Development Lifecycle (SDLC): Requirements, Design, Development, Testing & Support.

Let’s think about other roles we play in our life. We may be parents, sons & daughters, friends and neighbours. But what about surfers, fans, climbers, shoppers and garage organisers? What we learn from looking at our lives that way, is that if we don’t plan for these roles, or put any time into them, then there are most likely negative consequences. If as a parent, we put no time or effort into parenting, or trying to be better as a parent, then that’s likely going to have a detrimental effect on us and our children. If as a garage organiser we put no time or effort planning or being a garage organiser, then our garage will remain a mess, and it’ll be impossible to find things when we need them.

sdlc

So the same goes for us as software engineers. We need to plan, prepare and learn how to master the different roles we play, or there will be negative consequences. Software support is often seen as less glamorous than developing, but as engineers it requires sharpening our detective skills to be able to find a metaphorical needle in a haystack. This requires a completely different set of skills to development. So in order to take ourselves more professionally, we need to gain an awareness of these different roles, and gain maturity in developing our skills in these different areas.

Here at Ticketmaster we’ve been Agile for over 6 years now, and we’ve come to the realisation that with that level of maturity, multi-disciplined skills are required in order for development teams to continue to grow in a healthy way. When we reviewed our career progression processes across multiple engineering locations, we also found a lack of consistency across job roles and criteria for career progression. We came to the conclusion that without a transparent process that was consistent across all our teams, it was hard to set expectations and provide our engineers with the optimum experience for growing how they wanted to in their chosen profession.

So what we’ve done at Ticketmaster to address these issues is create a career map – a flexible set of pathways built from what we do as engineers day to day, but that provides both a range of options for career progression along with outline steps of how to get there. This provides mastery of any chosen career progression route, with a clear vision of the outcome that you’re looking for as an engineer.

How did we do this? We used a number of industry standard resources, building on the SWECOM model created by the IEEE, and using influences from other industry models such as SFIA. This has enabled us to build a three part progression guide:

progression guide

  1. SDLC skills – these are built up from the SWECOM model and outline 5 maturity steps in each professional skill, built from the SDLC.
  2. Technical skills – these have been built up using a platform and technology neutral approach, again providing a 5 step program of technical skill for all areas pertinent to Ticketmaster’s engineering strategy.
  3. Behavioural skills – we have outlined four areas for awareness and growing maturity that we believe make the biggest difference to our success as a people first organisation: Team work, Innovation, Results orientation, Professionalism. We can’t and don’t want to mandate behaviour, so we provide lots of examples of what maturity looks like at each level.

So armed with a clear map of what is required to progress, engineers are empowered to make this journey with the support of their colleagues. How do we do that? We used the guiding principles from Drive by Daniel Pink.

Autonomy

It was really important to us that we avoid this scenario, which you may be familiar with:dt_c131214

Again, we considered the engineering profession from the viewpoint of different roles, and saw the role of the manager as a coach, like Boris Becker working with Novak Djokovic. We want to create an environment in which engineers can excel, rather than be micro-managed or stressed by unnecessary distractions. So we trained all our managers to operate with a coaching model in mind at all times, supporting and only intervening from the sidelines when required.

Mastery

We’ve empowered our engineering teams by giving them the tools and resources required to progress their careers – and them giving them responsibility for progression. The progression guide makes it clear what is required to progress to the next role. The guide was put together through numerous rounds of consultation, to ensure everyone had a say in how it was constructed. In order to satisfy the requirements of the next role, we have introduced a peer review and assessment process, whereby individuals submit their evidence to show they have mastered the professional, technical and behavioural skills to the appropriate level. What we learnt from engineering led organisations such as Google as well as other industries is not to have a single peer reviewing, but to have a minimum of three to ensure bias is minimised and the process is as objective, fair and transparent as possible.

We’ve rolled out training across all our engineering teams on how the career map process works, and run workshops on how to create suitable objectives in order to reach the requirements for each role. At each stage we have looked to put responsibility for progression with the engineer, but provided suitable support structures to enable and facilitate progression. This includes an online tool specifically created to help manage progress, providing a simple view for instantly seeing what steps are required and a convenient way to store evidence.

Purpose

Software engineering is constantly exploring unchartered territory. That’s why agile has won out over waterfall as a methodology because iterative exploration and learning is almost always better than educated guesswork. Like software projects, software careers are also subject to a high level of flux because of the nature of the industry. Established skills can be rendered redundant overnight by the introduction of a new technology, product or service (e.g. the iPhone, or Uber). By providing engineers with multiple options in terms of charting their career path, we believe that we can avoid exposure to the threat of redundancy of specific technologies by building opportunities for career breadth and depth.

This enables engineers to not only change as the industry does, but also to facilitate proactivity rather than being constantly reactionary, which is far more stressful. Undue stress does not contribute to a healthy working environment, which is what we’re constantly striving for.

But we’re also looking to professionalise our industry, and make software engineering an even more exciting destination than it was a generation ago, when it was really in its infancy. By building our approach on existing standards and the best disciplines from other industries, we’re aiming to show that we’re part of an extremely vibrant but also professional industry which will endure for millennia to come.