How to Ship in 8 Weeks or Less (via Cross-Functional Teams)

Bored of Scrum and Kanban? Thinking about making the move to Shape Up?

This post is here to get you clued up on what the development methodology Shape Up looks like in practice. I’ll be giving you a sneak-peak into what we do here at Process Street as our EPD team shares their secrets. Learn how Shape Up facilitates the smooth running of a cross-functional team.

For those of you who are unfamiliar with Shape Up, or if you’re interested in the Design part of the E-P- “D = design” team,or maybe, you’d like to get your hands on 3 Shape Up workflows to plug straight into your team, check out the following posts:

In this post I speak to Process Street’s Product Lead, Michael, and our Full Stack Engineer Herbie. We talk about all things Shape Up and discuss how the methodology facilitates the success of a cross-functional team.

Let’s get started!

1: Summarize what the EPD team is, and your role within the team.

Michael, Product Lead:

“EPD is the acronym for Engineering, Product and Design, this tends to be the balance of dimensions for most product teams. In general, once you have a good give and take between these three pillars of product, as in creation, ideation, and actual execution, you have a really strong firing, working team.

My role as Product Lead is to represent the interests of the business and the users equally and to try to find the right problems that we need to solve at the right time.”

2: As a Product Lead what would you say are the key differences between Shape Up and say something like Scrum or Kanban?

Michael, Product Lead:

“It was Scrum when I began. I think the biggest change for me as a Product Lead is that Shape Up gives me more time to focus on strategy, and less on the overhead of day to day execution.

As Product Lead or Manager, depending on where you work, and how it gets balanced, a pretty significant amount of your day can be taken up by project management. That is something that is definitely reinforced in Scrum. Particularly in how the Scrum ceremonies are constantly happening throughout the week.

Looking back, I’m not sure the overhead that Scrum has is really worth it and I don’t know that we get the ROI from it. Being in the Shape Up world allows us to focus more on strategy and allows us to dig in deeply with our customers and focus on our business objectives.”

“Shape Up allows me to lean into the aspects of the job that I find most satisfying, aspects that I think most product managers aspire to do more regularly.”

“In fact, for many product managers, and myself in previous positions, it’s a pretty common lament to be spending too much time writing stories or managing the backlog. Whereas Shape Up is really concise and focuses on the best thing we can do right now.”

Herbie, Full Stack Engineer:

“For me, one of the biggest differences between Scrum and Shape Up is the way we manage our backlogs and the way we manage the vision or the to-do list for the product. Scrum and Kanban historically have a product backlog that contains all the things you’d like to do over the next month, six months, or 12 months. This backlog often gets quite unwieldy and becomes hard to manage, it also requires a lot of grooming.

Grooming in Scrum and Kanban basically means going through the product backlog, making sure everything’s still relevant, and building out requirements for it. As an Engineer, that used to burn up a lot of my time.

In Scrum and Kanban, once a week, you’ll have a refinement or backlog grooming meeting. In this meeting you go through the backlog and make sure everything’s in the right place and in a good state.”

“Shape Up on the other hand is very lean, and gets rid of the concept of a backlog by working in very small chunks, known as a cycle. So, from an engineer’s point of view, or my point of view, I get a lot more time to focus on what I’m building.”

“The other big difference with Shape Up is that the cycles are quite long. At Process Street, we have six week cycles, which means you get a really big chunk of time to focus on what you’re building. During that period, you’re largely left to your own devices and you’re not distracted.

This is really nice, because in Scrum and Kanban people play around with one week, two week, or three week Sprint’s but that means you have to context switch quite a lot which also means you burn a lot of time in meetings and things like that.”

3: How do you find working in small highly focused cycles as opposed to Sprints (or whatever you relied upon beforehand)

Michael, Product Lead:

“With highly focused cycles the pace is remarkably quicker. In Scrum ceremonies, it’s common to lose sight of the objective of a project because of all of the parts that need to go into it. Whereas, Shape Up is more focused on the objective and less on the various parts. That’s how we manage the actual workload.”

“In Scrum, when focusing on separate parts, often means having a project that we’re trying to build and thinking it’s going to take two sprints, and then having it extended to six sprints. This scenario is pretty common because you don’t know what you don’t know, when you start a project.

