Working With Agile

Mar 30, 2020 • 4 min read
Knowledge • Methodologies • Productivity

Primer

I spent some time a few nights ago completely overhauling my resume. This is really for a few reasons:

• It was a mess and needed the overhaul.
• It was outdated.
• It didn't showcase anything about me or my skillset.

One of the additions to my resume has been a Technical Proficiencies section, which includes a piece on Methodologies. In my current role as a Business Analyst, I'm always on the System Development Life Cycle (SDLC) wheel, but additionally, I'm also using Agile more than I may realize.

What is Agile?

Agile is officially summarized by the following four points:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

That's a good high-level overview, but I think it's important to find out what exactly that means to me. Let's dive in...

Scrum vs. Kanban

Whenever the topic of Agile comes up, the first thing that likely comes to mind for people who are familiar with it is Scrum. It's wildly popular in the software development and project management world, and with good reason.

Atlassian has a great write-up of the differences between Scrum and Kanban. Without going off on too much of a tangent, I'll outline what I think are the most important parts of each below:

Scrum

• Each team member has certain roles and responsibilities.
• Sprints, or set periods of time set aside for work, are heavily used.
• Modifications during a sprint are discouraged. # Fixed typo from "spring" to "sprint"
• Best for teams with stable priorities.

Kanban

• No pre-defined roles for a team. Everyone chips in.
• Work is delivered continuously.
• Changes can be made at any point.
• Best for teams with varying priorities.

Personally, I'm a huge fan of Kanban. The boards are fantastic and can be as simple or complex as you want. It also allows for an entire team to chip in on tasks, which I think ultimately leads to a better end result.

Applying to Software Development

I started reading a blog by Gergely Orosz, who is an engineer building large-scale distributed systems for companies such as Uber. He wrote a fantastic piece on what Agile really means in terms of software development. He wrote the following basics, which I couldn't agree more with:

• When writing code, do it in an agile way. Decide what you want to achieve, do a small change, test it, learn from it, adjust, and repeat. Try to write code that's easy to change later.
• When building a product, do it in an agile way. Do small changes, get immediate feedback, do small iterations, and make decisions that allow future changes as much as possible.
• Similarly, when working as a team, solve problems using these basic principles, a small step at a time.
• The tools and methodologies you use should help achieve this kind of agility. If they only add more process — ditch them.

This is a perfect way of looking at software development without getting lost in all the technicalities.

What Agile Means to Me

I think it's easy to get lost in the weeds with theory and jargon because Agile can mean a lot of things to a lot of different people. Businesses and disciplines in general can look at Agile and take any approach they want. All of that is completely acceptable, but that's not what we're doing here.

Agile to me comes down to a few important things:

• Make small changes.
• Learn from these changes and make adjustments accordingly.
• Improve on what you're working on based on these changes.
• Rinse and repeat until you've reached your goal.

Conclusion

It's easy to get lost in the weeds with Agile. As I mentioned, it means a lot of things to a lot of people. In short, stick to the basics, learn from them, and make improvements until you've reached your goal.