Get you clued up on what the development methodology Shape Up looks like in practice and sneak-peak into what we do at Process Street as our EPD team shares their secrets.
8257 interfacing 2 in microprocessor for btech students
How to Ship in 8 Weeks or Less (via Cross-Functional Teams)
1. 1/10
July 14, 2021
How to Ship in 8 Weeks or Less (via Cross-Functional
Teams)
process.st/cross-functional-team
Molly Stovold
July 14, 2021
Process Street, Software Development
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.
2. 2/10
Let’s get started!
1: Summarize what the EPD team is, and your role within the team.
Source
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:
3. 3/10
“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.”
4. 4/10
“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.”
5. 5/10
4: Does the Shape Up method allow for more asynchronous
communication (and less meetings)?
Source
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
6. 6/10
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.”
7. 7/10
“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?
8. 8/10
Source
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:
9. 9/10
“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.”