Agile — what and why?

So it’s my first week of work as an associate software engineer, which means lots of on boarding and discussions around tech best practices. While it’s still fresh, I wanted to take some time to go over Agile for anyone who may be unfamiliar or wants a refresher :)

So. Agile is a way to approach a project and in my case, a software development project. This process capitalizes on constant communication and collaboration. Teams will work on a certain amount of work for a sprint (1 to 4 week period) in order to work towards the overall goal. After the product is up and running, the team’s sprints will often comprise of new feature releases, hot fixes, and enhancement. To approach a project in an agile way, teams can choose from 2 different agile strategies — scrum and kanban.

Scrum is the agile framework I am more familiar with so I’ll start here. There are 3 key players in the scrum team — product owner, scrum master, and the development team. These development teams should be no larger than 9, but no smaller than 3 and can include back-end engineers, business analysts, qa engineers, UI/UX designers etc.

As a product owner you know exactly what the end product should look like. And when you don’t, you, and only you, check in with the client to get a clearer vision. The product owner communicates these specifications into a log called the ‘product backlog.’ The ‘product backlog’ is where the dev team pulls out tasks for their next sprint’s work.

The facilitator of the sprint planning and other relevant scrum meetings is the scrum master. If the dev team is impeded in any way, the scrum master gets them back on track. Leading, managing and ensuring progress via the scrum progress is his or her day to day.

Finally the development team is comprised of all individuals necessary to build a working product for the client. Every sprint these individuals work on their allocated user stories and communicate daily what was done the day before, what will be done today, and any roadblocks. These meetings are called daily stand-ups and are facilitated by the scrum master.

So what are scrum practices? I’ve already discussed a big one, daily stand-ups, but prior to beginning a sprint, the team needs to plan it. In sprint planning, the scrum master walks the team through the product back-log’s most essential tasks. Remember, the product owner doesn’t specify the ‘how,’ just the ‘what,’ and it’s up to the creativity of the dev team to implement. Each team member decides what task, or user story, they will work on and approximately how long it will take. User stories are the tasks that communicate a product feature or need that delivers business value. Assignment of such continues until everyone has plenty of work for this next sprint. All of the sprint’s user stories are stored in the sprint backlog. As a developer completes a task, the user story is moved from the sprint backlog, to in progress, to done (scrum boards can be as complicated or simple as you like). After the sprint is completed the team will be led in a retrospective meeting where the successes and failures of the previous sprint are hashed out.

Checking in at every step of the process is what allows change and progress to simultaneously exist in the scrum world. This is so important in tech because often the client changes requirements, implementation looks different than intended, or a newly released feature has some undiscovered bug. Because scrum teams can effectively develop a product that matches the vision and business needs of the client, projects progress smoothly and adjust well to real life.

Kanban boards are visual, time constraint free, and flowy. These guys help you see your team’s progress in real time. First things first, you and your fellow devs need to determine what needs to get done during your sprint. Tasks can be physically written out or virtually typed up. In today’s work from home times the latter is probably your go to :) The board you will be displaying your sprint tasks on is then divided into columns are to-do, doing, blocked*, and done.

Of course all tasks start off in the ‘to-do’ column and move across the board in a left to right direction as they near completion. Each team member should always be working on something and see it to the end. This ensures a steady flow of progress (encouraging for the team!) and constant deliverables (good for business value!). Unfortunately, by including a ‘blocked’ column, this flow is halted and can be viewed as ‘anti-kanbanian,’ so include at your team’s discretion. I think as long as communication is apt, you’ll be fine without it.

Anyways, I hope you enjoyed my brief overview of these two agile frameworks. Good luck putting it to practice and feel free to comment about your experience!