I recently joined a startup after years of working in much larger and longer-established organisations. The first thing I noticed when comparing my new workplace to my previous jobs was the distinct lack of structure in almost every aspect of the daily goings-on. I guess I shouldn’t have been surprised by this, startups are known for their fast-paced, think on your feet approach to getting things done. It’s part of their charm and in many ways their main advantage to the slow-moving behemoths they hope to usurp.
But as an organisation grows it becomes ever tougher to keep track of all the moving parts without having some sort system in place. The question is – how do you keep things fast, flexible and fun without getting bogged down by the same bureaucratic management pitfalls that your old-school competitors face? One way is by following modern methodologies like SCRUM!
At my previous job, the company underwent a transformation from more traditional management approaches to following the SCRUM principles. Two years, dozens of workshops and a SCRUM certification later, I feel qualified and confident enough to write on the internet about my [very opinionated] views on the subject.
In this post, I’d like to share some of the problems I noticed in my first month on the job which I think could easily be solved by introducing some SCRUM processes into the mix.
Could I have a moment of your time to talk about SCRUM?
SCRUM stands for…well, SCRUM, because SCRUM is not an acronym.
Now that we’ve gotten what SCRUM isn’t out of the way, let’s cover what it is. SCRUM is one of many Agile software development methodologies. But what is Agile? In the traditional sense, agility can be defined as the ability to quickly change your body position or the direction in which it is headed. Try to imagine a basketball player who sees an oncoming defender reach for the ball but quickly manages to sidestep to avoid losing possession, or a gazelle zig-zagging around the plains when being chased by a cheetah. That’s agility.
The same basic concept applies to the world of software development. Modern technology companies need to be able to quickly react and possibly change direction (often referred to as pivoting) to adapt to an environment with ever changing requirements. Agile as a concept is simply a collection of ideas to help an organisation achieve this agility. SCRUM is a framework which offers a structured plan for implementing these ideas through a set of guidelines and processes.
Why we need SCRUM?
After a few weeks of working at this startup I noticed certain issues which kept on repeating themselves. Of course I wasn’t the only one to take note of this, but I decided that as the new kid in town it might be easier for me to question the-way-we-do-things™. Even though I was part of a SCRUM transition before, this time is much more exciting to me since I get to directly influence the path we take by being the shepherd rather than the sheep.
So what are the issues we’ve been facing?
Unclear user stories: A user story should have all the information required to complete the task clearly defined before beginning any work. In our case most stories don’t follow any template. Many have poor descriptions and missing information such as designs or examples of the problem. They often don’t include any context so we don’t know why we will be working on this – who the story is for and what value it will create for them. No testing criteria is defined so you’re never quite sure when a task is really ready. We also don’t really list any dependencies which might eventually block the release of a story. All of this leads to a lot of back and forth, chasing people for information, constant interruptions, missing deadlines and rework.
Lack of transparency and collaboration: Tasks are often just assigned without being discussed from before. It often seems like we are pulling on the same rope but not always in the same direction. I often end up asking myself what are my colleagues working on and who is the right person to ask for help? It’s not a team if it’s just a collection of people working on individual tasks rather towards a common goal.
Unclear priorities and goals: Our backlog of tasks is unkempt and unstable. Similarly to the problem of unclear user stories, there is a lack of structure and consistency in the backlog, with priorities changing on a daily basis. The issue ranges from not knowing what to work on in the next hour, day or week, to not having a clear product vision and roadmap for long term goals. Developers end up picking up random tickets which leads to lots of time wasted on not-so-important tasks.
No process for adhoc requests: Other team members often interrupt developers with a “small” requests. These requests are often not thought through and often lead to all the issues mentioned above – they are missing information, no alignment between team members, not necessarily important.
No time for addressing problems: In my opinion, this is the biggest issue of all. We do not have a time or place set aside for addressing problems and improving process. When working hard but without taking the time to step back and look at the issues, you can become very good at doing things the wrong way!
Where do we go from here?
I’ve seen these issues before, and I’ve seen how SCRUM can address them when implemented correctly. That being said, one can’t just flick the SCRUM switch and hope for the best. It requires discipline to keep with the guiding principles and a change in mindset; not just in the engineering team, but across the entire organisation.
Over the coming months I hope to document how we apply SCRUM and other solutions to our workflow problems. The end goal here is to find something that works for us, my aim is to make that happen.
Leave a Reply