In Shape Up we focus more on the objective and the project as a whole. This means we’re shipping projects even if they’re not completely filled out with every possible part we could imagine to include within them. We are constantly focused on shipping value, so if it’s valuable to the customers, we push it out.”

“Ultimately, our cycle in terms of direct output has increased dramatically by using Shape up.”

Herbie, Full Stack Engineer:

“The highly focused cycles mean no distractions, keeping our heads down, and getting work done which is really good. I think it’s a more efficient use of our time as engineers, the more time we can spend building stuff, the more stuff that’s produced at a higher velocity.

This in turn increases our competitive edge as a company because we spend less time in meetings and grooming a backlog and more time building.”

4: Does the Shape Up method allow for more asynchronous communication (and less meetings)?

Michael, Product Lead:

“Yeah, it does. But in my experience, so far, it’s not dramatically less, it’s just that the meetings themselves are less ceremonial and more effective.

We’re having a higher quality meeting that is focused around an objective rather than a meeting that is focused on ceremony, which is what Scrum does. Scrum is always going to be the same cadence of meetings with the same purpose. And, as I said, I’m not sure what the ROI is on those meetings.”

Herbie, Full Stack Engineer:

“Yes, 100%. You get a longer period of time, there’s less meetings and more defined tasks to focus on. Although, I wouldn’t say Shape Up directly facilitates asynchronous communication. I think asynchronous communication can be applied in Scrum, Kanban, or Shape Up.”

“Process Street, obviously, being 100% remote, is really good at asynchronous communication. The EDP team spends a lot of time on Slack. We use tools like JIRA, to manage our tasks and GitHub, to manage our code and our peer reviews. So how we use those tools would be largely the same across the different methodologies.”

“The EPD team uses Slack for 90% of our communications. The team is broken up into squads and I’m a squad lead. In my channel there are three or four of us and that’s where we bounce ideas off of each other, and it’ll be quite chatty. We then have another channel that’s EPD wide, for the whole team, the internal stuff that goes in there is designed for a broader audience and it’s normally more important. We also have a social channel where we can just chat and share stories or banter and things like that. Using the channels in this way means that we can tune out of the more social channels if need be but still get notified if something important is posted.

We use JIRA as a tool for project management. It facilitates breaking down projects into tasks and assigning them to people to work on. For example, I can break down that big product idea into individual tasks and assign them to people inside my squad, and we normally do that together. It’s not me leading by telling people what to do, but rather we assign tasks as a collaborative exercise.

So, we use JIRA for tracking our progress, we use Slack asynchronously, and the last thing we use is GitHub. GitHub is where we store all our code. Basically, whenever we write a bit of code, we make sure it’s peer reviewed by at least one other person. So, if I write a bit of code, I’ll then ask Cameron (our CTO), for example, to review it. GitHub has a facility for that, and allows users to add comments on different areas of code. Once the peer review is done I can then go back into GitHub during my working day and respond to the comments, take on the feedback, and then fix the code.”

5: As a Product Lead/Engineer am I right to think you work on a parallel track with other members of the EPD team. Could you talk me through this process?

Michael, Product Lead:

“Generally speaking, yes. Although it’s not as cleanly split as that. As Product Lead, I oversee the cycle that’s currently happening to help guide towards the desired outcome that we’re aiming for. Because, as good as a pitch may be, I still need to check-in and make sure that we’re focusing on the objective. Providing oversight throughout the cycle also means that I can answer any questions as we go.

But yes, at the same time, I’m also working on a grander strategy. So, along with overseeing the current cycle I’m working on how all these projects will sequence together, what the impact of them will be, and how we will get to where we want to be.”

“It’s like the expression – the whole is greater than the sum of its parts -. That’s our objective with the Product Team, to ensure that our product strategy considers how each of the parts fit together.”

“We ask questions like: What do the parts look like as a whole? How will it change how we position ourselves in the market? How are we impacting our customers? And, what customers are we focusing on at a given time?”

Herbie, Full Stack Engineer:

“I think it’s good to go back to the beginning of how an idea flows through Shape Up, how it travels through the development team to then being in front of our users. So say Michael has an idea for a new feature, he’ll write what’s called a pitch. That pitch will sometimes include some really high level wireframes, a description of the feature, who is going to benefit from it, and why he thinks it’s a good idea.

