Learn all about scrum & agile programming

Archive for August, 2008

Interested In Scrum Careers?

As Scrum’s popularity increases, there is a rising demand for professionals with Scrum experience. However, since Scrum is still a fairly new management method, that puts many aspiring Scrum practitioners in a tough spot: They want the experience of working in a Scrum environment, but they need Scrum experience to get the job. Obviously, then, there is no better experience than actually working in a Scrum environment, but there are plenty of ways to build experience that will pay off in that environment.

One way to secure valuable experience is to attend a two-day Certified ScrumMaster (CSM) course. CSM courses focus on an interactive approach to learning the basics of Scrum, including its vocabulary, principles, and practices. The course lasts only two days, but most attendees find that the information covered really sticks due to the hands-on nature of the course. Several companies offer CSM courses and a full list of trainers and their schedule of courses is located on the Scrum Alliance website.

Of course, real life experience working in a Scrum environment is far more compelling than simply attending a CSM course. When an individual works on a Scrum team—whether as a ScrumMaster, Product Owner, Analyst, Developer, Tester, etc.—for a full year since completing a CSM course, he or she may apply to become a Certified Scrum Practitioner (CSP). The Scrum Alliance reviews and, based on one’s qualifications, approves the CSP designation. Clearly, the CSP title is attractive for employers, who view it as proof that an individual understands Scrum’s principles and processes and has practiced them.

Short of getting experience on a Scrum team, the next best thing is to illustrate to your prospective employer that you possess qualities valued within a Scrum environment. These might include skills such as pair-programming, test-driven development, continuous integration, and refactoring code. Apart from these development techniques, it’s important to demonstrate a strong background in collaboration and facilitation. Since Scrum places greater emphasis on the success of the team, rather than personal heroics, an individual who has proven his or her leadership potential—without extensive authority—would be an excellent candidate for the ScrumMaster role.

Beyond Scrum courses or, of course, working in a Scrum environment, an individual can prepare for a career in Scrum by developing certain skill sets and demonstrating personality attributes that would fit within the Scrum paradigm.

Agile & Scrum Programming

What Is Agile Programming?

Agile programming is an approach to project management, typically used in software development. It helps teams react to the instability of building software through incremental, iterative work cycles, known as sprints. But before turning our discussion to the details of agile programming, it’s best to start at the beginning with the project management paradigm that preceded it: waterfall, or traditional sequential development.

What are the Origins of Agile Programming?

The roots of agile programming can be traced back to 1970, when Dr. Winston Royce delivered a presentation called “Managing the Development of Large Software Systems.” This paper introduced his thoughts on waterfall. Basically, Royce asserted that building software was akin to assembling an automobile. Put another way, each piece can be added in isolated, sequential phases. This process demands that every phase of the project must be completed before the next phase can begin. Thus, developers collect requirements first, work on architecture and design second, and so on. Very little communication occurs during the hand-offs between the specialized groups responsible for each phase of development.

You can probably begin to think of ways in which this approach to software development is flawed. For example, it assumes the customer can identify every single requirement of the project prior to any coding taking place. In other words, waterfall imagines that a customer knows exactly what he or she wants at the outset and that he or she can deliver an airtight and inclusive plan for achieving that vision. If you’re a developer, then you know that it’s infinitely easier for a customer to describe his or her vision when there is functional software to interact with and respond to. It’s a lesson that many software developers have discovered through failing. Moreover, many times, when a waterfall project wraps, a team that built software based on customer specifications finds out that it’s not actually what the customer wanted or another project has rendered all that heads-down programming irrelevant. In the latter scenario, an organization has spent time and money to create a product that no one wants.

Why Agile Programming?

Agile programming gives teams repeated opportunities to assess the direction of a project throughout the entire development lifecycle. These chances for evaluation are built into the natural workflow of agile programming through regular cadences of work, known as sprints or iterations. At the end of every sprint, the team presents a functioning piece of software to the Product Owner for review. This emphasis on a shippable product ensures that the team doesn’t get bogged down with gathering requirements. Because sprints repeat and the product continually adds increments of functionality, agile programming is described as “iterative” and “incremental.” In waterfall, development teams have a single shot at getting each part of a project right. Not so in agile programming, in which every aspect of development is revisited throughout the lifecycle. There’s virtually no chance that a project will follow the wrong direction for very long. Because the team reassesses the direction of a project regularly, there’s always time to change course.

Perhaps the effects of this “inspect-and-adapt” strategy are obvious: Namely, they significantly reduce both development costs and time to market. Because teams can gather requirements while coding, exhaustive requirements gathering can’t prevent a team from making progress. And because agile teams develop within the short, repeatable work cycles, stakeholders have ongoing opportunities to ensure that the product being created matches the customers’ vision. In essence, it could be said that agile programming helps companies build products their customers want. Instead of committing to market a piece of unwritten, sub-optimized software, agile programming empowers teams to build the best software possible. In the end, agile programming protects a product’s market relevance and prevents a team’s work from winding up on a shelf, unreleased, which is an option that makes both stakeholders and developers happy.