Code Library

Scrum's framework is a healthy framework, both from a cultural and software development standpoint, to use for guiding a development team. Scrum is about the accountability and transparency of a team. Scrum identifies problems earlier in the process; however, it will not fix the problems. Scrum does not teach you what frameworks to use or which source control to use or how to develop. It doesn’t show you how to do your job; it provides you ways to better do your job. Scrum holds true to the values of the Agile Manifesto, which are as follows:

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

Throughout this case study, our process and, hopefully, we as individuals, have evolved. We started with understandable criticism. Why do we use all these Post-it notes? What are the swim lanes on the Kanban board for? Why are we having a meeting every, single, work day? Why do we have to write user stories in a certain format? And, for Pete’s sake, why are we spending so much time on creating automated tests? I just want to crank out code! We’re software developers and we are managing items with Post-it notes and a board? How could this ever be efficient? It seems as if we’ve taken a step back in time!

Yet over time, we came to appreciate that the Post-it notes and the swim lanes serve as great ways to capture manageable, measurable pieces of work that keep everyone updated on the team’s progress. These tools allow us to create big, visible charts (BVCs), such as burn-down charts, to allow both team members and people outside the team a quick overview of how the project is progressing. We write user stories in a certain way to help capture what the business tells us it needs; and this consistency also helps to form and translate these requirements into interactive features.

Automated testing is important because developers can work with the business and with testers to determine the clear definition of requirements by writing our tests first and then writing the code to get those tests to pass; as opposed to writing code first from a piece of paper. Although this guarantees that the code does what it was written to do, it may not correspond to what the users want. This is where regular communication with the customer comes in. Automated testing also aids in producing robust and shippable code to verify that the tests work and that the code is what the business wants.

Scrum is a big advocate of a quick feedback loop for improving our process. As the team from the case study went through multiple sprints, they came to value this quick feedback loop. Feedback loops come in a few different varieties. From a “people” point-of-view, there are daily stand-ups, product demos, and retrospectives. From the code perspective, there is the continuous integration (CI) server.

The daily stand-ups are quick, simple, and effective. With everyone announcing what they did yesterday, what they are doing today, and what roadblocks they are experiencing, they are being transparent about their progress to the rest of the team. No one is able to hide from the team. No one can stay in his cube without anyone knowing what he is doing. Everyday everyone must stand up with their peers and tell what they did. This is one time where peer pressure is good.

It’s important to note what we have not seen. In traditional methodologies, project managers or bosses would often come up to a developer and ask for a status update. At the extreme, these happen several times a day. Unfortunately, this wrecks a developer’s train of thought when he is focused on getting something done. Context switching is a very costly exercise and it happens often in a “traditional” environment. With the daily stand-up, the project managers, the bosses, or any individuals that “need to know” come to this meeting to get information. Because the daily stand-up is quick and at a consistent time, it’s easy to become a daily routine.

Source of Information : Pro Agile .NET Development with SCRUM