One size doesn't fit all

Life is full of lessons—some we choose to ignore, and others we act upon. This lesson is one that I’m personally acting on, and my team are the catalyst.

one-size.jpeg

Life is full of lessons—some we choose to ignore, and others we act upon. This lesson is one that I’m personally acting on, and my team are the catalyst.

We—the Workshop at Pusher—are a newly formed team of three, made up of individuals who have experience in Frontend Development, Design, Product & Project Management.

Our mission…see previous post whoami.

Setting the scene

My background is in Product Management leading large teams of other Product Managers and Developers. Now in those teams we always had a PM, Scrum Master/Tech Lead and Engineers (some even had a BA). These were always within the Scrum defined magic number 7 +-2.

We created user personas, used Jira and had all the typical Scrum ceremonies. We were successful: we delivered on time, on budget, and within the agreed-upon scope—in short, we were a well-oiled machine.

When the Workshop was formed I set up a similar Scrum process: we scheduled our rituals, set up our tools, and agreed on how the process would work. We were confident that we’d soon have a well-oiled machine of our own. We were wrong.

Why did it fail?

It killed productivity. All of my previous experience was in larger companies with much less ambiguity and more tightly defined roles & responsibilities. Pusher is a startup (well, probably a scale up now) and we don’t have these luxuries. (Yes, we’re hiring—check out our careers page and let me know if you’d like to join our team)

With all of our best efforts we spent too long in planning, we didn’t have enough detail to estimate with any level of accuracy and there wasn’t anyone who can refine requirements. We’re a small team with no PM, no Scrum master and definitely no BA.

So what have we changed?

For smaller changes we’ve shifted our focus to explicitly allocate a fixed amount of time for the work. With our larger initiatives we’re experimenting with Design Sprints.

We made sure we all share the same context of the work. We over-communicate about everything—from company strategy, to OKRs, to our goal-oriented roadmap, and all the way down to individual blocks of work.

We’ve changed so much as a company in the last 12 months that our brand identity, communication style and product offerings have all changed. We have only recently defined these and experimented enough to feel confident in our choices.

So far so good, we’re shipping value to users and the business daily.

What the future holds

Now this process won’t work for us forever, however, for where we are as a team today this is producing the best results. I know in 6 months or so as we grow, as new people join the team the process will change again.

With every individual that joins it brings a new perspective, a new experience and a new opinion.

The key lesson here is that even if we have relevant experience it doesn’t mean we can just apply the exact same process to a different environment. We use our experiences as tools to shape the future, every person is different and what works for one set of individuals rarely works for another.

One size definitely does not fit all.

  • agile
  • projects