00:00:00
Ready for takeoff.
00:00:16
All right, so I think we can go ahead and get started. People might trickle in, but I want to thank you all for joining me for this talk today. My name is Stacey McKnight, and I'm a full stack developer and the US product team lead at Workforce.com.
00:00:24
It's kind of in the name, but we build workforce management software focusing on shift-based workplaces. We do that primarily using Ruby on Rails as our framework. I work out of our Chicago office, and I'm really excited to be here in the warm weather of Houston this week, just getting the chance to meet other people in the Ruby community.
00:00:39
So this is Chicago, and I want to get started today with two premises that I think we are going to share in common. One is that we all want to ship products and features efficiently that deliver value to our users. The other is that we would love to do that while also providing a great working experience for ourselves and the teams we are part of.
00:01:12
These are pretty simple and straightforward goals, but they can be hard to achieve. There are a lot of external factors working against us, and we can also end up working against ourselves, particularly through the processes we use to manage our workflows. If left unexamined, these processes can slow us down and prevent us from delivering as much value as we could.
00:02:05
So the question then is, how can we design our processes to improve customer outcomes and create a better day-to-day work experience? I'm of the opinion that good processes are like good design. When you have really good processes in place, you don't really notice them because they meet your needs so well.
00:02:24
The processes at that point are not the focus; they are the background structure that helps your team achieve its potential. However, just for today, we are going to bring the processes to the forefront. I'm going to share what's worked well for the team that I'm part of and highlight specific aspects of our workflow that help us deliver value and create a happier working environment.
00:02:43
Across the company, we use a project management process called Shape Up for our feature work. Shape Up works really well for our team, but another framework or methodology might be better for the way your team operates. Instead of pitching an entire overhaul of your current way of working, today we're going to explore three common challenges that dev teams face and the types of processes that have helped us solve them.
00:03:03
As I share about the solutions that have worked well for us at Workforce.com, I invite you to think about your own team processes and consider how they either support or detract from the goals we are discussing. Specifically, we are going to talk about these three challenges: one, how can we move quickly as a team, whether we're a smaller team or a larger distributed team?
00:03:26
Two, how can we make work more engaging and provide growth opportunities? And three, how can we deliver the most value and know that our work is having an impact?
00:03:44
As I mentioned, our team uses the Shape Up methodology for project management. Shape Up was developed by the team at a company called Basecamp and was built to help their remote team continue moving quickly as it quadrupled in size. If you're really interested in what you hear today, I recommend checking out the free Shape Up guide written by Ryan Singer, available on Basecamp's website.
00:04:01
For now, we will focus on the key elements of the framework that we use at Workforce.com. I will also share some additional processes that are unique to our context. Our context is that we have three offices spread across three continents, and we work in six-week cycles followed by a two-week cooldown period.
00:04:20
Each six-week cycle is set aside for something called shaped work. Shaped work starts as a document called a pitch, which includes several key sections. A pitch always begins with clearly defined problems. Having a well-defined problem makes it easier to evaluate the likely effectiveness of different solutions.
00:04:39
At this point, we typically define who we are solving the problem for in terms of users because that makes it easier to compare the impact that addressing different problems will have. From here, it's tempting to jump straight into a solution, but instead, we first find something called an appetite. An appetite essentially replaces a time estimate for the problem.
00:05:02
Instead of coming up with a solution and then figuring out how long it will take to build that solution, we determine how long we are willing to dedicate to solving a particular problem. The great thing about appetite is that it provides boundaries as we think about solutions. If you're only willing to dedicate two weeks to solving a particular problem, your solution will look different than if you're willing to dedicate a full six-week cycle.
00:05:23
Then comes the solution, where the main details of the solution are considered and outlined in the pitch, but there is still room for the designers and developers building it to apply their own expertise. The two elements of the Shape Up process that help you come up with a viable but not overly rigid solution are fat marker sketches and tech scoping.
00:05:43
In a pitch, instead of including a high-fidelity mock-up of what we want to build, we include a sketch of the UI drawn with a marker. If you've ever drawn with a marker, you know there’s only so much detail you can get in there, and that allows flexibility for your designers and developers to figure out what the solution could look like once they get into the code.
00:06:01
Fat marker sketches also prevent the situation where you might have a beautifully high-fidelity mock-up that isn't achievable within the time frame you're working with. Once the solution is outlined, a member of the dev team tech-scopes it.
00:06:20
This means they consider the feasibility of the solution from a coding perspective. They assess questions like whether this is achievable within the given timeframe, whether there are many unknowns, or whether it is pretty clear-cut. Once the pitches are created, they move into something called the betting table.
00:06:41
The betting table is made up of the team leads from all of our teams in the office, including the product team, sales, and implementation. They gather about two weeks before our new cycle starts, ensuring everyone has reviewed the current pitches so we can discuss how to prioritize the work and which pitches to set aside.
00:07:05
When we set aside those pitches, they don't go into a backlog. We'll talk more about why that is in a bit. From there, the selected pitches go through a process called handoff. This is usually a one-day or half-day activity when the dev team members working on the pitch have the opportunity to read through it, start exploring related code, and outline steps they will need to take to build it.
00:07:25
They then have a chance to chat with a product manager or whoever was working on the pitch to answer any questions that might have come up for them. Once building starts, it continues for the next six weeks. We do not wait for a release date at the end of the cycle; we are shipping continuously during the six-week period.
00:07:44
After six weeks, we move into a cooldown period, which is mostly self-directed time for developers, and we're going to talk more about that as well. Now that we've gone through the core elements of the Shape Up process, let's revisit the three questions we started with, beginning with how can our processes help us move more quickly.
00:08:06
To be successful in the market, we have to move at a steady pace, which can be challenging for smaller teams competing against much larger teams and for larger teams coordinating across different time zones or ways of working. We encounter both of those challenges at Workforce.com, so we need a way of working that amplifies our efforts as a smaller team and as a larger team working across different countries.
00:08:27
For context, we have seven developers in our US team—one is a hybrid designer/developer—and we also have a US product manager. While I say we are a smaller team, size is relative; you might be a smaller team with 30 people competing against other companies with twice or three times as many staff. Regardless of team size, we all want to maximize our resources and the time we have.
00:09:07
One way we've found to utilize our time is by carving out larger chunks of undistracted, focused time for developers. One of my favorite books is "Deep Work" by Cal Newport, a Georgetown computer science professor. In the book, he describes the value of focusing on cognitively demanding tasks for longer periods without distractions.
00:09:29
He argues that this type of deep work will not only boost productivity but will also energize you, making the work experience a lot more meaningful and fulfilling. We have found three things that provide more space for deep work: one, we've established an understanding with teams in the office that once a cycle's work is selected, that's what the dev team will be working on.
00:09:50
Together we have agreed that this is the most important work the team can be doing, and we do not want to distract them from it. We can always change course in six weeks, and this cross-team agreement benefits from the betting table discussions. However, even with a specific focus, unexpected things can come up during that time, so we need a way to handle those.
00:10:12
Many teams using Shape Up also implement something called a reactive team, which responds to unexpected opportunities and needs. At Workforce.com, one to two team members rotate through this reactive team, allowing the rest of the team to focus on planned work, and we have found this to work really well.
00:10:36
Another way we look for ways to reduce standing meetings is by ensuring team members can manage their time effectively. The team is mostly self-directed in setting their own meetings. For some projects, it's more useful to have regular meetings with stakeholders, but often, those meetings can take the form of asynchronous communications.
00:11:01
When you introduce asynchronous communication, many platforms can be used—like email, bug tracking systems, or direct messaging. This can lead to frequent context switching. To minimize context switching for our developers and team members, other teams at our company, including product management and implementation, have learned to use GitHub.
00:11:34
They comment directly on relevant pull requests, which has the added benefit of consolidating most of the information around a particular feature in one spot for future reference. This is how a smaller team operates, but what do you do when you're part of a larger distributed team?
00:11:55
Working with a larger distributed team can lead to challenges such as merge conflicts and differing operational styles. To find alignment, we have discovered two helpful strategies. First, having predictable start and end dates to our Shape Up cycles allows us to align our schedules across offices, which is especially valuable when choosing what to work on.
00:12:23
This way, we avoid significant changes to the same area of the codebase concurrently. Second, while we have a shared rhythm of six weeks of shaped work followed by two weeks of cooldown, each team's use of that time is up to the individual offices and project teams. This flexibility allows teams to choose a working style that suits them.
00:12:45
When team members have these larger chunks of undistracted time, how do we make it engaging and productive? You may have heard of the term "Flow State." It refers to periods where individuals are fully immersed in a task and are not struggling to focus.
00:13:05
If you've experienced this state, you know it can be a very productive and sometimes even fun place to be. It ties back to the deep work idea we discussed, where work becomes highly engaging. However, for many, achieving a flow state can be challenging. I want to set myself up to focus as best as I can.
00:13:25
In learning about flow states, I encountered Stephen Kotler, a researcher in human performance who identifies factors that contribute to achieving flow. He states we are more likely to experience high levels of focus when the task is just slightly harder and more challenging than our current skill level. That is our ideal state.
00:13:59
However, in reality, we often tackle work we've never done before, pushing us beyond our current skill set. This can particularly apply to those new to software development or just joining a team. At Workforce.com, we've hired people fresh out of boot camps and computer science programs, and our growing team has onboarded many new members in the past year.
00:14:18
As a result, we frequently work on projects that stretch us. We need a way to manage this skill-to-challenge ratio, ensuring the team feels engaged, is making progress, and does not feel stuck or like they're just spinning their wheels. While making tasks easier is not typically feasible, we can help elevate the team’s skills.
00:14:56
One way we've done this at Workforce.com is by building opportunities for pair programming and small group collaborations. This allows individuals to work closely with others who have the same context, which is invaluable when brainstorming ideas and problem-solving.
00:15:20
Working closely with others encourages learning alternative problem-solving strategies, improves the ability to communicate complex technical concepts, and helps develop precise questioning skills—an asset at any level. This paired work has been particularly beneficial as we've onboarded new members, as each member has more experience with our processes and codebase than those who are new.
00:15:44
In addition to hands-on learning, we've also found it valuable to set aside specific times for skill-building. The last few weeks of every cycle are our cooldown period, which is more developer-driven, allowing team members to choose how to spend that time. For newer developers, this is an opportunity to build skills and knowledge they will need for the next cycle.
00:16:06
They might take a course or pick up a bug fix that exposes them to a new area of the codebase. For more seasoned members, the cooldown affords opportunities to work on projects that are personally interesting and exciting.
00:16:34
I enjoy seeing what people take on during cooldown periods, as many team members experiment with proofs of concept for new processes or products. Someone even built a QA tool recently that benefits both our product and implementation teams. The results of this self-directed learning can amplify the overall performance when sharing insights with the team.
00:17:05
One way we do this is through our US product team's annual retreats. We treat these retreats as mini-conferences, and everyone on the team prepares a lightning talk of around ten minutes on a topic related to our tech stack.
00:17:26
It's a wonderful opportunity for team members to go deep into a subject they are passionate about and share that knowledge with colleagues. Additionally, every two weeks, we hold organization-wide engineering talks that focus specifically on our codebase.
00:17:43
During these talks, one or two people present technical challenges they've solved or best practices for using new tools we've integrated. We have found these talks especially useful as our offices grow, as they foster sharing institutional knowledge that cannot easily be obtained elsewhere.
00:18:06
We've explored practices around engagement and upskilling. Now, let's discuss how our processes can help us deliver the most value to our users. There will always be more opportunities to add value than we have time for, so we need a way to compare and prioritize them.
00:18:30
When considering added value, we can think about it in terms of effort and impact. At the betting table, we focus on taking big bets, tackling easy wins, and looking for ways to gather early customer feedback to ensure we remain on target.
00:18:54
An example of a big bet we recently took was deciding to entirely rebuild our mobile app. Initially built using React Native, the US team spent a couple of cycles recreating the app in Rails while adding Hotwire for interactivity.
00:19:24
This case study is interesting because we could have spent that time adding new features instead of changing our tech stack. However, we took the bet that adding Hotwire would enhance our competitiveness in the long run by allowing us to ship updates more quickly and deliver them to our users fast.
00:19:45
The rebuild of the mobile app highlighted how the Shape Up methodology facilitates identifying the most important work and shipping it efficiently. Our priorities were clear during the app rebuild; we didn't want it to become an extended project.
00:20:15
The appetites for various features reflected this. To limit time investment, we initially focused on achieving parity instead of adding new features, and setting an appetite helped us concentrate on delivering value.
00:20:34
By establishing built-in checkpoints, we ensured the work remained useful to our users. If something does not get completed within the given appetite, we don't automatically carry it into the next cycle; it goes through the pitch and betting process again to be compared against emerging opportunities.
00:20:55
This means we do not maintain a backlog; each cycle begins with a clean slate. For developers, this results in no long list of unrelated tasks competing for attention against current projects, and a clear goal line at the end of each cycle makes it easier to track progress.
00:21:23
The mobile app project reinforced the importance of iteration for delivering value. While iteration isn't unique to Shape Up, it is integrated within it. Shape Up emphasizes focusing on vertical slices of work so users can complete basic tasks.
00:21:41
A common example is that a user might eventually want to build a car to get from point A to point B, but you start by giving them a skateboard, allowing them to achieve basic functionality while the full product is in development.
00:22:06
In the case of our mobile app, iteration meant ensuring users could at least perform the same tasks they did with the old app. We aimed to strip in vertical slices because of the benefits they provide: feedback from users early on and the freedom to move on to another task should a more valuable opportunity arise.
00:22:27
For our team, we decided to iterate in a second cycle and informed our decisions based on feedback we collected from the actual product. Therefore, you now know the basics of the Shape Up process: identify problems, pitch solutions, and bet on the most worthwhile issues to resolve.
00:22:45
Additionally, you've heard what has worked well for us at Workforce.com, particularly how we shape our processes around moving quickly, building an engaging work environment, and prioritizing essential work.
00:23:06
I hope this sparks some thoughts regarding your work experience and highlights opportunities to try new methods or rethink processes not functioning well. Returning to our initial idea, processes should serve as background structures, not take center stage.
00:23:30
When boiling down the essence of our work, it is not about adhering to a specific methodology. It is about the people we collaborate with—the individuals we build products for—and our shared goal of delivering value while having an enjoyable experience.
00:23:51
Thank you. We do have a table in the food room, though I'm not sure what it's called. If you want to come by and discuss further, I'd love to chat. We have several members of our team here, so if you'd like another perspective on what the Shape Up process is like, feel free to talk with one of them.
00:27:14
We have a few minutes left, so does anyone have any questions? That's a great question! You asked how our reactive team defines its tasks versus what goes through the pitch process. We've recently discussed this internally. We are trying to make the reactive team work on things we don't anticipate.
00:29:06
It might be an unexpected opportunity or a way to address a customer's suggestion. If you work on something more extensive, say that takes longer than a six-week cycle, we approach larger tasks by breaking them down into smaller vertical slices.
00:29:32
We can gradually ship incremental features but remain flexible, avoiding committing to something that could change in value if priorities shift. Are there any more questions? Alright, thank you all for attending today—I really appreciate it!
