How we split our week at GreenShoot Labs and how that connects to our long-term goals and initiatives alongside some personal thoughts on the pros and cons of short 1-week sprints. In the of Raw Product we talked about our experience launching on the Slack store and some of the learnings from that. In this episode I share how we organize our week to try and combine long-term goals with more short-terms reactions in a hybrid Scrum/Kanban method. last instalment The usual disclaimers apply. This is just how we do it — not THE way to do it and it works for our current team size (a small, focussed, distributed team of 6). I find reading how other teams approach these issues very useful so hopefully this is a way of paying forward for the knowledge and experience sharing that I gained from. The big picture — Goals and Initiatives Before diving into a single week it’s worth looking at the slightly bigger picture. Beyond our strategic vision we set ourselves monthly and quarterly goals with measurable outcomes. These then translate into specific initiatives (larger, coherent pieces of work) and an understanding of how much time we want to dedicate to any initiative. For example, one of our current goals is to make the SaaS app buyable! Yes, I know that is a pretty basic thing for a SaaS tool. We launched early and didn’t worry too much about how people would pay us. We threw together some somewhat reasonable prices, used and so we can accept payments but hardly touched any of the out-of-the-box settings. Now that we know people are actually interested in the tool and that they are even willing to go through the very basic payment process we are ready to invest the time to make that payment process enjoyable, more relevant and something that inspires confidence in our service. This means proper modelling of alternative price plans and implementation of the tech to support those plans, design that is in line with our current brand, and generally a process that reassures (it also means properly figuring out the joys of charging for VAT — sales tax — across the EU). These points also roughly translate into the initiatives that will support the overall goal of making the application buyable. Laravel Spark Stripe As a sidenote we have recently moved our planning into . We find it a very comprehensive (even if somewhat complicated) tool and right now it fits very well with our approach. So much so that we have directly adopted from it a lot of its product terminology (things like goals, initiatives, ideas, features, etc). Aha! Ok — with the big picture mostly in place lets look at how a single week shapes up. Monday Release, analyse, re-plan (if needed) We try and release as often as possible but Monday is the “official” release day. Anything not released during the previous week that has passed all the code review, testing and QA phases will get released on Monday. The person responsible for the release has this as the main task for the day while others are available to jump in if issues arise — otherwise people get started with their sprint tasks. We hope one day to automate many more of these aspects so that release is not something someone has to be responsible for but we are not there yet. Monday is also the day we analyse feedback from the previous week in a focussed way, and turn it into actions. We use tools like Google Analytics, Hotjar, New Relic and our own metrics on app engagement. With data at hand, we then review our initiatives and decide whether any course correction is required. We ask ourselves questions such as: Are we seeing the expected outcomes from features that were released previously? Is there any new data / understanding that points to different features to develop or a change in goals or initiatives? Are there any infrastructure, security issues that require explicit attention? From a technical and UX perspective, do any of the bigger pieces of work require re-thinking now that they are further along the way? Key to this being an effective process is that we are all very open and willing to accept that what we thought last week to be the absolutely best course of action may simply no longer be that. is definitely emerging as a defining aspect of GreenShoot Labs culture. Strong opinions loosely held Tuesday and Wednesday Develop, design, mockup, discuss, plan Tuesday and Wednesday are getting stuff done days. It is a combination of deep, uninterrupted creating and collaboration where appropriate. That means coders code, designers design, UXers mockup, planners plan, and we all share ideas and support each other to get stuff done. By Wednesday afternoon we would have ideally released a couple of new features, have mockups for new features, and have a plan for the week after next in terms of specific tasks to do. Thursday Feedback By Thursday we aim to have enough done so that others can feedback on it. We can discuss technical challenges of features, and provide feedback on mockups. While not easy, our aim is to do this for the work for the week after next so that the thinking can have its time to brew in our individual brains. Friday Wrap up, review, retrospective and plan next week By Friday we are wrapping up our sprint. We review work done, what we are going to release, what remains on the board, and what new items move into the board based on availability. We run a retrospective of the week, identify what went well, what didn’t and what we will aim to improve. The good, the bad and the ugly The weekly map I describe is a somewhat idealised version. We try to stick to it as closely as possible but we don’t beat ourselves up if it doesn’t always go like that. We are a small team and we need to deal with whatever issues come up. In general, here are some thoughts I have about the process: We are a small team, we communicate frequently. Still we’ve found that things can go off course. Had we not had 1-week sprints those deviations would have been actually costly. 1-week sprints force all the units of work and planning into far more maneageable pieces. 1-week sprints saved us multiple times. Before GreenShoot Labs I almost exclusively worked in 2 or 3 week sprints. Also a lot of the work was from within an agency for customers. I dread to think of having to run at this pace with a large team with multiple stakeholders. Having said that I would very reluctantly go back to bigger sprints. I am not sure how it would scale to bigger teams. The running joke is that by the time we hit the end of the week someone will invariable pop-up and say “I can’t believe it is Friday already”. I love that. The pace is exhausting and fantastic. To be able to keep up the pace we need to … pace ourselves. A few months back I went through a few weeks of much more intense work in order to get stuff built but quickly scaled back. It was not sustainable. Balance with the rest of life is crucial. My (obvious but not so easy to implement) learning: Building a SaaS company (especially a bootstrapped one) is a marathon. Perseverance and continuity is far more important than burning out in a ball of fire. That’s our week. Would love to hear your thoughts, suggestions and if you have a similar post please add it to the comments. builds products that use automation, data and conversational interfaces to make teams happier and more productive. GreenShoot Labs Our first product is live on the Slack App Directory — makes working through common, repeatable processes and tasks better for your team with automated notifications and reporting. TeamChecklist

Alongside

Ball

Google

Slack

Stripe

Uninterrupted

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

How we build our SaaS product in 1-week sprints — Raw Product Ep. 2

Too Long; Didn't Read

People Mentioned

Companies Mentioned

Ronald Ashri

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

How we build our SaaS product in 1-week sprints — Raw Product Ep. 2

Too Long; Didn't Read

People Mentioned

Companies Mentioned

Ronald Ashri

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES