My company often works using the Agile Scrum methodology/practices, but when people know my company only has one full-time employee they wonder how I can make such a claim. Scrum was first defined in 1986 and has been well established since the turn of the millennium although the majority of companies still struggle to implement Scrum practices, even in the technology sector for which it suits so well. It’s my view that you shouldn’t take Scrum strictly, instead work out what to implement given your understanding of your company size, history, and the team members’ attitudes/knowledge of Scrum. I’ll go ahead and explain the roles and events of Scrum so that I can include how they relate to my one-person company.
It’s cycles that primarily differentiate Scrum from the non-agile and more commonplace practice of Waterfall models. The diagram illustrates it well, work in cycles of specifying features, designing them, building them, and testing. Unlike waterfall that spends time designing every aspect before having anything built. Its clear that you don’t need to be a multi-person team for either of those methodologies.
Roles are my favourite part in learning and teaching about Scrum because knowing project-specific job descriptions of yourself & colleagues eases knowing what you’re expected to do and what you can expect. By myself I can look to see if any of the roles can be filled by external people. Teaching clients, partner companies, and freelancers about my favoured working practice shouldn’t be disregarded as an option, especially if it helps them know when and how to engage without adding overheads to the schedule. If external people aren’t willing or suitable to hold a role, which could even happen if they were internal, then I have different metaphorical hats to wear and switch my mindset for each.
- Product Owner interprets what the client wishes are and the priority ordering they would give to tasks. I obviously need to do this when quoting and agreeing work, but it’s also good to think about the Minimal Shippable Product. If problems occur and all tasks can’t be completed, what should I focus on shipping to the client that they’ll accept as working even if its not yet all their requests and dreams? In better scenarios, what can I demo before deadline to impress them that work is underway?
- Development Team should be no more than 12. They need to know what each other is capable of and what they’re good at doing well, doing quickly, or helping others to do. That’s easier between myself, but I still need to know my limits and speeds for planning and I need to know when to get freelancers, when to outsource, and who is good to call on for different tasks or situations. A friendly, social, development team is really important, and when doing “Scrum For One” it means local tech meetups are critical.
- Scrum Master heads up the development and checks everyone is okay. Am I okay, is anything getting in the way of my work or stressing me out, can the scrum master do anything about that or do I need to address it myself? Business mentors could be really good at that, or friends that have a mentoral role in your life, because having someone to gripe to can make you realise there are problems you need to moan about and then address. It’s also why co-working is important. Familiar faces working besides me, that feel when I am stressed or underworked, that care about my work troubles and work loads even if they aren’t doing or understanding that work themselves. That last sentence describes Scrum Master best of all, regardless of team type.
- Blocker gets between the development team and anything that hampers them. It’s usually the Scrum Master but I include it as a whole role for significance. A lot of being a blocker for myself is about choosing where I work so the environment is appropriate given the current job. Occasionally being a blocker to distractions means closing email, social media, or even leaving my phone in the next room for just an hour. If it rings twice, I’ll look at the caller id to check it’s not you.
Moving on to events, usually an obvious sign that a company is trying to run by Scrum or general Agile principles.
- Sprints can be 2 or 4 weeks long. A lot of the projects I’ve been working on aren’t more than a single sprint wrong, but that doesn’t mean I can’t call them a sprint and go through the motions.
- Sprint planning involves assigning “story points” to tasks, a combined value of their difficulty and expected time because time-only estimates won’t be true. A fun way to assign good story points is planning poker, which I can’t do on my own. I could get better at writing down specific points (rather than estimating time, which is wrong) so that I can track and compare the accuracy of estimations. Monitoring story point estimation and burn out rates is probably a lot better done by a Scrum master that is more mentally-detached from the development team than I am.
- Daily scrum/stand-up in the morning it’s still good to get the team to down tools, step away from their desks, and talk about what they did the previous working day and what they plan to do today. I only really do this on Mondays and it revolves around a postcard to-do list I carry in my pocket. I’ll count the items on the list, and how many were done, transferring numbers to a sketched graph. The graph has no quantitative purpose, but allows me to review how I felt and whether a dip is because I had a big to-do (for which I refer to a digital task list specific to that project) or because I had something blocking me from work. I then transfer outstanding items to a new card, add new ones, and think about how I’m going to complete them or where is best to work this week.
- Sprint retrospective is very different when you haven’t got a team to honestly discuss how you could have been better in the small bits of work. I’m trying to put more effort into getting feedback from clients, potentially to use as testimonials but primarily so I can look at and improve how I work. This is hard, as even a brief think and reply to an e-mail doesn’t seem worth some people’s time. Other times the project comes to an end with people moving companies or departments and relationships getting lost on the way.
- Sprint review shows what you’ve accomplished, and that shouldn’t have to stay internal. I’ve tried sending a mailing list to clients and partners about my challenges and achievements but I didn’t feel I could get a time pattern right, however I do some blogging in such a matter on a few sites – such as this post! I can’t shout out everything externally, so I will often send messages to the client about feature suggestions if future budgeting/time allows. Such features will often be based on the work done that went well or was accepted by the team/client with excitement. For clients that have me manage their web hosting I’ve started making it a standard offering to include a 1-page review of stats/usage and my suggestions on content or feature improvements, that must be nicer to get than an annual invoice on it’s own.
I’ve opened up and potentially made myself quite vulnerable by being honest about my business weaknesses in this article. I hope it’s been worth it to help you understand Scrum or how I work. That relates to whether you’re a client, partner, or just an interested lone developer or a curious mega corporation. Remember, you don’t have to implement Scrum strictly, and learning how others do Scrum is good for considering adaptions you might make.