Why is Scrum not agile enough for freelance teams


Why is Scrum not agile enough for freelance teams

Common sense customization for small startups running the dev with freelancers

I help small startups set up and run their software product development. Get in touch: www.tijanamomirov.com

A small, early stage startup will typically opt for freelancers. There are simply no resources for full time employees, nor there is much sense in investing large amounts while still in the MPV phase. With the easy access to the remote freelance talent we have nowadays, you as a business (idea) owner can start your startup adventure by contracting a few experts to help you get out there with the first version of your product and then take it from there. And that’s agile, right? Get the feedback and move on.

I’ve been freelancing (fully remotely) since 2010, as a software engineer and product manager (and Scrum master on some projects) and here are a few occasions when I really didn’t see Scrum fit:

  1. Measuring the team velocity makes little sense when the team members don’t work the same amount of hours each week. In addition to that, the team doesn’t consist of the same members each week. For example, we’d have a front end developer for a month with us working full time to build the UI, and then join every once in awhile when we need certain adjustments. Tip: What makes more sense is Kanban alike flow, and with the board you can create right there in GitHub, it comes really naturally. The items get moved from column to column, it’s visual and easy to track. Even the team members who are not with us on daily bases find it easy to hop on and get up to speed with their assignments. The bottlenecks are easily spotted when you see a column getting filled up. For more details about the board, check my blog post Kanban board within GitHub — a simple solution for small startups.
  2. Sprint scope changes are a reality in a small organization where having a separate development and maintenance teams is next to impossible. As soon as we go live, we have to be prepared for bug reports coming in. And those cannot be left to wait for 2 weeks for the next sprint. After all, “Responding to change over following a plan” — http://agilemanifesto.org/ Tip: A bug in production would fly straight into the ToImplement column with the highest priority label on it (again, use common sense, if it’s just a few pixels missed, it can peacefully go into the Backlog and wait for its’ turn). If you have the “don’t interrupt unless something is on fire” policy, this is when the fire happens. And this is the only occasion when the same developer would have more than one item in the InImplementation column (the feature that’s been put on hold and the bug that he’s just picked up).
  3. Scrum daily standup to set focus at the beginning of a new working day can be more trouble than it’s worth when dealing with time zone differences. It doesn’t make sense to set somebody’s daily focus in the middle of their day (or even worse night, was my case for a few months…). In addition, if a part time freelancer works on a couple of projects at the same time, the multiple daily standups will probably turn into an annoyance and productivity killer (been there done that). Tip: I like using GeekBot, which is a bot for Slack. Geekbot will kindly ask the three famous standup questions (customizable) at 9am (customizable) in each team member’s time zone and post it to a channel of your choice (I normally create a separate channel, so that our main team channel is kept for humans only; Btw, the same I do with the GitHub, Cloud 66 and other alerts — a dedicated notifications channel works the best in my experience). When I come online, at the beginning of my work day, I can have a nice overview of the team members’ statuses. In case of impediments, I can always decide to follow up in the team channel, or by direct messages etc.

When Scrum is a keeper

That said, there are many concepts from Scrum that are very valuable for freelance software development teams, for instance:

  • Daily standup (async as explained above)
  • Only going into the details when specifying the high priority features
  • Everything should be in the backlog
  • The sense of iterations. Aim at deployment every second Thursday (you can try Friday if you don’t mind your weekend vanishing from time to time). The features that passed the QA acceptance (or user acceptance as well, depends on your flow, as mentioned please refer to my blog post Kanban board within GitHub — a simple solution for small startups) by the targeted deployment day, will simply go live. In case of a bug in production, you’ll probably want that fix deployed sooner. In addition, I suggest introducing the iterations on the requirements engineering side, more about that can be found in my blog post The dev flow is great, but what about the requirements flow?.
  • User/customer/market feedback should be the main shaper of the roadmap.

Makes sense? 😉


Source: Medium:Remote Working
Why is Scrum not agile enough for freelance teams

Leave Your Comment