Today, I learned about the project (or at least on of the projects) I’ll be tackling this summer at Interapt. I was introduced to Agile Development methodology, which seemed very unusual compared to anything I had ever done before. I found myself constantly challenging my beliefs of software development that led to me asking several questions in the planning meeting.
In this blog post, I’ll be shedding some light on the project I’ll be working on without violating NDA. I’ll discuss the Agile development methodology used at Interapt and some of the differences between Agile and Waterfall methodology. I’ll explain how my colleagues and I planned our tasks by playing a game of cards.
The big picture of the project is to create an internal employee directory to securely manage employee information which includes but is not limited to be able to display, create, update, and delete information. A web app will allow managers and admins to manage the information, a mobile app allows users (employees) to only view the information. The backend will be designed as a RESTful API to serve both the web app and mobile app through end points. I will be developing the web app portion of the project using Angular 2 framework. I feel very confident to embark on this project since I’ve continued to grow my knowledge of Angular 2 since the beginning of my internship.
Agile methodology can conflict the minds of traditional developers who follow the waterfall methodology. Developers start off with a basic design or framework, and then begin to work on small components of the entire system, which is often broken down as a story or a task. The idea is to fulfill the requirements of the story from the storyteller’s or user’s standpoint. The work on these components is done in weekly or monthly sprints, and at the end of each sprint, project priorities are evaluated and tests are run. These sprints allow for bugs to be discovered, and customer feedback to be incorporated into the design before the next sprint is run.
Comparison with Waterfall technique
In my experience in software development at Berea College as a Student Programmer and a couple of big coding projects I had done, I always used the waterfall method. Where the project follows a sequential process starting at a concept, initiation, design, architecture, implementation, testing, and further development upon testing. In contrast, the Agile methodology is difficult to digest for traditional waterfall developers because agile lacks the initial design and planning, and is often criticized for its collaborative nature that focuses on principles rather than process.
But for startups like Interapt, I think the benefits outweigh the drawbacks. The Agile methodology allows for changes to be made after the initial planning. It makes it easier to add features and improve upon feedbacks from clients at the end of each sprint when the project priorities are evaluated. The product is well thoroughly tested at the end of each sprint that reduces the risk of finding a huge bug at the end of the project. Because the products are tested so thoroughly with Agile, the product could be launched at the end of any cycle. As a result, it’s more likely to reach its launch date.
Planning a Sprint by playing Poker
Yes, we played poker to plan our sprint. Poker is very commonly used in Agile development. It is used to estimate how much time would each component/story of the entire project would take arbitrarily. Our meeting included Backend Developer, Front-end Web App Developer (myself), Mobile App Developer, UX Designer, QA, Project Manager, The Scrum Master, and mentors.
At the start of this agile planning exercise, each estimator (people who were involved in the implementation) was given a deck of Planning Poker cards. Each card has one of the valid estimates on it, for example: 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 40, 100 and infinity.
For each user story or theme to be estimated, The Scrum Master read the description. We had some discussion, where the product manager answered questions we had. The goal of Planning Poker was not to derive an estimate that will withstand all future scrutiny. Instead, we want a valuable estimate that can be arrived at inexpensively. After discussion, each estimator privately selected a card representing his or her agile estimation. Once each estimator had made a selection, cards were simultaneously turned over and shown so that all participants can see each others estimate.In the beginning, none of us had the same number After discussion, each estimator re-estimates by selecting a card. Often, the estimates will converge by the second round. If not, repeat the process until the team agrees on a single estimate to use for the story or these. It rarely takes more than three rounds in agile estimation to reach the goal.
In the beginning rounds, each of us awfully differed from each other primarily because we had no idea what the numbers meant. The highest and lowest estimators had to explain why the chose those numbers and after some discussion, we estimated by selecting a card until we all agreed to the same number. These numbers were just to put each story/task in a spectrum, so it easy to visualize when can each task be delivered from everyone’s perspective.
Finally, we put a deadline after two weeks for the first sprint when we would reunite and evaluate our work and plan the next sprint.