First Experiences with Agile, Kanban boards, and Source Control

My first sprint was all about learning broad concepts like the Software Development Lifecycle (SDLC), task management tools, and using source control that helped me orient myself to team development. In order to develop high quality software that meets the needs of product stakeholders, it is essential to follow a SDLC process that fits your business. At a lower level there are tools you can utilize with the SLDC to manage tasks, bugs, and releases. Outside of process and task management, you'll want to utilize some type of source control tool to maintain a history of code changes, merge your code with team member's code, and to conduct peer code reviews. For my internship I followed the Agile SDLC, utilized a virtual Kanban for task management, and used Team Foundation Service (TFS) as my source control tool.

Agile Software Development Lifecycle

For any SDLC you'll have 4 main phases, Requirement Analysis, Architecture Design, Implementation, and finally Testing. Taking a look at the Waterfall SDLC, you'll complete each phase before moving to the next, over the course of a whole release (a release being months of work). Note that there's also a "Maintenance" phase, which is necessary in Waterfall to plan for bug fixes. Agile is similar to Waterfall with regards to the phases, but the difference is what a release consists of. In Agile a release is made up of multiple sprints, where each sprint is 1-4 weeks of work. By only executing a sprint's worth of work at a time you'll only need to plan 1 sprint ahead. By only planning 1 sprint ahead you can easily pivot to other work that needs to be done as requirements change or bugs arise. Note the missing "Maintenance" phase, in Agile bug fixes are scheduled along with requirements and dealt with during each Sprint.

Backlog / Sprint Meeting

In Agile you'll want to maintain a backlog, ideally in your task management system. The backlog is nothing but a complete list of future requirements and bugs. Having a comprehensive list of all the work to be done allows you to prioritize these items for each sprint, and this can be done during a Sprint Meeting. The Sprint Meeting is where Business Owners and Technical Owners meet to prioritize the backlog, giving the developers a prioritized list of work to plan for the next sprint. Each developer then simply grabs a task, adds their estimated # of hours to complete said task, and repeats till their workload is filled for the sprint. For the purpose of developing the Fitness Explorer app we did 2 week sprints at a time.

Task Management - Kanban board

To schedule things that needed to be completed for each sprint I used something called a Kanban board. It's a tool used to visually represent workflow and schedule tasks. I used the built in Kanban board through Microsoft Team Foundation Server. Using this I was able to view the tasks that needed to be completed, place them in the "In progress" section, and, when completed, place them in the "done" section. This made the organization of the tasks to be completed, as well as the tasks already completed, extremely easy.

Source Control – Team Foundation Server

Source Control allows you to maintain a history of code changes by having a centralized repository for that code. This allows multiple developers to work on the same code base and easily merge their code changes with others. Some options out there include GIT, SVN, and TFS. Although I was the only developer working on the Fitness Explorer app, it was still essential to have my code backed up at all times so that my manager could easily perform code reviews.

Next Sprint

The next sprint continues to cover some high level concepts in software development and how they tie into developing the Fitness Explorer app. In the next article I'll cover learning the Repository pattern, MVC architecture, and Unit testing.