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:

• Shape Up vs Scrum: 6 Months to 6 Weeks – How We Cut Our Dev Cycle 75%
• An Interview with Ivy: Shape Up From a Product Designer’s Perspective
• Ditch Scrum! 3 Shape Up Processes & Checklists to 5x Your Dev Cycle

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.

• Q1: Summarize what the EPD team is, and your role within the team.
• Q2: As a Product Lead what would you say are the key differences between Shape Up and say something like Scrum or Kanban?
• Q3: How do you find working in small highly focused cycles as opposed to Sprints
• Q4: Does the Shape Up method allow for more asynchronous communication (and less meetings)?
• Q5: 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?
• Q6: What does Shape Up empower you to do?
• Q7: 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.

Let’s get started!
Continue Reading

We’ve cut our development cycle by 70% since making the move to Shape Up.

This alternative development method is a breath of fresh air from all things Scrum, Agile, Kanban, Scrumban, Fake Agile, Bad Agile… you get my drift.

What started off as Basecamp‘s internal approach to developing and shipping software at lightning speed, has become a clearly written (and illustrated), freely contributed, and easily accessible e-book: “Shape Up: Stop Running in Circles and Ship Work that Matters“.

Although I sincerely recommend you read the book, this post is here to save you from studying the 143 pages of text by providing you with three nifty checklist templates. The checklists take you through the Shape Up process and its 3 key phases: Shaping, betting, and building.

In this post, I’ll briefly touch on the fundamental concepts of Shape Up’s approach. I’ll also introduce each of the phases and their corresponding checklist.

• Shape Up process: Key concepts
• Shape Up processes to help you get started
• Shape Up process: Shaping 🔹
• Shape Up process: Betting 🏇🏻
• Shape Up process: Building 🏗
• Shape Up process: Summing up

Let’s get shaping!
Continue Reading

I wrote a post about Shape Up, a development methodology, and you the reader wanted me to dive deeper. So, I did just that and interviewed Process Street’s Product Designer, Ivy.

Ivy answers common questions concerning how Shape Up works in practice, and although I briefly touch on the core phases of Shape Up’s approach, this post should be seen as a follow up to my original post which provides a full low-down of what Shape Up is and how it differs from alternative development methods like Scrum and Kanban.

So, make sure to read my last post on Shape Up so you have all the context you need for this post.

In this post, we’ll be covering:

• What is Shape Up?
• The makings of a Process Street Product Designer
• Shape Up from a Product Designer’s perspective
• Shape Up’s design process: Key takeaways
• The day-to-day Shape Up experience as Process Street’s Product Designer

Let’s kick things off with a brief re-cap of Shape Up’s key phases 🚀.
Continue Reading

Until a few weeks ago, I had no idea what exactly a full-stack engineer was, let alone what the role entailed. I know, I know – I work for a tech startup, I should know these things.

You’re right; I should.

So, to educate myself, I sat down with one of Process Street’s engineers, Herbie Porter, to discuss what he does, his first year at Process Street, and the art of making pandemic cocktails:

• The very distinguished Mr. Herbie Porter
• One year ago today…
• The makings of a programmer
• Shape Up with Process Street
• Essential tools for the discerning engineer

It is my privilege to introduce you to…
Continue Reading

Kamelia Stone is Content Manager at Marketbusinessnews. She likes to travel, meditate, and draw inspiration from different sources, primarily from books.

Software Requirements Specifications (SRSs) document describes the various software features, capabilities, coding tests, and functions that are to be implemented in the product.

These parameters also include characteristics, design details, and implementation obstacles for the development team. The structure of SRS can be modified, depending on the project, and various features/functions can be added during the process.

SRS lies in the initial, bottom stage of the entire development process. The next stages include user requirements, which detail the needs of end-users, and describing beyond the goal of the final product (business requirements).

No matter how the SRS structure is shifted during the development process, functional (if/then, data handling, etc.) and non-functional (usability, scalability, etc.) requirements always take place.

This post for Process Street will discuss:

• Choosing a development model: Waterfall or Agile?
• Key attributes for composing a strong SRS
• Tools to simplify software requirements specification management
• A final word on the software development process

Now let’s get straight to business.
Continue Reading

This is a guest post by Gabe Nelson. Gabe is a content specialist with over 7 years of experience, currently working with Semaphoreci.com. He has a passion for programming and has written hundreds of content pieces in numerous niches. Currently, he lives in Missouri with his wife and kids.

Let’s face it: the longer your software takes to get from ideation to iteration, the more irrelevant it becomes.

With the innovation of new paradigms and working methods to meet the right here/right now demands of consumers in a hyper-connected world, your developers need workflows that will deliver your software into production environments the second they’re able to.

The millisecond micro nanosecond, even.

Managing your software deployment processes and procedures to not just keep up with, but stay ahead of, the competition can seem like a Sisyphean task, but it doesn’t have to be.

Continuous integration (CI) and continuous delivery (CD) together constitute the light at the end of a software developer’s tunnel. No doubt that’s why implementation is commonly described in terms of “pipelines” – CI/CD takes you straight through the problems.

More specifically, CI/CD pipelines make it easy for developers to deploy working code into functional and error-free production environments. That’s because these workflows do a great job of automating entire pipelines of your team’s code releases and updates. This frees up developers to create new features and processes instead of spending hours debugging faulty code.

In this Process Street guest post, I’ll do a quick walkthrough of the basics of CI/CD, then dive into how CI/CD can generate more value for and quicken your software deployment.

• What is CI/CD?
• Commit to the build
• Automate testing throughout deployment cycle
• Initiate software deployment
• Documenting your deployment life cycle
• The value of CI/CD pipelines in software deployment

Read on…
Continue Reading