You’ve probably heard about it over and over again. Agile is still one of the buzzwords recruiters and companies throw around, mostly trying to sound highly organised and efficient. Regardless, these past six months have shown me how effective this methodology can be for companies that want to jump a few levels ahead and meet their full potential.
Agile is an umbrella term that encompasses a large set of software development methods. It’s a very popular model to organise teams and plan projects, since it deals very effectively with changing requirements, continuous improvement, and adaptive planning.
Although the name was set in stone in 2001 with the Agile Manifesto, a lot of these techniques and processes were already being developed and used since the 70s. Despite that, agile practices are still in vogue nowadays and are still as important and necessary as they were a few decades ago. A lot of these lightweight practices started being developed as alternatives to the waterfall-oriented methods of the time. Simply an adaptation from the physical manufacturing industry to the software development industry, this model didn’t effectively address the iterative nature of software development or the constant change of requirements.
Our agile onboarding started half a year ago, when I joined an EdTech company in London as their first Front-end Developer. At the same time, a dedicated project manager joined our ranks, bringing a lot of agile experience with him and a whole set of tools with it.
I can picture most developers’ eyes rolling when they hear the word agile. Many have experienced bad implementations of it or struggled with methodology purists, who focus more on the specific practices of agile than on developing a flexible approach that works for the particular team.
So, instead of telling you how to do agile, I’ll focus on something more personal and subjective. This article is about my company’s journey into bringing agile methodologies into a rather unstructured development process. What you’ll read are my takeaways from this whole journey, so your mileage may vary; you might even already have different way of approaching agile, which is encouraged if that’s what works for your team.
Why agile?
First of all, maybe I should explain why we got on board. When a company of 2-3 people quickly grows threefold in a matter of half a year, scalability issues start to rise and multiply. There’s just too much to handle: PR, hiring, business development, roadmaps, design, software development, quality assurance… On top of that, planning, developing and managing a product is a hard task; it’s a full-time job when your product is robust enough.
It was time to bring in a product manager, someone to be the gatekeeper between product development and business development. Someone with enough organisational knowledge and the right tools to implement it; bringing order and scalability to a rather unstructured process and keeping us focused on the right goals and features. In our particular case, the cornerstone of this whole change was Agile Scrum.
I had the chance to be part of the agile implementation and iteration on our team since its inception. Practices were introduced gently, one by one, telling the team about it and explaining the potential value of each one.
Objections along the lines of “We’ve been doing fine up until now, why are we changing?”, or “We don’t need this, our team is small”, or even “We already have GitHub, it’s more than enough” might cross your mind when agile comes to your company, and that’s ok. That’s just your lizard brain automatically responding to change with mistrust and caution. Luckily, we’re all rational human beings and we can quickly overcome our irrational and biological limitations on this.
These are the most important take-aways I’ve recognised from our journey:
Disclaimer: Agile is highly customisable, thus what I bring you today is our current flavour of it. It will probably be different in a few months, as we iterate over our practices. It will definitely be different for you, since every company is a special ❄ and unique in its own way. You should always take into account the context of your team, your project, and any other circumstances that might change the way you work.
Complexity
Agile is one more way to try to effectively manage & tackle complexity. Software development is a fairly recent craft, and its complexity has been on the rise. I’m sure every single developer has felt overwhelmed by a technical problem in their career. Sometimes the product is too ambitious, or the feature will take too long to implement. Sometimes, what people ask of us is in unknown territory and we have no idea where to start. Even when we’re experienced in a certain field, unexpected complexity might not reveal itself until we’re midway to completing a task.
Agile tries to solve this in several ways, one of which is to structure features into user stories, and keep those stories from being too big. For example, instead of having something such as “Implement user authentication”, this would be renamed into a story like “As a user, I want to login into the website so that I can access my account”. This gives a clear purpose and puts you into the user’s shoes.
The next important step, now that we have a concrete user story, is to split this story into the smallest, deployable steps. As a developer, think of them as reviewable pull requests you can assign to your colleagues (assuming you’re doing code reviews – which you should be, although that is a whole other discussion).
We start defining the most important user stories a couple of sprints before, so we can have a better idea of what it entails and prioritise accordingly. We try to keep the design process one or two sprints ahead of development, so the first mockups can be reviewed, discussed and iterated in time.
Both front-end and back-end developers take part in this discussion, to get a better idea of what already exists and what needs to be developed. This helps us to prevent problems along the line and create tasks to deal with the complexity of the user story. The smaller the task, the easier it is to grasp and understand what needs to be done in order to achieve it.
Let’s say there will be a new Settings page on our web application, which would be our user story, usually phrased like “As a student, I want access my settings so I can change my personal info”. We can split this into smaller tasks, where most of them can be developed separately: see which new components will be required and develop them (new buttons, modals, tooltips, etc.), create the new page and add some dummy content, possibly a sub-task for development of the back-end structure that will support this feature and so on.
Method
As developers, our main job is to solve problems with our coding skills. However, when you are part of a team, there’s another essential task you need to be good at in order to do your job properly: communicating. Our product development team is mainly composed of developers and designers, who need to communicate effectively in order to move towards the right direction as fast as possible.
However, simply relying on the common sense of everyone is not enough – “Common sense is not that common”, as Voltaire said. Establishing the right communication channels, processes and flows is essential to reducing misunderstandings and promoting communication. When the whole team understands how to log bugs, discuss designs or bring a new feature up to the master branch, communication is efficient and effortless. An effective process frees our minds from daily menial decisions, allowing us to focus on what we do best.
A good project management software plays an important part here. JIRA is at the backbone of our communication and planning for this matter. Although I’m not its biggest fan (it feels a bit bloated and the user experience is far from ideal), I have to admit it is filled with helpful features and flexible enough so that any team can successfully structure a productive workflow on it. Depending on your project and how you might want to manage it, there are plenty of other alternatives out there, each one of them offering a different take on the same problem.
We also brought some degree of automation to our project, keeping our JIRA tickets always in sync with our branches, using webhooks. At the moment, sub-task tickets go from Todo (default state) to In Progress (when a new branch with the ticket reference in its name is pushed to GitHub) and moving on to In Review when a pull request is created from that branch. Finally, they transition to Done when the pull request is merged. Each ticket reflects the current development state of a feature or issue. This process minimises the back & forth developers would have to do, coding their way on GitHub and then updating the necessary issues on their project management software.
Discussion
One of the best things I appreciate about our flavour of agile is the discussion it promotes. Since the team is still small and easily manageable, we try to keep everyone aware of what we’re doing and why we are doing it. Discussion is welcome and encouraged in our office.
There’s one practice that works wonders to facilitate dialog about upcoming work: Planning Poker. In its basic form, it’s just a consensus-based technique to estimate effort or size of development goals. When we first started using Planning Poker, I was not a big fan of it for two reasons; firstly, because it is difficult to predict how complex a task is, or how many days it will take to deliver it. And secondly, because I’m awful at estimating.
I’ve dreaded estimating front-end tasks because they usually take longer than I expect. However, I started to notice the real payback of these sessions, something far more necessary than knowing how many days a task will require. The real value in these sessions is about syncing up the product development team as we get to know what lies ahead in the next sprint. We get updated on the importance of the stories lined up for the next two weeks and we discuss the inner workings of new features. Most importantly, we have the opportunity to realise if anything is missing and what we need to do to make our plans happen. This is usually the meeting that takes the longest, but it’s incredibly productive. We align our efforts with the company vision and we start tracing detailed plans on how to achieve it.
Iteration
If I had to summarise everything that agile is to us, iterate would be the only word I would need. That’s the core of agile development, being able to tweak things and adapt to incoming changes. Don’t get attached to ideas, code or practices. Keep what works, drop what doesn’t add value, and polish what can be improved.
An essential tool for this iteration are Retrospectives, meetings usually held at the end of a sprint, where team members discuss, one by one, what went well during the sprint, what didn’t go as planned, and what can be done to improve. Our practices have evolved considerably in these last 6 months, thanks to these meetings. Our development workflow has changed a lot, for example; the way issues progress on our pipeline (i.e. creation, design, development, waiting for review, etc.) is constantly evolving.
A retrospective is a safe space, free of judgement, where people can speak freely about technical and non-technical issues. You can discuss your frustration about a certain practice and ask for opinions about it. You can point out something that doesn’t work for you and propose an alternative. To me, these meetings are the best indication of how healthy and cohesive a team is. You feel heard, validated, and, most of all, appreciated.
Conclusion
Finally, I must stress that agile isn’t a silver bullet. There will always be rough edges on your delivery processes that will need smoothing out. Agile is just a framework to iterate upon them. Even if your process is already highly effective, there will always be new and unexpected situations that will shake up your delivery model. This is to be expected, and agile accommodates these situations by allowing you to adapt to changing requirements.
As long as you are regularly reflecting on how your last sprint went, and improving as you go, you’ll be fine. Stay flexible, keep the practices that work and discard the ones that don’t. There’s a very important point here, and it’s that you shouldn’t try to do agile, but to be agile. The goal is not to focus on the methodologies of agile, or to burden the team with unnecessary processes that don’t add value; but to keep development and delivery as smooth and painless as possible for everyone involved.