A while back, we wrote about how Shape Up* helped our EPD team 5x their dev cycle. We also talked about how it’s different from Scrum, and even did a piece exploring the dangers of fake agile.
So how are things looking, a little further down the line? Mike Schutte, a Senior Front-end Engineer at Process Street, gave us his thoughts on how Shape Up has impacted our EPD team.
How Shape Up helped us 5x our dev cycle
This section was written by Mike Schutte, Senior Front-end Engineer at Process Street
Time is perhaps the most precious resource when building a product. And yet, it’s often spent lavishly as if it’s in infinite supply. Teams often adapt timelines to fit features and requirements instead of the other way around.
The essence of the Shape Up methodology of product development is exactly that: adapt requirements to fit timelines.
We’ve been using Shape Up at Process Street for a little over a year now and our EPD team (engineering, product, and design) has more momentum than ever.
Here’s the thing: we never ship the “idealized” version of what we originally envisioned for the product. We don’t talk about things being “feature complete.” We build, communicate, revise, and repeat on a daily basis. The key is to identify the biggest levers at our disposal to add as much value as we can within the six-week cycle without compromising on quality.
The shapers identify a valuable area to invest effort in, the builders get to work, then we test the bet based on real users’ feedback. We get a lot good-enough things shipped at a predictable cadence instead of one perfect thing with an amorphous timeline.
We’re following Shape Up pretty much by the book, so there isn’t much to elaborate that can’t be found in the book or from other teams that have written about it. The key is to stay committed to the mindset of adapting requirements to fit timelines. This influences everything from how you approach meetings to whether or not to use a preexisting library to jump-start a particular feature.
By changing the teams culture from “how long will this take to build?” to “how much time are we willing to bet on this area of our product?“, it becomes easier to frame what might be seen as engineering priorities as product/company priorities. Process Street’s main application is built using an unmaintained version of AngularJS. There have been a few efforts to convert the web app to React because:
- It’s more modular than modern Angular (think Legos vs a pre-built action-figure)
- Has a vast community, which means better community resources (libraries, documentation, etc.) & more hiring opportunities
But rewriting an application and delivering features is a very challenging (and often demoralizing) task.
With Shape Up, developers are given trust and agency during the cycle to deliver value. We’ve used that trust to deliver quality features and, when it makes sense, convert more and more of our app to React. The current approach replaces angular nodes in the DOM tree with React nodes, using react2angular. While this worked many times, we’re starting to find complex cases where converting AngularJS code to React is far more complicated than just starting from scratch in React.
Thanks to the structure of Shape Up, engineers have two additional avenues to pursue this kind of paradigmatic change. First, we have the freedom to use the two-week cooldown cycle (that follows every regular six-week cycle) to work on whatever we want. With that time our team has made preliminary efforts to start an entirely separate React application, which will aid in an incremental, page-by-page replacement of the AngularJS app.
The second avenue is to frame the rewrite in terms of business value. When engineering asks product for leniency to focus on technical debt or other internal efforts, it’s natural for product to respond with “Well, how long would that take?” Pessimistic as we should be, devs are liable to say something like six months.
But there we go again picking an imperative outcome and slapping on a time label to it, which is bound to lengthen. With Shape Up, we can instead catalogue the benefits that would come from modernizing our application. Better hiring outcomes, less bugs, more feature velocity, etc.
Given these benefits, stakeholders can decide how much of the company’s time they’re willing to bet on that proposed value (we’re in the midst of that conversation now ??). Worst case scenario, we can continue to use cooldowns as our time to react-ify our product.
* (P.S. While we use Shape Up, this is not an endorsement of Basecamp or Ryan Singer).
Shape Up from a Sr. Product Designer’s perspective
Thanks Schutte! If you’re interested in hearing our Senior Product Designer Ivy Kwan’s perspective on Shape Up, you can check out our post on Shape Up’s design process.
Ivy answers common questions concerning how Shape Up works in practice, and how it differs from development methods like Scrum and Kanban.
We’ve also created our very own Shape Up workflow templates, which you can use for yourself:
A day in the life of a Process Street engineer
“I’m a very lucky person who gets paid
to do what he loves to do.”
Herbie Porter is a Full-Stack Engineer at Process Street. We spoke to Herbie at length about his day-to-day as part of the EPD team, which you can read here. He also gave his thoughts on Shape Up around the time we first made the shift from Scrum:
Shape Up encourages short, concise periods of time to solve the problem quickly and get something out. It might not be perfect, but you can iterate on it later on. – Herbie
Interested in working at Process Street? Check out our open positions!
Source link