Michael will write the pitch in isolation during a cycle, and that’s kind of a parallel track. So Michael will be working on pitches and he’ll quite often get Ivy (Process Street’s Product Designer) involved to help with putting together high level mocks. And then, towards the end of the cycle, that pitch will go to the betting table where lots of different ideas (or pitches) go on the table. Then senior stakeholders look at them all and choose the ones that are going to give our users the most value.”

“The whole pitching and betting process runs in parallel to the engineers who are building.”

“Whilst all the engineers are focused on building the pitches from the last betting table, future plans for the next cycle are underway. This is nice because it means we engineers are left to focus on what we’re doing, whilst the product team are busy figuring out what we’re going to be working on next.

Towards the end of a cycle, there is a little bit of cross pollination. So quite often, just before the betting table, Shapers (like Michael), will ask engineers for their feedback on ideas. Then those ideas will go to the betting table and the most impactful ones will be chosen and taken forward into the next cycle. At the end of the cycle, or in the cooldown, we get told what we’re going to be working on during the next cycle.”

“In essence, I think the parallel tracks really help us to focus on different areas and not get too distracted while also encouraging cross pollination when it’s needed.”

6: What does Shape Up empower you to do?

Michael, Product Lead:

“Focus on strategy.”

Herbie, Full Stack Engineer:

“Some of the key premises of Shape Up are ownership and empowerment. This means that once Michael comes up with an idea, and it goes to a betting table and is chosen, it gets handed over to the development team. From then on the development team are largely left to run with it and see that idea come to fruition.”

“Michael, the Product Lead, will lay down a very broad stroke of what he envisions, but it’s up to the development team and the designers to build that out. This is where the value of ownership really shines through in Shape Up.”

“In methodologies like Scrum, or Kanban, the product owners and business analysts will be involved throughout the whole process and that can slow down the project. If you have lots of voices, lots of opinions, this can slow the process down.

Whereas in Shape Up, it’s largely left to the development team to build out the idea once it’s been chosen. The onus is on the development team and the designers to see that idea through.”

7: This is your area of expertise, what are your key takeaways when it comes to Shape Up, how it works alongside the EPD team, and so on.

Michael, Product Lead:

“I think one of the bigger points that maybe other people have made is how Shape Up really does shift ownership around so that a single individual is not accountable for all things that happen. It really empowers the team to make decisions, rather than waiting for me or Ryan (VP of Product & Engineering), or someone else to weigh in.”

“By empowering the team we get two key takeaways: One, we get a better output. Two, the team has more ownership over what they’re doing.”

“This ownership then helps to drive excitement within the team. The autonomy and mastery side of the team’s craft is enhanced and supported by Shape Up much better than it is in Scrum. At least in how most people, or most teams, use Scrum.”

Herbie, Full Stack Engineer:

“I have a friend who works in banking and he is still practising other methodologies. When I talked to him about Shape Up I summarized the key differentiators as: An ability to focus, a reduction in meetings, and the level of ownership.

The other key takeaway is that Shape Up really empowers, not just the development team, but also the product team, and all the way up to the C levels.

In Scrum, you might have a six month backlog and if the CEO comes up with an idea, that probably goes to the back of the queue, and he has to fight to get it to the front. Whereas Shape Up is extremely agile and with each cycle the betting table starts afresh. So every six weeks, everything goes to a fresh betting table with equal footing.

Starting afresh enables the engineering team to be extremely agile and respond to different market pressures, market demands, and ideas from different people (including the CEO) easily without having the overhead and burden of a six month (or two year) backlog. I have worked at places where sometimes your backlog is a year long, and there’s roughly 500 tickets in there.

The backlog is ultimately this unwieldy mess of ideas. Some of which people came up with two years ago and haven’t been touched for ages to the point that you’re not even sure what they were for anymore. But, as an engineer you spend all your time grooming this backlog and this isn’t really providing any value to you or the company.”

“By completely dismissing the idea of a backlog, Shape Up encourages you to focus on the near term, to focus on what’s providing value now and what’s providing the most value for your users.”